Che cos’è un file INI?

INI è un formato di testo semplice che si apre in qualsiasi editor. Si usa per la modifica.

L’estensione è .ini e il nome per esteso è INI Configuration. Contano entrambi meno di ciò che il file può contenere, ed è di questo che parla il resto della pagina.

Risale al 1985.

A un formato rimasto leggibile così a lungo si può affidare qualcosa che vuoi ritrovare fra dieci anni.

È pubblicata per intero, quindi la si può implementare partendo dal documento invece che per osservazione: è per questo che il formato compare in così tanti programmi, ed è per questo che file scritti vent’anni fa si aprono ancora. Una specifica pubblicata però non è la stessa cosa di una esente da royalty: dove un formato incapsula un codec, le licenze sui brevetti restano una questione a parte che lo standard non risolve.

Si apre ancora dappertutto e i programmi più vecchi lo scrivono ancora, ma attorno non si costruisce più niente di nuovo. Converti ciò che vuoi tenere e non sceglierlo per qualcosa che comincia oggi.

INI ha una sintassi per i commenti, ed è la differenza fra un file che cura una persona e uno che scrive un programma. I commenti sono la prima cosa che si perde convertendo in un formato che non li ha, e nessuno ti avvisa.

Notepad e Visual Studio Code lo leggono, e così fanno quasi tutti i programmi dello stesso tipo.

Quando un file non si apre, il formato è raramente il problema: più spesso è il programma a essere più vecchio di lui. Convertire in qualcosa di più vecchio è la via d’uscita affidabile, ed è a questo che serve il resto di questo sito.

Nessun browser lo legge.

È di gran lunga il motivo più comune per convertirlo: non che il formato sia scadente, ma che il posto in cui vuoi mostrare il file non sappia leggerlo.

INI è pensato per essere aperto e modificato. Tieni il file in questo formato per tutto il tempo in cui il lavoro va avanti, ed esporta da lì ogni volta che serve una copia finita.

L’INI viene dai primi Windows, dove salvava la configurazione del sistema e quella di ogni applicazione. Non è mai stato standardizzato: nessun documento lo definisce, nessun comitato lo sorveglia, e ogni programma che ne legge uno implementa il proprio dialetto.

Il nucleo è comunque universale: intestazioni di sezione fra parentesi quadre e sotto, righe chiave-uguale-valore. Tutto ciò che va oltre quel nucleo è incerto. Se il commento inizia con punto e virgola o con cancelletto. Se un valore può stare fra virgolette e cosa succede a quelle virgolette. Se le chiavi distinguono maiuscole e minuscole. Se un valore può continuare sulla riga successiva. Se le sezioni si annidano, cosa che in quasi nessun dialetto avviene. Due programmi possono leggere lo stesso file e non essere d’accordo, entrambi legittimamente.

Scrivete timeout=30 e nel file ci sono un 3 e uno 0. Che questo diventi un numero, e che significhi secondi o millisecondi, lo decide interamente il programma che lo legge. Lo stesso vale per true, yes, on e 1, tutti modi comuni di scrivere un booleano, nessuno definito dal formato, e ogni libreria ne accetta un sottoinsieme diverso.

È la differenza pratica con JSON, YAML o TOML, che hanno tipi veri. Spiega perché i file INI arrivano quasi sempre con documentazione o commenti che chiariscono cosa significano i valori, e perché spostare un file di configurazione fra due implementazioni dello stesso programma sia più pericoloso di quanto sembri.

Su Windows, tuttora, in vari posti: il desktop.ini che decide come si mostra una cartella, configurazioni di avvio e driver, e una lunga coda di applicazioni che non hanno mai avuto motivo di cambiare. I videogiochi sono una fonte particolarmente abbondante: un numero enorme di giochi per PC salva le impostazioni grafiche e dei controlli in un INI, motivo per cui le guide di configurazione sono piene di istruzioni per modificarne uno.

