Qual è il formato più usato oggi?

JSON domina il web, senza dubbio, è il formato di default per API REST e configurazione frontend. YAML regna nel DevOps e nell'infrastruttura, soprattutto nelle pipeline CI e nelle definizioni di container. XML resiste negli ambienti aziendali e nei formati con struttura documentale complessa. TOML è cresciuto molto nell'ecosistema degli strumenti di sviluppo. CSV resta lo standard per i dati tabellari.

Posso convertire tra formati?

Sì, nella maggior parte dei casi. JSON, YAML e TOML hanno modelli di dati simili e la conversione fra loro è quasi diretta. XML è più complesso per via di attributi e contenuto misto, ma esistono corrispondenze comuni. CSV rappresenta solo tabelle, perciò convertire in dati gerarchici o viceversa richiede decisioni su come appiattire la struttura.

Perché YAML è così problematico?

Ha una specifica molto più ampia di quanto sembri. Alcune parole chiave ("yes", "no", "on", "off") sono interpretate come booleani, i numeri con zeri iniziali possono essere letti come ottali, e l'indentazione con spazi o tab causa errori silenziosi. Le versioni più recenti (YAML 1.2) hanno risolto in parte questi punti, ma occorre stare attenti alla modalità rigorosa del parser.

JSON5 e JSONC risolvono la mancanza di commenti in JSON?

Sì, sono varianti di JSON che aggiungono commenti e un po' di flessibilità in più (virgole finali, chiavi senza virgolette). Non sono standard universali, ma sono supportati in contesti specifici come gli editor di codice. Per lo scambio fra sistemi, resta sul JSON puro per garantire compatibilità.

Quando dovrei scegliere TOML invece di YAML?

TOML è preferibile quando vuoi una sintassi pulita per la configurazione senza le trappole dell'indentazione significativa. Per file di configurazione di progetto con struttura media, TOML tende a essere meno soggetto a errori. YAML è meglio per strutture molto profonde o quando ti servono riferimenti interni e funzionalità avanzate.

Confronto Formati di Dati. JSON, YAML, XML, TOML, INI, CSV

Tabella di confronto

Formato	Commenti	Verbosità	Tipi	Leggibilità	Uso tipico
JSON .json	No	Media	Base	Media	API web, configurazione frontend
YAML .yaml / .yml	Sì	Bassa	Base	Alta	Pipeline CI/CD, infrastruttura come codice
XML .xml	Sì	Alta	Solo testo	Bassa	Sistemi aziendali, documenti, SOAP
TOML .toml	Sì	Media	Ricco	Alta	Configurazione di applicazioni, strumenti di sviluppo
INI .ini / .conf	Sì	Bassa	Solo testo	Alta	Configurazione semplice, file legacy
CSV .csv	No	Bassa	Tabellare	Media	Fogli di calcolo, esportazione dati tabellari

Formato per formato

JSON.json

JavaScript Object Notation

Formato derivato dalla sintassi degli oggetti JavaScript. È diventato la lingua franca dello scambio dati sul web grazie alla semplicità e al supporto nativo in ogni linguaggio moderno.

Esempio

{
  "server": {
    "host": "localhost",
    "port": 8080,
    "debug": false,
    "tags": ["web", "api"]
  }
}

Pro

+Supportato nativamente da praticamente tutti i linguaggi
+Sintassi semplice e prevedibile
+Parsing veloce ed economico
+Struttura gerarchica chiara

Contro

−Non ammette commenti, cosa che limita l'uso nei file di configurazione modificati a mano
−Poco tollerante agli errori di sintassi (una virgola di troppo e il parsing fallisce)
−Verboso per configurazioni lunghe a causa di virgolette e parentesi graffe obbligatorie

Quando usarlo

Richieste e risposte di API REST, archiviazione di dati strutturati, comunicazione tra servizi. Ovunque la leggibilità sia secondaria rispetto all'interoperabilità.

YAML.yaml / .yml

