Convertire XML in INI

INI è il formato di configurazione che molte applicazioni Windows, giochi e strumenti a riga di comando si aspettano ancora: sezioni fra parentesi quadre e righe `chiave=valore`, niente di più. Chi ha una configurazione in XML — spesso più espressiva di quanto serva — e deve alimentare uno di questi strumenti trova qui la via diretta.

Non è una conversione reversibile con la stessa fedeltà con cui è arrivata: XML può rappresentare strutture profonde quanto vuole, INI ne conosce solo due livelli, quindi qualcosa nella forma dell’originale viene necessariamente compresso strada facendo.

Il parser legge attributi e testo in un unico albero: ogni attributo diventa una chiave con il prefisso `@` davanti al suo nome, e il testo contenuto direttamente in un elemento diventa una chiave `#text`. Un attributo che sembra un numero, come `versione="2"`, viene convertito automaticamente in un numero.

Il testo di un elemento, invece, resta sempre testo: non c’è alcuna conversione automatica di tipo su quel lato, a differenza di quanto avviene per gli attributi.

I commenti XML non vengono letti in nessuna forma: se la configurazione originale spiegava un’impostazione con un commento accanto, quella spiegazione non arriva nel file letto e quindi non può arrivare nemmeno nell’INI finale.

Un elemento che compare una sola volta nell’XML diventa un oggetto singolo; lo stesso elemento, se ripetuto due o più volte, diventa invece una lista. Un file dove quell’elemento a volte compare una volta sola e a volte più volte produce quindi strutture diverse a seconda del caso specifico — vale la pena tenerlo presente se la struttura del documento non è sempre identica.

Tutto ciò che sta oltre il primo livello dell’albero XML viene appiattito: il percorso di ogni valore, dai suoi elementi genitori fino a lui, diventa il nome della chiave, con un punto a separare ogni passaggio. Un valore annidato tre livelli sotto la radice arriva come un’unica chiave con due punti al suo interno.

È lo stesso meccanismo che appiattisce i dati annidati verso CSV, TSV o XLSX altrove sul sito: qui la destinazione è diversa, ma la logica di collassare la profondità in un nome di colonna — o, in questo caso, in un nome di chiave — è la stessa.

Un valore che sta direttamente sotto la radice dell’XML, senza ulteriore annidamento, diventa una riga senza sezione, in cima al file INI. Tutto ciò che sta più in profondità finisce sotto una sezione che prende il nome dal primo elemento del suo percorso, con il resto del percorso — punti compresi — come nome della chiave dentro quella sezione.

Questo significa che un XML con tre livelli di annidamento sotto un elemento produce comunque una sola sezione INI per quell’elemento, non tre sezioni annidate: INI non ha un modo di annidare le sezioni, e il convertitore non ne inventa uno.

Un valore che contiene un ritorno a capo, un backslash o entrambi viene scritto racchiuso fra virgolette con quei caratteri codificati, così da poter essere riletto correttamente da questo stesso convertitore. Un valore che inizia o finisce con uno spazio riceve lo stesso trattamento, perché altrimenti quello spazio andrebbe perso rileggendo il file.

Un lettore INI diverso da questo, scritto per un’altra applicazione, potrebbe non riconoscere questa codifica dei ritorni a capo: se il file deve essere aperto da un programma specifico, vale la pena controllare che quel programma gestisca valori multiriga prima di affidarsi a questo comportamento.

Il formato INI ammette righe di commento che iniziano con `;` o con `#`, ma questo convertitore non ne scrive mai: anche se l’XML di partenza avesse avuto commenti — e comunque non li leggerebbe, come detto sopra — il file INI in uscita è fatto solo di sezioni e coppie chiave-valore.

Chi ha bisogno di documentare la configurazione dovrà aggiungere quei commenti a mano dopo la conversione, direttamente nel file INI generato.

La lettura dell’XML e la scrittura dell’INI sono JavaScript puro, eseguito nella pagina già caricata dal browser: non viene scaricato alcun modulo aggiuntivo e non parte alcuna richiesta di rete che porti il contenuto del file altrove.

Ogni file può arrivare fino a 100 MB, e se ne possono convertire fino a cento insieme in un’unica volta, restituiti come un archivio ZIP con un INI per ciascun XML originale.

Un XML con array lunghi o con più di due livelli di annidamento significativo produce un INI pieno di chiavi punteggiate difficili da leggere a occhio, perché il formato non ha davvero un modo elegante di rappresentare quella profondità. Se la struttura del documento conta quanto i suoi valori, JSON o YAML — entrambi mantengono l’albero intatto invece di appiattirlo — sono la scelta migliore.

INI resta la scelta giusta quando la configurazione di destinazione è genuinamente piatta: poche sezioni, poche chiavi per sezione, nessun bisogno di liste o di annidamento profondo.