Fuori da lì sopravvive in strumenti precedenti alle alternative moderne: il php.ini di PHP, la configurazione di Git, il setup.cfg di Python e le sue utility di packaging, le unit di systemd e innumerevoli piccoli programmi. I progetti nuovi tendono a scegliere TOML o YAML, ma nulla di già installato verrà riscritto.

Con qualsiasi editor di testo. Due regole evitano quasi tutto il danno che si fa di solito: copiate il file prima di toccarlo e cambiate una cosa sola alla volta, perché un programma che non parte a causa della sua configurazione raramente dice a quale riga ha trovato un problema.

Poi vengono i dettagli che provocano guasti veri. Salvate in UTF-8 senza indicatore d’ordine dei byte, perché quei byte invisibili all’inizio del file rompono la prima intestazione di sezione in molti analizzatori. Non aggiungete spazi intorno al segno di uguale a meno che non sappiate che il lettore li rimuove, perché alcuni lettori non lo fanno e il vostro valore inizia con uno spazio. E non toccate le virgolette: se i valori esistenti sono senza, aggiungerle può aggiungere due caratteri al valore invece di delimitarlo.

Essere evidente. Una persona che non ha mai visto il file può aprirlo, trovare l’impostazione chiamata fullscreen, cambiare false in true e indovinare correttamente. È una proprietà reale ed è il motivo per cui il formato è sopravvissuto a tutto ciò che negli anni Novanta doveva sostituirlo.

Fallisce anche con eleganza nel caso superficiale: una chiave sconosciuta viene di solito ignorata invece che essere fatale, così un file scritto per una versione più recente del programma di solito continua a funzionare in una più vecchia. Le alternative sono più rigorose, il che è meglio per la correttezza e peggio per chi sta sistemando un gioco a mezzanotte.

Quando la configurazione è andata oltre semplici sezioni piatte di stringhe. Struttura annidata, liste, date, numeri che devono essere numeri, o qualunque valore dove la differenza fra la stringa «false» e il booleano false conta: lì l’INI smette di aiutare e comincia a nascondere errori.

Il TOML è stato progettato proprio come risposta a questo: assomiglia all’INI, così nessuno deve imparare una forma nuova, e ha una specifica, tipi veri e annidamento definito. YAML è l’altra destinazione abituale, più potente e piuttosto più facile da rovinare. Se un file sta per crescere, TOML è il passo più breve e quello che conserva la leggibilità che rendeva utile l’INI.

L’INI non ha dove mettere un oggetto dentro un altro, quindi convertendo verso di esso la struttura viene appiattita: ogni valore finale diventa una chiave il cui nome è il percorso completo separato da punti, e gli indici di un array sono un ulteriore tratto di quel percorso. Un JSON con server.base.porta finisce per essere letteralmente una chiave chiamata così.

È una scelta consapevole e ha conseguenze da vedere prima di convertire. Il file risultante è corretto e leggibile, ma non ha più la stessa forma: chi lo leggerà dopo vedrà chiavi lunghe e piatte dove c’era un albero, e tornare indietro richiede che qualcuno decida che i punti significavano annidamento. Le stesse destinazioni appiattite sono CSV, TSV, SQL, XLSX e Parquet; JSON, YAML, TOML, XML e NDJSON conservano l’albero.

Leggendo un INI qui, i commenti vengono scartati esplicitamente. Non è una svista: in un file di configurazione il commento è spesso l’unica documentazione presente, quindi se avete davanti l’INI commentato di un programma e lo convertite in un altro formato, conservate anche l’originale. Nessuno dei formati di configurazione di questo sito conserva i commenti, né YAML, né TOML, né XML, perché tutti si trasformano in valori piatti senza un canale dove salvarli.

L’ordine delle chiavi, invece, resta com’è: nulla ordina alfabeticamente per conto proprio. Conta più di quanto sembri quando il file va confrontato con un’altra versione di sé stesso, perché un riordinamento silenzioso trasforma un cambiamento di una riga in un diff illeggibile.