YAML Ain't Markup Language

Formato pensato per la leggibilità umana, con sintassi basata sull'indentazione invece che sulle parentesi graffe. È un soprainsieme di JSON.

Esempio

server:
  host: localhost
  port: 8080
  debug: false
  tags:
    - web
    - api

Pro

+Molto leggibile, senza rumore visivo di parentesi e virgolette
+Supporta commenti e riferimenti interni
+Eccellente per file modificati manualmente
+Strutture complesse con poca sintassi

Contro

−L'indentazione significativa è una fonte comune di bug (tab vs spazi)
−Specifica ampia con casi limite sorprendenti ("yes" e "no" interpretati come booleani)
−Parsing più lento e dipendente da librerie esterne in alcuni linguaggi

Quando usarlo

Pipeline CI/CD, definizioni di container, configurazione di orchestratori e qualunque file di configurazione lungo che benefici di commenti e struttura chiara.

XML.xml

Extensible Markup Language

Formato basato su tag con radici in SGML. Per anni è stato lo standard dello scambio di dati strutturati prima che JSON prendesse il sopravvento.

Esempio

<server>
  <host>localhost</host>
  <port>8080</port>
  <debug>false</debug>
  <tags>
    <tag>web</tag>
    <tag>api</tag>
  </tags>
</server>

Pro

+Schemi formali maturi (XSD, DTD) per validazione rigorosa
+Buon supporto per i metadati tramite attributi e namespace
+Ecosistema potente di trasformazioni con XSLT e interrogazioni con XPath
+Ideale per documenti con contenuto misto (testo e struttura)

Contro

−Molto verboso, i tag di apertura e chiusura raddoppiano il volume
−La distinzione fra attributi ed elementi è arbitraria e divisiva
−Più difficile da leggere e scrivere a mano rispetto alle alternative moderne

Quando usarlo

Integrazioni con sistemi legacy o aziendali, documenti con struttura complessa, formati dove la validazione rigorosa per schema è obbligatoria (fatturazione elettronica, file da ufficio).

TOML.toml

Tom's Obvious Minimal Language

Formato relativamente recente, pensato per essere ovvio e privo di ambiguità. Unisce sezioni in stile INI con tipi di dati ricchi e supporto per strutture annidate.

Esempio

[server]
host = "localhost"
port = 8080
debug = false
tags = ["web", "api"]

Pro

+Specifica corta senza casi ambigui
+Tipi nativi per date, numeri e array
+Supporta commenti e sezioni con nome
+Equilibrio fra leggibilità e parsing affidabile

Contro

−Meno universale, fuori dagli ecosistemi che lo hanno adottato risulta esotico
−Le strutture profondamente annidate diventano più verbose che in YAML
−Comunità ancora in crescita, meno strumenti ausiliari

Quando usarlo

File di configurazione di progetti moderni, manifest di pacchetti, qualunque caso in cui vuoi sintassi pulita senza le insidie dell'indentazione di YAML.

INI.ini / .conf

Initialization File

Uno dei formati più antichi ancora in uso. Strutturato in sezioni fra parentesi quadre e coppie chiave valore. Non esiste una specifica formale unica, il che produce varianti incompatibili.

Esempio

[server]
host = localhost
port = 8080
debug = false
tags = web,api

Pro

+Estremamente semplice da leggere e scrivere
+Banale da parsare, anche con codice proprio
+Supportato da molti sistemi operativi e strumenti
+Accetta commenti e sezioni

Contro

−Senza standard formale, ogni implementazione differisce
−Niente gerarchie profonde oltre una singola sezione
−Tutti i valori sono stringhe, la conversione di tipo spetta all'applicazione
−Niente supporto nativo per liste strutturate

Quando usarlo

Configurazione piatta di piccoli strumenti, file utente su sistemi Windows e Linux, casi in cui la semplicità vale più delle funzionalità.

CSV.csv

Comma-Separated Values

