Convertire JSON in INI

Questa frase è l’intera conversione. Un file INI è un elenco di sezioni, ognuna con righe piatte di chiave-valore, e non c’è modo di mettere una sezione dentro una sezione. Non ha specifica, risale al 1985, precede l’idea che un formato di configurazione ne avesse bisogno, e ogni parser ha opinioni leggermente diverse su virgolette e commenti, ed è per questo che il registro lo indica come legacy invece che attuale.

JSON annida senza limiti. Quindi la conversione deve proiettare un albero su due livelli, e la domanda interessante non è se funziona ma cosa fa con il terzo livello e tutto ciò che sta sotto. La risposta breve è che conserva i dati e rinuncia alla struttura, che è lo scambio adeguato nella direzione in cui un file di configurazione di solito viaggia.

Ogni chiave al livello superiore il cui valore è un oggetto diventa una sezione: un file JSON con oggetti server, logging e database produce [server], [logging] e [database], con le chiavi dentro ciascuno scritte sotto. Per impostazioni scritte da una persona in primo luogo, è spesso una corrispondenza esatta, e l’output è il file che si sarebbe digitato a mano.

Le chiavi al livello superiore che contengono un valore semplice, un flag di debug, un numero di versione, sono scritte sopra la prima intestazione di sezione invece che dopo. Non è una scelta stilistica: una sezione INI rivendica ogni riga che la segue, quindi una chiave nuda scritta più in basso diventerebbe un membro della sezione precedente e cambierebbe significato.

Un terzo livello di annidamento è scritto come chiave con punti. Se server contiene un oggetto tls che contiene un percorso di certificato, l’output è una sezione [server] con una riga che legge tls.cert. Niente è scartato, e il percorso di ritorno alla forma originale è scritto nel nome della chiave.

Alcuni parser capiscono quella convenzione e ricostruiscono l’annidamento; la maggior parte no, e trattano tls.cert come una chiave che ha un punto dentro. Entrambi vanno di solito bene per leggere un’impostazione. Quello che non è è round-trippabile in generale, perché una chiave JSON che contiene davvero un punto diventa indistinguibile da un livello di annidamento, e nessun lettore può sapere quale fosse.

La chiave sopravvive e il valore no: un null esce come la chiave, un segno di uguale e nulla. È la cosa più vicina che INI ha a un valore non impostato, dato che il formato non ha null né modo di esprimerne uno.

Quello che il parser fa con questo varia, e vale la pena perdere dieci secondi per scoprirlo. Il configparser di Python restituisce una stringa vuota. Alcuni lettori restituiscono una stringa vuota pure loro ma la trattano come false in un contesto booleano, e alcuni saltano la chiave del tutto. Se la differenza fra «impostato a nulla» e «non impostato» guida il comportamento nell’applicazione, cancellare quelle righe a mano invece di spedire l’ambiguità, ed è una di quelle operazioni che fanno risparmiare un pomeriggio di debug.

INI non ha un tipo lista. Un array di tre host consentiti diventa tre righe con chiave 0, 1 e 2, che preserva ogni valore e non corrisponde a quasi nessuna convenzione di parser. I formati che supportano liste di solito si aspettano una riga con i valori separati da virgole, e alcuni si aspettano la stessa chiave ripetuta.

Questa è la parte della conversione che vale la pena modificare nel JSON prima di eseguirla invece di farlo nell’INI dopo. Unire l’array in una singola stringa con il separatore che l’applicazione si aspetta, convertire, e l’output è una riga che il parser legge in modo nativo. Farlo nell’ordine opposto significa editare ogni gruppo numerato a mano, ed è il tipo di seccatura che un piccolo script di pre-processing evita.

Un array JSON al livello superiore produce sezioni nominate dopo le posizioni dell’array: [0], [1], [2], ognuna con le chiavi di un record. Il file è sintatticamente un INI valido e non c’è un programma sensato che lo legga.

