Convertire INI in XML

La mappatura è abbastanza diretta da poter essere prevista. Un’intestazione di sezione diventa un elemento, ogni chiave sotto di essa diventa un elemento figlio, e il valore diventa il testo di quell’elemento. Un file INI che contiene [db] con host e port sotto esce come un elemento db che contiene un elemento host e un elemento port, rientrati di due spazi per livello.

Questa prevedibilità è il motivo per cui questa coppia vale uno strumento invece di uno script. Non c’è ambiguità da risolvere, perché un file INI offre a un convertitore quasi nulla da interpretare: un livello di raggruppamento, una chiave, un valore per riga. Tutto ciò che è interessante succede ai bordi, e il resto di questa pagina è su quei bordi.

XML richiede esattamente un elemento più esterno, e un file INI non ha il concetto di radice. Il convertitore risolve la cosa guardando ciò che ha letto: se il file conteneva una sola sezione e nient’altro, quella sezione diventa la radice, quindi un file con una sola sezione chiamata [settings] produce un documento il cui tag radice è settings. Qualsiasi altra cosa, due sezioni o chiavi scritte sopra la prima intestazione, viene racchiusa in un elemento radice generico.

Vale la pena saperlo prima di scrivere un XSD o un XPath sul risultato. Aggiungere una seconda sezione al file INI di partenza cambia silenziosamente l’elemento radice dell’output da settings a root, e ogni espressione di percorso scritta contro la prima versione smette di corrispondere. Se la forma del documento conta a valle, meglio decidere da soli quale contenitore usare e mantenerlo stabile invece di lasciare decidere al numero di sezioni.

INI non ha alcun sistema di tipi: tutto ciò che sta a destra del segno di uguale sono caratteri. Il lettore ci prova comunque, trasformando true e false in booleani e tutto ciò che si analizza come numero in un numero, e chi scrive l’XML poi ristampa ciò che ha ottenuto come testo. Per la maggior parte delle chiavi il viaggio di andata e ritorno è invisibile.

Per alcune non lo è. Un valore scritto 007 è letto come numero 7 e riscritto come 7. Una chiave di versione scritta 1.0 diventa 1. Una maschera esadecimale scritta 0x1F esce come 31, e un permesso Unix scritto 0755 esce come 755, che è un permesso diverso. Qualsiasi cosa abbia un’unità attaccata sopravvive intatta, quindi 128M resta 128M, e così gli indirizzi dotted come 127.0.0.1 e gli orari come 08:00, perché nessuno dei due si analizza come un singolo numero.

XML è molto più rigido sui nomi di quanto non sia INI. Una chiave INI può contenere spazi, barre, due punti e parentesi; un nome di elemento può contenere lettere, cifre, underscore, trattini, punti e poco altro, e non può cominciare con una cifra. Chi scrive l’XML quindi sostituisce con un underscore ogni carattere che non può usare, e premette un underscore a qualsiasi nome che non cominci con una lettera o un underscore.

La sostituzione non è reversibile, quindi due chiavi che differiscono solo per punteggiatura collidono nello stesso nome di elemento. «log level» e «log-level» non collidono, perché il trattino è legale, ma «log level» e «log/level» diventano entrambi log_level. Se il file INI ha chiavi di quel tipo, meglio rinominarle nell’origine prima di convertire, invece di scoprire dopo da quale riga veniva ciascun elemento.

Un’intestazione scritta [database.pool] sembra che dovrebbe annidarsi, e in TOML lo farebbe. Qui non lo fa: il lettore prende tutto ciò che sta fra parentesi come un unico nome di sezione, quindi l’output contiene un singolo elemento di nome database.pool con le chiavi dentro. I punti sono legali nei nomi di elemento XML, quindi il documento è valido; è piatto dove ci si poteva aspettare una profondità.

Se lo schema di destinazione vuole un annidamento reale, quella struttura va creata, non convertita. La sequenza onesta è convertire prima e poi rimodellare l’XML risultante con XSLT o a mano, perché un convertitore che provasse a indovinare l’annidamento dalla punteggiatura sbaglierebbe proprio sui file INI in cui un punto fa parte di un nome invece di essere un separatore, e i file di configurazione PHP, dove chiavi come date.timezone sono ovunque, sono esattamente quel caso.

INI non ha uno standard, solo convenzioni, e uno dei punti su cui le implementazioni sono in disaccordo è cosa significhi un’intestazione di sezione ripetuta. Alcune fondono i due blocchi. Questo lettore no: crea una sezione nuova e vuota ogni volta che vede un’intestazione, quindi un file con [logging] che compare due volte conserva solo le chiavi della seconda occorrenza e perde il primo blocco interamente, senza un errore.

Le intestazioni ripetute sono rare nei file scritti a mano e comuni in quelli assemblati per concatenazione, una configurazione di base con sopra accodata una sovrascrittura di ambiente, che è uno schema reale di distribuzione. Cercare nel file di partenza le intestazioni duplicate prima di convertire, perché il fallimento è silenzioso e l’output è un documento XML perfettamente ben formato a cui mancano delle impostazioni.

Entrambi i formati supportano i commenti. INI li marca con un punto e virgola o un cancelletto, XML con un blocco fra parentesi angolate, e questa conversione non ne porta nessuno dall’altra parte: le righe di commento sono saltate durante la lettura e non ricompaiono. Il registro indica entrambi i formati come commentabili, il che rende la perdita un artefatto della pipeline invece di un limite del formato di destinazione.

Su un file di configurazione conta più di quanto sembri. La riga sopra un timeout che spiega perché è stato alzato a 90 secondi a causa di un report lento è di solito l’unico registro di quella decisione esistente al mondo. Copiare il file originale commentato nel controllo di versione prima di convertire, e riattaccare le spiegazioni all’XML dopo; niente in una conversione automatica di questo tipo può farlo al posto nostro.

La ragione per fare questo spostamento non è quasi mai la sintassi. XML 1.0 è una raccomandazione W3C dal 1998, e intorno gli è cresciuto il meccanismo che INI non ha mai avuto: schemi XSD che rifiutano una configurazione con una chiave scritta male prima che l’applicazione parta, XPath per estrarre un valore da un documento grande, XSLT per rimodellarlo, e firme digitali XML per attestare che un file di configurazione non è stato alterato.

Niente di tutto ciò arriva con la conversione. L’output è un documento ben formato senza schema allegato e senza namespace dichiarato, e scrivere lo schema è il lavoro vero; la conversione fornisce solo un documento di partenza su cui scriverlo. Se non si intende convalidare, firmare o trasformare il risultato, la migrazione compra solo verbosità.

Se l’applicazione che legge il file è quella che lo ha scritto, e nulla a valle ha bisogno di uno schema, convertire è un costo senza ritorno. Un file INI è modificabile da chiunque sappia aprire Blocco Note, e questa è una proprietà operativa reale quando la persona che cambia un parametro alle due di notte non è uno sviluppatore.

La conversione è anche lo strumento sbagliato se ciò che serve davvero sono due o tre valori dal file invece del file intero. Estrarli direttamente. Questo convertitore è per il caso in cui il file INI è la configurazione e la configurazione si sta spostando, non per estrarre un frammento.