Formato per dati tabellari: una riga per record, valori separati da virgole. Esiste da decenni e resta il pane quotidiano dello scambio fra fogli di calcolo, database e strumenti di analisi.

Esempio

host,port,debug,tags
localhost,8080,false,"web,api"
example.com,443,true,"web"

Pro

+Universale fra fogli di calcolo, database e strumenti statistici
+Compatto per dati puramente tabellari
+Lo streaming riga per riga permette file enormi
+Modificabile in qualunque strumento, da Excel a Vim

Contro

−Niente gerarchia, solo una tabella piatta
−Niente tipi, tutto è stringa senza distinzione fra numero e testo
−La gestione di virgolette, virgole nei valori e a capo è una classica fonte di bug
−Variazioni regionali (virgola vs punto e virgola come separatore)

Quando usarlo

Esportazione di report, importazione in fogli di calcolo, dataset per analisi statistica, qualunque scenario in cui i dati sono davvero tabellari.

Informazioni su questo strumento

Confronto diretto fra sei formati di serializzazione molto usati: JSON, YAML, XML, TOML, INI e CSV. Per ciascuno vedi la sintassi fianco a fianco, punti di forza, punti deboli e il contesto in cui ha senso sceglierlo. Utile per decidere il formato di configurazione di un'applicazione nuova, per aggiornarsi velocemente su un formato che non conosci, o per sostenere una decisione tecnica con argomenti concreti.

Come si usa

Leggi la tabella di confronto per avere un quadro delle caratteristiche di ciascun formato.
Confronta gli esempi fianco a fianco. Tutti rappresentano lo stesso oggetto per facilitare il confronto.
Decidi in base al contesto. Alcuni formati sono migliori per la configurazione modificata a mano, altri per lo scambio fra sistemi.

Domande frequenti

Qual è il formato più usato oggi?: JSON domina il web, senza dubbio, è il formato di default per API REST e configurazione frontend. YAML regna nel DevOps e nell'infrastruttura, soprattutto nelle pipeline CI e nelle definizioni di container. XML resiste negli ambienti aziendali e nei formati con struttura documentale complessa. TOML è cresciuto molto nell'ecosistema degli strumenti di sviluppo. CSV resta lo standard per i dati tabellari.
Posso convertire tra formati?: Sì, nella maggior parte dei casi. JSON, YAML e TOML hanno modelli di dati simili e la conversione fra loro è quasi diretta. XML è più complesso per via di attributi e contenuto misto, ma esistono corrispondenze comuni. CSV rappresenta solo tabelle, perciò convertire in dati gerarchici o viceversa richiede decisioni su come appiattire la struttura.
Perché YAML è così problematico?: Ha una specifica molto più ampia di quanto sembri. Alcune parole chiave ("yes", "no", "on", "off") sono interpretate come booleani, i numeri con zeri iniziali possono essere letti come ottali, e l'indentazione con spazi o tab causa errori silenziosi. Le versioni più recenti (YAML 1.2) hanno risolto in parte questi punti, ma occorre stare attenti alla modalità rigorosa del parser.
JSON5 e JSONC risolvono la mancanza di commenti in JSON?: Sì, sono varianti di JSON che aggiungono commenti e un po' di flessibilità in più (virgole finali, chiavi senza virgolette). Non sono standard universali, ma sono supportati in contesti specifici come gli editor di codice. Per lo scambio fra sistemi, resta sul JSON puro per garantire compatibilità.
Quando dovrei scegliere TOML invece di YAML?: TOML è preferibile quando vuoi una sintassi pulita per la configurazione senza le trappole dell'indentazione significativa. Per file di configurazione di progetto con struttura media, TOML tende a essere meno soggetto a errori. YAML è meglio per strutture molto profonde o quando ti servono riferimenti interni e funzionalità avanzate.

JSON vs YAML vs XML vs TOML vs INI vs CSV

Informazioni su questo strumento

Come si usa

Domande frequenti

Strumenti correlati