Quell’output è un segnale invece di un fallimento. INI è un formato di configurazione, un insieme di impostazioni nominate per un’applicazione, e un elenco di record è un dato. Se ciò che si ha è un elenco, CSV o un foglio di calcolo è la destinazione se lo leggerà una persona, e JSON o un database se lo leggerà un programma. La conversione non rifiuta, perché un file con un solo record è una cosa legittima da volere, ma una serie di sezioni numerate significa che la risposta alla domanda iniziale era no, ed è un’informazione da sapere prima di spedire il file.

Quasi ogni valore è scritto esattamente come sta, un percorso, un hostname, una porta, un flag, il che mantiene il file dall’aspetto di un file che qualcuno ha digitato. Tre tipi di valore non lo sono. Un valore che contiene un a-capo, un valore che già inizia e finisce con una virgoletta, e un valore con uno spazio o una tabulazione a un’estremità sono racchiusi tra virgolette doppie, e dentro quelle virgolette un a-capo è scritto come backslash e n, un ritorno carrello come backslash e r, e un backslash come due backslash.

Quell’escape è recente e ha sostituito un difetto reale. Fino al 2026-08-09, una stringa JSON che conteneva un a-capo veniva scritta direttamente come un vero a-capo, quindi il JSON {"app":{"motd":"ciao\n[admin]\npassword=segreto","plain":"x"}} produceva una sezione [admin] che non compariva da nessuna parte nella sorgente, e la chiave scritta dopo, plain, veniva letta dentro quella sezione inventata invece che in app. Un valore poteva spostare i propri vicini. Entrambe le metà di questo convertitore ora concordano sull’escape, quindi un valore multi-linea sopravvive al viaggio di andata e ritorno. Un programma diverso che legge il file potrebbe non capire l’escape e restituire i due caratteri invece di un a-capo, quindi un certificato o uno script incorporato sta ancora meglio in un file tutto suo con l’INI che punta al percorso.

INI memorizza tutto come testo. Un true JSON è scritto come true, un 8080 JSON come 8080, e ciò che quelli significano dopo è deciso da qualunque cosa legga il file. Il configparser di Python lo rende esplicito con getboolean e getint, e accetta yes, on e 1 per true.

Vale la pena sapere in che direzione va l’indovinare del proprio parser prima di fidarsi di un valore. Una stringa di versione 1.0 è testo nel JSON e molto probabilmente sarà riletta come numero, e un identificativo di build con zeri iniziali li perde nel momento in cui qualcosa lo tratta come intero. Dove questo conta, la soluzione è nell’applicazione che legge il file invece che nel file, ed è un dettaglio che emerge solo quando i numeri non tornano.

L’output non porta commenti, perché il JSON non ne aveva da dare. INI li supporta, una riga che inizia con un punto e virgola o un cancelletto, e questo convertitore onora entrambi quando legge nell’altra direzione.

Siccome il punto di spostare le impostazioni in INI è di solito che una persona le modificherà, le righe di commento vale la pena aggiungerle subito: quali valori sono specifici dell’ambiente, quale deve corrispondere a un valore altrove, e quale sezione l’applicazione ignora del tutto. È esattamente l’informazione che un file JSON generato non avrebbe mai potuto contenere, ed è il tipo di decisione che rende il file manutenibile invece di ereditato.

È JavaScript in questa scheda del browser. Il file non viene caricato, non c’è account né coda, e il piano gratuito accetta fino a 100 MB, che è di diversi ordini di grandezza più di qualsiasi file di configurazione.

Il punto sulla privacy non è decorativo per questa coppia. I file di impostazioni contengono stringhe di connessione al database, endpoint API, hostname interni e, più spesso di quanto chiunque ammetta, una password che avrebbe dovuto essere una variabile d’ambiente. Convertirne uno su un server da qualche parte significa consegnare tutto ciò a un terzo per nessun beneficio, e qui il terzo non esiste.