JSON, XML o CSV? Come Scegliere il Formato di Dati Giusto per il Compito
13 ottobre 2026
JSON, XML e CSV esistono tutti per spostare dati strutturati tra sistemi, ma trattarli come intercambiabili è il modo in cui i progetti di integrazione finiscono con dati persi, importazioni rotte, o file gonfiati. Ogni formato ha fatto veri compromessi di progettazione per i problemi e le epoche per cui è stato costruito, e conoscere questi compromessi rende semplice scegliere quello giusto per un dato compito.
In cosa è davvero bravo il CSV, e dove si rompe?
Il CSV (comma-separated values, valori separati da virgola) è tra i formati strutturati più semplici che esistano — testo semplice, una riga per riga, valori separati da virgole — il che lo rende leggibile universalmente da software di fogli di calcolo, database e praticamente ogni strumento di dati mai costruito. È eccellente per dati piatti e tabellari: un elenco di record dove ogni riga ha gli stessi campi. Si rompe nel momento in cui i dati hanno una vera struttura oltre una tabella piatta — oggetti annidati, relazioni uno-a-molti, o campi che contengono legittimamente virgole o interruzioni di riga (gestiti in modo incoerente tra le diverse implementazioni di CSV) spingono tutti il CSV oltre ciò per cui è stato progettato.
Perché JSON è diventato lo standard specificamente per le API web?
La struttura a oggetti e array di JSON si mappa quasi direttamente sul modo in cui la maggior parte dei linguaggi di programmazione moderni rappresenta già i dati in memoria, il che significa che un payload JSON può spesso essere analizzato direttamente in una struttura dati nativa con un lavoro di traduzione minimo — un vantaggio pratico importante per le API web dove contano velocità e semplicità sia nel produrre che nel consumare dati. È anche comparativamente compatto e leggibile dall'uomo, trovando un equilibrio che lo ha reso lo standard naturale con il proliferare delle API web, soppiantando in gran parte XML nella progettazione di nuove API anche se XML è arrivato prima.
Cosa può fare XML che JSON strutturalmente non può?
XML supporta attributi sugli elementi (metadati collegati a un tag stesso, distinti dal suo contenuto), namespace (evitando collisioni di nomi quando si combinano vocabolari da fonti diverse), e un ecosistema maturo e formale di validazione dello schema (XSD) per definire e imporre rigorosamente esattamente cosa deve contenere un documento valido — capacità che il modello più semplice a oggetti/array di JSON non fornisce nativamente (JSON Schema esiste ma è arrivato più tardi ed è meno universalmente adottato). Questo è il motivo per cui XML persiste in domini che richiedono validazione rigorosa dei documenti, documenti con vocabolario misto, o standard di dati aziendali e governativi consolidati da tempo che precedono l'ascesa di JSON.
Perché convertire CSV in un formato annidato come JSON richiede più di una conversione meccanica?
Il CSV non ha alcun concetto di annidamento — ogni riga è piatta — quindi convertire dati CSV in un formato che supporta la gerarchia (come JSON che rappresenta, per esempio, un ordine con più righe di dettaglio) richiede una decisione reale su come le righe piatte si mappano su una struttura annidata: ogni riga diventa un oggetto separato di primo livello, o più righe che condividono un ID vengono raggruppate in un unico oggetto con un array annidato? Quella decisione di mappatura non è recuperabile dai soli dati CSV — dipende dalla comprensione delle relazioni reali dei dati, motivo per cui "converti semplicemente il mio CSV in JSON" a volte produce un risultato tecnicamente valido ma praticamente inutilizzabile se la struttura non è stata specificata.
La dimensione del file o la velocità di analisi differiscono in modo significativo tra i tre formati?
Il CSV è generalmente il più compatto per dati genuinamente piatti e uniformi poiché ha quasi nessun overhead strutturale — nessun nome di tag o di chiave ripetuto per record. JSON è più compatto di XML per gli stessi dati annidati perché manca della ridondanza dei tag di chiusura di XML, ma include più overhead del CSV a causa dei nomi di chiave ripetuti in ogni oggetto, a meno che non si usi una codifica più compatta basata su array. XML è tipicamente il più grande dei tre per dati equivalenti a causa dei verbosi tag di apertura e chiusura, anche se questo è raramente il fattore decisivo rispetto a quali capacità strutturali ed ecosistema di strumenti richiede davvero una data integrazione.