Cookie di statistica e di pubblicità
Usiamo cookie di statistica e di pubblicità, entrambi inviati a Google. Rifiutare non cambia niente di quello che vedi.Leggi la pagina sulla privacy
Qui converti JSON in CSV gratis e senza account: trascina il file qui sopra e in un paio di secondi il risultato è pronto da scaricare. La conversione avviene dentro il tuo browser, quindi il file non viene mai caricato. Funziona allo stesso modo su Windows, macOS e Linux e anche su iPhone e Android, e continua a funzionare anche se stacchi la connessione.
Fino a 100 file alla volta. Formati diversi insieme non sono un problema.
Vengono convertiti uno dopo l’altro e scaricati insieme in uno ZIP.
JSON in CSV
Questa è la cosa da capire prima di convertire qualsiasi cosa. JSON descrive un albero: un oggetto può contenerne un altro, che può contenere un array di oggetti, a qualsiasi profondità. Un CSV descrive una griglia: righe e colonne, e niente dentro una cella.
Quindi la conversione non è una traduzione fra due modi di scrivere la stessa cosa. È una proiezione, e qualcosa deve cedere. Per dati che sono davvero un elenco di record piatti, che è la maggior parte delle esportazioni, nulla va perso. Per qualcosa di strutturato in profondità, il CSV è un’approssimazione leggibile e il JSON resta il file vero, ed è una distinzione che va capita prima di prendere l’uno per l’altro.
Un oggetto annidato viene appiattito unendo i nomi delle chiavi, quindi un record con un cliente che contiene una città produce una colonna che porta entrambi i nomi. Un livello di annidamento produce una tabella che chiunque può leggere. Due è di solito ancora accettabile.
Oltre degrada rapidamente: i nomi delle colonne diventano lunghi, la tabella diventa molto larga, e la maggior parte delle celle nella maggior parte delle righe sono vuote perché record diversi annidano in modo diverso. Se una conversione produce sessanta colonne da quello che sembrava un’esportazione semplice, è la forma dei dati che traspare, non un difetto della conversione.
Un record con tre tag, quattro voci, o un elenco di indirizzi precedenti non ha una rappresentazione corretta in una tabella. Ci sono tre risposte abituali e ognuna è sbagliata per qualcosa: una colonna per posizione, che si rompe quando un record ne ha cinque; una colonna con i valori uniti da un separatore, che è inutilizzabile se i valori contengono quel separatore; o una riga per elemento dell’array, che duplica il record genitore e cambia ciò che una riga significa.
Quando gli array portano il significato, un ordine con le voci, un post con i commenti, la risposta onesta è non convertire. O tenere il JSON, o produrre due tabelle come farebbe un database: una per gli ordini e una per le voci, collegate da un identificatore, che è la forma che effettivamente si può interrogare senza acrobazie.
I record in un’esportazione JSON non sono obbligati ad avere le stesse chiavi. Un’API restituisce i campi che esistono e omette quelli che non esistono, quindi cento record possono presentare ottanta forme diverse, e nessun campo obbligatorio è garantito.
La conversione risolve la cosa guardando attraverso i record per costruire l’insieme completo delle colonne e lasciando una cella vuota dove un record non ha un valore. Questo è normalmente ciò che si vuole, e spiega una sorpresa frequente: convertire un campione di dieci record produce meno colonne che convertire il file intero, perché il campione non conteneva i campi più rari. Prendere lo schema da una conversione dell’intero export, mai dal campione con cui si è testato.
Produrre un CSV corretto non lo protegge da ciò che succede dopo. Excel ne apre uno indovinando un tipo per colonna, il che toglie gli zero iniziale dai codici, converte qualunque cosa assomigli a una data in una data, e tronca gli identificativi oltre le quindici cifre.
Il rimedio è sempre lo stesso: importare invece di aprire, Dati → Da testo/CSV, e impostare le colonne di identificativi come Testo prima del caricamento. Se il destinatario è una persona invece di un programma, convertire in XLSX elimina del tutto l’indovinare, perché i tipi sono dichiarati nel file, ed è il formato da preferire quando c’è un collega dall’altra parte.
Convertire quando i dati sono record piatti e la destinazione è un foglio di calcolo, un import in un database, uno strumento statistico o un collega. Questo copre la maggior parte delle esportazioni da piattaforme di analisi, CRM, builder di moduli e API di reportistica, e il CSV è più facile per ognuna di esse di quanto lo fosse il JSON.
Non convertire quando la struttura è il contenuto: un file di configurazione, una risposta API annidata che si intende usare in modo programmatico, qualunque cosa con array significativi. E tenere il JSON in entrambi i casi: è il file che continua a contenere tutto, e rigenerare un CSV da esso richiede pochi secondi, anche se la domanda iniziale era «come apro questa cosa».
Le esportazioni di dati dai servizi di intelligenza artificiale sono ormai una delle ragioni più comuni per cui qualcuno apre un file JSON, e l’archivio di ChatGPT è il solito caso. Il suo `conversations.json` non è un elenco di righe: è un insieme di alberi di messaggi, ogni nodo che punta al proprio genitore, che è il modo in cui le conversazioni ramificate e modificate sono rappresentate. Dentro non c’è una griglia onesta.
Convertirlo in CSV produce qualcosa di tecnicamente valido e praticamente inutilizzabile: una riga per nodo, con la struttura del thread andata. Se l’obiettivo è rileggere le proprie conversazioni, il file HTML esportato nello stesso archivio è ciò che aprire. Il CSV è la destinazione giusta per le esportazioni più piatte accanto ad esso, come record di utilizzo e fatturazione, dove ogni voce è davvero una riga, ed è la distinzione che vale la pena fare prima di convertire l’intero archivio.
Un array JSON deve essere completo prima di poter essere analizzato, perché la parentesi di chiusura è ciò che lo rende valido. Quindi un file molto grande deve essere letto intero, e questa è una proprietà del formato invece che di un qualsiasi strumento.
Se si controlla come i dati sono prodotti, chiedere NDJSON, un oggetto JSON completo per riga, invece di un singolo array grande. Va ancora letto in memoria intero qui, come un array, ma ogni riga è analizzata per conto suo: una riga corrotta o troncata fallisce con il proprio numero di riga invece di invalidare l’intero documento. È ciò che le pipeline di log e le esportazioni di dati grandi usano per questa ragione, e ogni strumento che legge JSON lo legge con un cambio di una riga, che è il tipo di dettaglio che fa risparmiare un pomeriggio.
La conversione gira nel browser sul proprio processore. Il file non viene mai spedito, non c’è account né tetto giornaliero, e un file fino a 100 MB viene gestito nella scheda.
Questo vale di più qui che sulla maggior parte delle conversioni. Un’esportazione JSON è quasi sempre l’output grezzo di un’API, record di clienti, storie di ordini, submission di moduli, account utente, e di solito contiene campi a cui nessuno ha pensato perché nessuno si aspettava di doverli leggere. Non spedirlo da nessuna parte è la risposta semplice, ed è l’unica che non richiede di fidarsi di qualcun altro per il contenuto.
| JSON | CSV | |
|---|---|---|
| Nome completo | JavaScript Object Notation | Comma-Separated Values |
| Estensione del file | .json | .csv |
| Tipo di media | application/json | text/csv |
| Prima pubblicazione | 2001 | 1972 |
| Specifica | RFC 8259 | RFC 4180 |
| Licenza | Standard aperto | Standard aperto |
| Situazione attuale | Attuale | Attuale |
| Si apre nel browser | Tutti i browser | Nessun browser |
| Valutato al suo posto | XML, YAML, NDJSON | XLSX, Parquet |
Nessun browser legge CSV. È il meno trasportabile dei due: meglio assicurarsi che chi lo riceve lo accetti prima di inviarlo.
I programmi di sempre non coincidono: JSON si apre in Visual Studio Code, jq e Postman, CSV in Microsoft Excel, LibreOffice Calc e pandas, quindi chi riceve il risultato ha bisogno di uno del secondo gruppo.
JSON è stato pubblicato nel 2001. È descritto in RFC 8259, e vale la pena conoscerlo se il file deve sopravvivere allo strumento che lo ha scritto.
CSV risale al 1972, descritto in RFC 4180. Microsoft Excel, LibreOffice Calc e pandas lo leggono.
CSV è stato pubblicato nel 1972 e JSON nel 2001. Il più vecchio è in genere il file più sicuro da consegnare; il più recente fa lo stesso lavoro con meno byte.
No. Questa conversione avviene interamente nel tuo browser, quindi il file non esce dal tuo dispositivo. Puoi controllarlo da solo: apri la scheda di rete degli strumenti per sviluppatori e converti qualcosa. Vedrai la pagina stessa e le richieste di statistica e di pubblicità con cui questo servizio si paga, e nemmeno una che porti il tuo file.
Sì. Senza account, senza filigrana e senza una quota giornaliera da consumare: gira sulla tua macchina, quindi puoi tornare quante volte vuoi. Il browser lavora file fino a 100 MB, 100 per volta.
JSON e CSV descrivono il contenuto in modi radicalmente diversi. La conversione è quindi una ricostruzione e non una copia: fedele, ma non identica byte per byte. Gli oggetti annidati vengono appiattiti in colonne. I dati molto annidati perdono la loro forma.
Nessun browser legge CSV. È il meno trasportabile dei due: meglio assicurarsi che chi lo riceve lo accetti prima di inviarlo.