Articolo
Conversione tra CSV, XML, JSON e YAML: una guida pratica
CSV, JSON, XML e YAML sono i quattro formati che gli sviluppatori incontrano più spesso in pipeline di dati, file di configurazione e API. Convertire tra loro è semplice quando i modelli di dati corrispondono, e sorprendentemente distruttivo quando non corrispondono. Questa guida spiega cosa ogni formato può e non può rappresentare, dove le informazioni scompaiono durante la conversione e i rischi di codifica che causano corruzione silenziosa. Lo strumento data-converter di questo sito gestisce tre dei quattro formati (CSV, JSON e YAML) interamente nel browser; le sezioni su XML qui servono come base quando sposti i dati a mano o con uno strumento separato.
I quattro formati e i loro modelli di dati
CSV organizza i dati come una griglia piatta di righe e colonne. La prima riga tipicamente nomina le colonne; ogni riga successiva è un record. Non esiste annidamento, nessuna informazione di tipo e nessuno standard per nulla al di là del testo normale nelle celle. Ogni valore è una stringa a meno che l'applicazione che lo consuma non imponga un tipo. JSON modella i dati come un albero di oggetti (mappe chiave-valore) e array. I valori possono essere stringhe, numeri, booleani, null, oggetti annidati o array di qualsiasi profondità. Questo consente a un singolo documento JSON di rappresentare un record cliente con oggetti indirizzo incorporati, array di voci e totali numerici tipizzati. XML modella i dati come un albero di elementi. Ogni elemento può avere attributi nominati e contenere elementi figli o contenuto testuale. Non esiste un tipo numerico o booleano integrato; tutto è testo. Gli schemi come XSD possono imporre tipi al momento della validazione, ma il formato trasmesso è sempre dati di caratteri. YAML usa l'indentazione per esprimere lo stesso modello oggetto-e-array di JSON, con una sintassi più leggibile. YAML è un superset di JSON: qualsiasi documento JSON valido è anche YAML valido. Aggiunge stringhe multi-riga, commenti e riferimenti ancora-alias per blocchi ripetuti. YAML è comune nei file di configurazione; JSON è comune nelle risposte API.
Conversioni con perdita: appiattimento e l'ambiguità XML
La conversione con perdita più comune è l'appiattimento di JSON o XML annidato in CSV. Un oggetto JSON con un campo indirizzo annidato non può mappare chiaramente a una riga CSV. La soluzione tipica è usare nomi di colonne con notazione a punti: customer.address.city diventa la propria colonna. Questo funziona per un livello di annidamento, ma si interrompe completamente quando appare un array. Un cliente con tre numeri di telefono richiede tre colonne separate (codificando il conteggio massimo), la suddivisione in un secondo file CSV o la codifica dell'array come stringa delimitata in una singola cella. Nessuna di queste opzioni torna al JSON originale senza metadati aggiuntivi. XML introduce un'ambiguità separata: la scelta tra attributo ed elemento figlio. Il valore Paris potrebbe essere memorizzato come attributo (<city name="Paris">) o come elemento figlio (<city><name>Paris</name></city>). Quando un convertitore legge XML e produce JSON, deve decidere come mappare gli attributi. Le convenzioni comuni includono il prefissare le chiavi degli attributi con @ o il posizionarle sotto una chiave "_attributes". La scelta non è standardizzata, il che significa che due convertitori che leggono lo stesso XML possono produrre JSON strutturalmente diverso. Se si prevede di trasferire dati tra XML e JSON, stabilire una convenzione prima di iniziare.
Insidie CSV: delimitatori, virgolette e codifica
CSV non ha un unico standard formale, solo RFC 4180 come riferimento ampiamente citato. Il delimitatore più comune è la virgola, ma i punti e virgola (comuni nelle localizzazioni europee dove le virgole servono come separatori decimali), le tabulazioni (TSV) e i caratteri pipe compaiono tutti nella pratica. Un file chiamato .csv può usare qualsiasi di questi senza indicare quale. Quando un valore di campo contiene il delimitatore stesso, RFC 4180 richiede di racchiudere il campo tra virgolette doppie: "San Francisco, CA". Una virgoletta doppia all'interno di un campo tra virgolette deve essere preceduta da escape raddoppiandola: "He said ""hello""". Un campo contenente un'interruzione di riga letterale deve essere anch'esso tra virgolette. I parser che saltano questo passaggio producono errori nel conteggio delle righe difficili da tracciare. La codifica è una trappola separata. I file CSV degli strumenti Windows spesso contengono un UTF-8 BOM (byte order mark: i tre byte EF BB BF all'inizio del file). Il BOM aiuta Excel a identificare la codifica, ma molti parser di linguaggi di programmazione trattano il BOM come parte del primo nome di colonna, producendo una colonna denominata "id" invece di "id". Questo rompe qualsiasi codice a valle che cerca le colonne per nome. Quando si legge un file CSV a livello di programmazione, rimuovere il BOM prima di analizzarlo, o usare una libreria che lo gestisce esplicitamente.
Scelta del formato: configurazione, scambio e fogli di calcolo
La scelta del formato è di solito determinata dal contesto, non dalla preferenza. JSON è il predefinito per le REST API e lo scambio tra browser e server. È compatto, analizzato nativamente in ogni linguaggio di programmazione e porta informazioni di tipo per numeri e booleani. Il suo punto debole è l'assenza di commenti, il che lo rende inadatto per file che gli sviluppatori leggono e modificano a mano. YAML è preferito per i file di configurazione (manifest Kubernetes, definizioni di pipeline CI, playbook Ansible) perché consente commenti in linea ed è più facile da leggere di JSON con molti livelli di indentazione. Il suo rischio principale è che gli errori di indentazione sono silenziosi: una chiave mal indentata si sposta in un ambito diverso senza alcun errore di analisi. XML rimane standard nei sistemi aziendali più vecchi, nei servizi web SOAP, nei formati di documento (DOCX, SVG, RSS) e nei contesti che richiedono validazione dello schema o disambiguazione degli spazi dei nomi. È verboso, ma gli strumenti XPath e XSLT sono maturi. CSV è la scelta giusta quando i dati sono genuinamente piatti e il consumatore è un'applicazione per fogli di calcolo o un analista di dati. Non è adatto per la configurazione o lo scambio API perché non ha un sistema di tipi e non supporta l'annidamento.
Farlo localmente con data-converter
Lo strumento data-converter su questo sito analizza e converte tra CSV, JSON e YAML interamente all'interno del browser; non legge né scrive XML. Nessun dato viene trasmesso a un server in nessun momento. La conversione viene eseguita nel runtime JavaScript locale e l'output è disponibile per il download o la copia senza che nulla lasci il dispositivo. Questo è importante per i dati che non si è autorizzati a condividere: risposte API contenenti informazioni personali, file di configurazione con nomi host interni o esportazioni CSV da database interni. Incollare questi dati in un convertitore web che gira su un server significa che il contenuto viene inviato sulla rete ed elaborato su hardware che non si controlla. Con data-converter, la scheda del browser è l'ambiente di elaborazione. Lo strumento applica le virgolette RFC 4180 in lettura e scrittura CSV, e per JSON o YAML verso CSV si aspetta un array piatto di oggetti: un valore oggetto o array annidato sotto una chiave non riceve un appiattimento automatico con notazione a punti, quindi appiattisci tu stesso quei campi prima di convertire se ti servono come colonne separate. Se devi spostare dati da o verso XML, convertili prima in JSON o YAML con uno strumento XML dedicato, poi porta qui il risultato.
Strumenti citati in questo articolo
Domande frequenti
Posso convertire JSON in CSV e ottenere il risultato originale?
Solo se il JSON è un array piatto di oggetti senza campi annidati e senza array come valori. Nel momento in cui si ha un oggetto annidato o un valore array, la rappresentazione CSV richiede una decisione strutturale (colonne con notazione a punti, righe multiple o stringhe codificate) che non può essere automaticamente invertita. Se i dati hanno annidamento, JSON, XML o YAML funzioneranno correttamente; CSV no.
Perché il mio CSV appare errato in Excel dopo l'esportazione da un'applicazione europea?
Le localizzazioni europee spesso usano i punti e virgola come delimitatore CSV perché le virgole sono riservate per la notazione decimale. Excel in una localizzazione europea si aspetta i punti e virgola. Se il file usa le virgole, Excel tratta l'intera riga come una singola colonna. La soluzione è cambiare il delimitatore nelle impostazioni di esportazione, oppure usare la procedura guidata di importazione dati di Excel, che consente di specificare il delimitatore manualmente. Il problema del UTF-8 BOM è separato: senza un BOM, Excel potrebbe anche leggere erroneamente i caratteri accentati come testo incomprensibile.
Qual è la differenza tra YAML e JSON nella pratica?
Entrambi rappresentano lo stesso modello di dati sottostante: oggetti, array, stringhe, numeri, booleani e null. YAML aggiunge commenti (righe che iniziano con #), letterali di stringa multi-riga e riferimenti ancora per blocchi ripetuti. JSON è strettamente un sottoinsieme di YAML valido, ma i parser JSON non leggono YAML. La regola pratica: usa JSON per i payload API e l'archiviazione dei dati; usa YAML per i file di configurazione che gli esseri umani modificano e che traggono vantaggio dai commenti in linea.