Per convertire JSON annidati in CSV, usa un convertitore online da JSON a CSV che ti permetta di scegliere quale array JSON deve diventare l’insieme delle righe del CSV. Questa scelta è più importante di quanto si pensi. Le esportazioni JSON reali spesso iniziano con metadati, informazioni di paginazione o oggetti contenitore, mentre i record utili si trovano in un percorso come results, data.items o payload.records.
Di solito, considero la conversione da JSON a CSV come un insieme di tre decisioni:
- Quale array deve diventare l’insieme delle righe?
- Quali campi degli oggetti annidati devono diventare colonne?
- Quali array devono essere uniti, mantenuti come JSON o espansi in righe separate?
Una volta risposto a queste domande, il resto segue un normale workflow CSV. Puoi visualizzare l’anteprima, controllare le colonne e scaricare un file CSV utilizzabile in un foglio di calcolo, un CRM, uno strumento di BI o un processo di pulizia dei dati.
📌 In breve
Per prima cosa, stabilisci che cosa deve rappresentare ogni riga del CSV. In questo esempio voglio una società per riga, quindi il row node è
$.results. A quel punto posso appiattire le metriche aziendali e decidere come gestire array qualicontactsetags.
In questa guida userò un’esportazione JSON annidata contenente 20.000 record aziendali sotto results. Lo stesso workflow funziona con risposte API, risultati di scraping, log di webhook, esportazioni CRM e dati di marketplace nei quali i record utili non si trovano alla radice del JSON.
Link rapidi:
- Esempio di file JSON annidato
- Convertire JSON annidati in CSV con Datablist
- Scegliere il row node corretto
- Appiattire gli oggetti JSON annidati
- Gestire gli array nelle righe JSON
- Controllare e scaricare il CSV
Esempio di file JSON annidato
Per questo esempio, immaginiamo una grande esportazione JSON proveniente da un’API o da uno strumento di scraping. Il file pesa circa 8,8 MB e contiene 20.000 record in un array results di primo livello.
L’oggetto radice si presenta così:
{
"meta": {
"generatedAt": "2026-07-04T10:00:00Z",
"source": "stress_test"
},
"results": [
{
"id": 0,
"name": "NbDXeG4Gyg",
"website": "https://example-0.com",
"contacts": [
{
"name": "Ava Martin",
"emails": ["ava@example-0.com"],
"phones": ["+1 555 0100"]
},
{
"name": "Noah Lee",
"emails": ["noah@example-0.com"],
"phones": []
}
],
"tags": "enterprise",
"metrics": {
"employees": 124,
"revenue": {
"amount": 476171,
"currency": "USD"
}
},
"createdAt": "2026-06-25T09:12:00Z"
},
{
"id": 1,
"name": "DwwGmkzmBi",
"website": "https://example-1.com",
"contacts": [
{
"name": "Mia Chen",
"emails": ["mia@example-1.com"],
"phones": ["+1 555 0101"]
}
],
"tags": ["saas", "mid-market"],
"metrics": {
"employees": 47,
"revenue": null
},
"createdAt": "2026-06-26T14:33:00Z"
}
]
}
È proprio il tipo di file che mette in difficoltà i convertitori più semplici. I record non coincidono con l’oggetto radice, ma si trovano all’interno di results. Contengono inoltre oggetti e array annidati, valori che possono essere sia stringhe sia array, valori null e date.
🔍 Perché questo file è un buon test
Un array JSON piatto verifica soltanto il caso più semplice. Questo file mette alla prova le scelte che contano nelle esportazioni reali: metadati contenitore, un array di record annidato, campi oggetto, campi array, valori misti e null.
Ecco la struttura delle prime righe:
| Riga | Formato di Website | Numero di contatti | Formato di Tags | Fatturato |
|---|---|---|---|---|
| 0 | Stringa | 2 | Stringa | Importo e valuta |
| 1 | Stringa | 2 | Array | Null |
| 2 | Array | 1 | Array | Null |
Il CSV finale deve avere una riga per società. Voglio colonne per campi utili quali id, name, website, employees, amount, currency e createdAt. Per campi come contacts e tags, devo scegliere quanta parte della struttura conservare.
Convertire JSON annidati in CSV con Datablist
Apri il convertitore JSON di Datablist. Puoi incollare il JSON nell’editor oppure caricare un file .json.
Per una risposta API di piccole dimensioni, incollare il contenuto va benissimo. Per un’esportazione più grande, preferisco caricare il file, così evito che un copia-incolla incompleto tronchi accidentalmente i dati. Il contenuto viene letto nel browser e la conversione viene eseguita localmente, senza inviare il file ai server di Datablist per elaborarlo.
Una volta caricato il JSON, Datablist ne analizza la struttura e cerca gli array di oggetti. Accetta come radice JSON sia array sia oggetti, quindi esamina percorsi annidati come $.results, $.data.items o array ancora più profondi.
Se il file è difficile da interpretare, a volte apro prima il JSON in JSONCrack. La visualizzazione ad albero aiuta a individuare l’array che deve diventare l’insieme delle righe. È un passaggio facoltativo, ma utile quando il file contiene diversi array possibili.
In questo esempio, il row node corretto è:
$.results
Scelgo $.results perché voglio una società per riga. Ogni elemento dell’array diventa una riga del CSV.
Datablist può suggerire un row node, ma preferisco comunque verificarlo manualmente. È qui che si verifica la maggior parte degli errori di conversione. Un file JSON può contenere un array principale di società, un array secondario di contatti e un altro array di tag o eventi. Sono tutti array, ma soltanto uno corrisponde al CSV che vuoi ottenere.
⚠️ Cambiare il row node cambia il dataset
$.resultse$.results[].contactssono entrambi row node validi, ma non generano lo stesso CSV. Scegli l’array principale se vuoi righe relative agli account. Scegli l’array secondario se il dataset è costituito dagli elementi annidati.
Per questo articolo mantengo il row node principale:
$.resultssignifica una società o un account per riga.$.results[].contactssignificherebbe un contatto per riga.
Anche la seconda opzione può essere corretta, ma cambia l’output. Un CSV a livello di contatto è utile quando vuoi ottenere un elenco di persone. Un CSV a livello aziendale è più adatto per pulire gli account, arricchire i dati delle società, importare record in un CRM o analizzare le metriche.
Scegliere il row node corretto
Un row node è l’array JSON i cui elementi diventano le righe del CSV.
Gli esempi più comuni sono questi:
| Percorso JSON | Quando usarlo |
|---|---|
$.results | I record sono memorizzati sotto una chiave results |
$.data.items | Un’API racchiude i record in un oggetto data |
$.payload.records | Un webhook o un’esportazione interna racchiude i record sotto payload |
$.results[].contacts | Vuoi un contatto annidato per riga |
Prima di scegliere, di solito mi pongo una domanda: che cosa deve rappresentare una singola riga?
Se ogni riga deve rappresentare una società, un account, un ordine, un prodotto, un annuncio o un evento, scegli l’array principale. Se invece deve rappresentare un contatto, un’email, una voce d’ordine, un prezzo, un commento o un evento secondario, scegli l’array figlio.
Sembra semplice, ma questa scelta cambia l’intero CSV.
Con $.results, il CSV conserva il contesto aziendale. Il campo contacts rimane nella riga della società come valore annidato, a meno che tu non decida di elaborare i contatti separatamente. Con $.results[].contacts, il CSV diventa un elenco di contatti, ma i campi della società principale non vengono inclusi automaticamente, a meno che il convertitore non introduca questa funzione in una versione futura.
Di norma parto dall’array principale. È l’opzione più sicura per la prima esportazione, perché posso comunque esaminare in seguito gli array annidati. Passo a un array figlio soltanto quando sono i suoi elementi a costituire il vero dataset.
Appiattire gli oggetti JSON annidati
È nella gestione degli oggetti annidati che un convertitore CSV deve offrire qualcosa in più rispetto a una semplice trasformazione di file.
Nel file di esempio, metrics è un oggetto:
{
"metrics": {
"employees": 124,
"revenue": {
"amount": 476171,
"currency": "USD"
}
}
}
In un foglio di calcolo non voglio una singola cella metrics contenente un oggetto JSON. Voglio colonne che sia possibile filtrare e ordinare:
employeesamountcurrency
Datablist rileva i percorsi degli oggetti annidati e ti consente di scegliere quali appiattire. Mantengo appiattiti i campi scalari utili, perché sono più facili da gestire negli strumenti CSV.
In questo esempio, appiattisco:
metrics.employeesinemployeesmetrics.revenue.amountinamountmetrics.revenue.currencyincurrency
Il CSV previsto a livello aziendale si presenta così:
| Colonna CSV | Valore di origine |
|---|---|
id | Identificativo della riga |
name | Nome della società o dell’account |
website | Valore del sito web, array unito o stringa JSON in base alle impostazioni |
contacts | Dati di contatto annidati quando si esporta una società per riga |
tags | Etichette unite o testo originale |
employees | Valore di metrics.employees |
amount | Valore di metrics.revenue.amount |
currency | Valore di metrics.revenue.currency |
createdAt | Data originale o formattata |
Per la prima esportazione preferisco nomi di colonna facili da leggere. Se il file contiene nomi ripetuti in oggetti diversi, controlla l’anteprima prima di scaricarlo. Per esempio, billing.amount e revenue.amount non dovrebbero essere entrambi ridotti a una colonna ambigua chiamata amount senza un controllo.
💡 La mia regola per appiattire i dati
Appiattisci i campi scalari che vuoi filtrare, ordinare o importare come colonne. Mantieni gli oggetti o gli array strutturati in formato JSON quando l’appiattimento rischia di nasconderne il significato o creare celle illeggibili.
Gestire gli array nelle righe JSON
Gli array richiedono una decisione separata: le celle CSV contengono testo, mentre gli array JSON possono rappresentare elementi molto diversi.
Un elenco di tag non equivale a un elenco di contatti. Un elenco di email non equivale alle righe di un ordine. Evito quindi di applicare un’unica regola generale quando gli array hanno significati differenti.
Per il file di esempio userei queste impostazioni:
| Campo | Gestione consigliata | Motivo |
|---|---|---|
tags | Unisci i valori | I tag sono semplici etichette e funzionano bene in una sola cella |
website | Unisci i valori o mantieni il JSON | Uniscili per una maggiore leggibilità; mantieni il JSON se è importante conservare i diversi formati |
contacts | Mantieni il JSON per le righe aziendali | Gli oggetti dei contatti hanno campi annidati propri |
contacts | Usa $.results[].contacts come row node per le righe dei contatti | È preferibile quando l’elenco dei contatti è il vero output |
Datablist offre diverse opzioni per gestire gli array: unire i valori, mantenerli come stringhe JSON, prendere il primo elemento e applicare impostazioni diverse caso per caso.
La mia regola di base è semplice:
- Unisci gli array semplici, come i tag.
- Mantieni gli array strutturati come stringhe JSON se devi conservarli.
- Prendi soltanto il primo elemento quando ha un significato preciso, per esempio nel caso di un’email principale.
- Cambia il row node quando ogni elemento dell’array merita una riga propria.
Per l’esportazione aziendale mantengo contacts come valore strutturato, perché ogni contatto ha un nome, delle email e dei numeri di telefono. Appiattire tutto in una cella renderebbe il CSV disordinato, mentre prendere soltanto il primo contatto causerebbe una perdita di dati.
Per esportare i contatti, sceglierei invece $.results[].contacts. Il CSV conterrebbe quindi colonne a livello di contatto come queste:
| Colonna CSV | Valore di origine |
|---|---|
name | Nome del contatto |
emails | Elenco di email unito o stringa JSON |
phones | Elenco di numeri di telefono unito o stringa JSON |
Il compromesso riguarda il contesto. Un’esportazione aziendale mantiene intatta la riga della società. Un’esportazione dei contatti si concentra sulle persone, ma i campi della società principale non vengono copiati automaticamente in ogni riga, a meno che lo strumento non supporti questa funzione in una versione futura.
Configurare le impostazioni di output
Dopo aver configurato correttamente il row node, l’appiattimento e la gestione degli array, imposta l’output CSV.
Di solito parto da queste opzioni:
- Separatore: virgola per un CSV standard.
- Riga di intestazione: attiva.
- Formato della data: mantieni quello originale, a meno che il foglio di calcolo di destinazione non richieda un formato più leggibile.
Usa il punto e virgola quando il tuo programma o le impostazioni locali si aspettano file con questo separatore. Può essere importante nei fogli di calcolo configurati per l’Europa, dove la virgola viene spesso utilizzata come separatore decimale.
Per le date, preferisco conservare il formato di origine nella prima esportazione. I timestamp ISO sono facili da elaborare in seguito e mantengono le informazioni sul fuso orario. Se il CSV è destinato a un collega non tecnico, formattare le date può però renderlo più leggibile.
Prima del download, controlla entrambe le anteprime:
- L’anteprima della tabella consente di verificare righe e colonne.
- L’anteprima del CSV grezzo consente di controllare separatori, virgolette e interruzioni di riga.
🔑 Controlla l’anteprima prima di esportare
È nell’anteprima che puoi individuare errori nel row node, colonne mancanti, array disordinati e problemi con il separatore. Preferisco dedicare 30 secondi a questo controllo anziché dover correggere in seguito un’importazione non riuscita in un CRM o in un foglio di calcolo.
Controllo sempre l’anteprima del CSV grezzo quando sono presenti array o testi su più righe. Richiede pochi secondi e permette di rilevare un numero sorprendente di problemi di importazione.
Controllare e scaricare il CSV
Prima del download, eseguo questi controlli:
- Il numero di righe corrisponde al row node selezionato?
- Le righe rappresentano l’entità che volevo ottenere?
employees,amountecurrencysono suddivisi in colonne utili?- Gli array sono leggibili oppure conservati come JSON quando la struttura è importante?
- I valori null del fatturato sono vuoti o abbastanza chiari per il passaggio successivo?
- Le date sono adatte al foglio di calcolo o allo strumento di importazione?
- L’anteprima del CSV grezzo usa il separatore previsto?
A questo punto, scarica il CSV. Quando carichi un file, il nome del file scaricato può essere ricavato da quello originale, così è più facile risalire alla provenienza del CSV.
Dopo l’esportazione, apri il file nell’editor CSV di Datablist, in Excel, in Google Sheets o nel tuo strumento dati preferito. In Datablist puoi continuare con pulizia, filtri, deduplicazione, enrichment o traduzione. Se generi più esportazioni, puoi confrontare due file CSV. Se il file è troppo grande per un altro strumento, puoi dividerlo in file CSV più piccoli.
Risultato CSV previsto
Selezionando $.results, l’output principale contiene una società o un account per riga.
| Colonna CSV | Percorso JSON in ogni riga | Valore previsto |
|---|---|---|
id | $.id | Identificativo della riga |
name | $.name | Nome della società o dell’account |
website | $.website | Stringa del sito web, array unito o stringa JSON |
contacts | $.contacts | Array di contatti unito o in formato JSON quando si mantiene una società per riga |
tags | $.tags | Etichette unite o stringa originale |
employees | $.metrics.employees | Numero di dipendenti |
amount | $.metrics.revenue.amount | Importo del fatturato, quando presente |
currency | $.metrics.revenue.currency | Valuta del fatturato, quando presente |
createdAt | $.createdAt | Data originale o formattata |
Selezionando $.results[].contacts, l’output cambia e contiene un contatto per riga.
| Colonna CSV | Percorso JSON in ogni contatto | Valore previsto |
|---|---|---|
name | $.name | Nome del contatto |
emails | $.emails | Elenco di email unito o stringa JSON |
phones | $.phones | Elenco di numeri di telefono unito o stringa JSON |
Entrambe le esportazioni sono valide, ma rispondono a esigenze diverse.
Usa l’esportazione a livello aziendale per pulire gli account, analizzare dati firmografici, arricchire i record delle società o preparare importazioni CRM. Usa l’esportazione a livello di contatto quando sono le persone a costituire il dataset di destinazione.
Quando usare questo workflow
Questo workflow è utile ogni volta che il formato di origine è JSON, ma quello di lavoro è CSV.
Alcuni casi tipici:
- Risposte API con metadati, paginazione e un array
resultsannidato. - Risultati di scraping tramite API con annunci, prodotti, contatti o eventi.
- Esportazioni CRM e RevOps in cui le società contengono contatti, tag, metriche e campi personalizzati.
- Esportazioni da marketplace o cataloghi di prodotti con varianti, prezzi, categorie e fornitori.
- Log di webhook in cui gli eventi sono annidati in un payload.
- Workflow di localizzazione nei quali vuoi tradurre il CSV ottenuto.
Lo schema è sempre lo stesso: individua l’array che rappresenta le righe, appiattisci i campi oggetto necessari, decidi come trattare gli array e controlla l’anteprima prima dell’esportazione.
Risolvere i problemi nella conversione da JSON annidato a CSV
Se il JSON non è valido, controlla innanzitutto il file di origine. Virgole mancanti, log della console copiati, testo aggiunto alla fine, download parziali e virgolette senza escape possono impedire il parsing. Di solito convalido il file prima di modificare le impostazioni di conversione, perché un JSON non valido deve essere corretto alla fonte.
Se non viene trovato alcun row node, è possibile che il file non contenga un array di oggetti. Un singolo oggetto composto soltanto da campi scalari non è sufficiente per questo workflow. Radici primitive, stringhe, numeri e valori singoli non permettono di creare righe CSV utili.
Se nell’anteprima compaiono le righe sbagliate, cambia il row node selezionato. Di solito significa che il convertitore ha trovato un array, ma non quello desiderato. Cerca il percorso in cui si trovano i record, per esempio $.results, $.data.items o $.payload.records.
Se contatti, tag, voci d’ordine o eventi sono difficili da leggere, modifica la gestione degli array. Unisci gli elenchi semplici. Mantieni gli array strutturati come JSON quando vuoi conservarne i dettagli. Passa a un row node figlio quando ogni elemento annidato deve diventare una riga.
Se l’elaborazione di un file di grandi dimensioni sembra lenta, ricorda che le prestazioni del browser e del dispositivo continuano a essere importanti. Datablist esegue il parsing e la conversione in un web worker, quindi il lavoro non avviene nel thread principale dell’interfaccia, ma la memoria e la CPU del tuo dispositivo determinano comunque i limiti pratici.
Se il CSV non viene importato correttamente in un altro strumento, prova un separatore diverso, mantieni attiva la riga di intestazione e controlla l’anteprima del CSV grezzo. Virgolette e interruzioni di riga possono fare la differenza quando i valori JSON contengono testo, array o oggetti annidati.
Come avviene l’elaborazione nel browser
Datablist analizza e converte il JSON in un worker del browser. Il worker esamina i possibili row node, memorizza nella cache l’oggetto analizzato, converte in CSV il nodo selezionato e restituisce all’interfaccia l’anteprima e il risultato.
Questo è importante per due motivi.
Innanzitutto, la conversione non viene eseguita nel thread principale dell’interfaccia. In questo modo la pagina rimane utilizzabile mentre il file viene analizzato.
In secondo luogo, l’elaborazione avviene localmente nel browser e il file non viene inviato ai server di Datablist per la conversione. È utile quando lavori con esportazioni API, risultati di scraping o file di dati interni e non vuoi caricarli su un convertitore lato server.
Resta comunque opportuno rispettare le normali regole di gestione dei dati. L’elaborazione locale nel browser è utile, ma non sostituisce le policy aziendali in materia di privacy e conformità.
Conclusione
Convertire JSON annidati in CSV significa soprattutto scegliere il row node corretto. Una volta individuato l’array che deve diventare l’insieme delle righe, tutto il resto risulta più semplice.
Per il file di esempio, $.results genera una società per riga. Appiattendo metrics.employees, metrics.revenue.amount e metrics.revenue.currency si ottengono colonne utili nel foglio di calcolo. Le impostazioni degli array stabiliscono se campi come tags, website e contacts devono diventare testo leggibile, JSON conservato oppure un’esportazione separata a livello di contatto.
Apri il convertitore da JSON a CSV, carica un’esportazione JSON annidata, seleziona il row node, controlla l’anteprima e scarica il CSV. Se devi pulire, filtrare, deduplicare, arricchire o tradurre i dati, apri quindi il file esportato nell’editor CSV di Datablist.
FAQ
Come posso convertire JSON annidati in CSV?
Usa un convertitore che permetta di selezionare l’array JSON da trasformare in righe. In Datablist, incolla o carica il JSON, scegli il row node, appiattisci i campi utili degli oggetti annidati, configura la gestione degli array, controlla l’anteprima della tabella e scarica il CSV.
Posso convertire JSON in CSV se i record sono sotto results?
Sì. Se ogni elemento sotto results deve diventare una riga del CSV, seleziona $.results come row node.
Come posso convertire data.items o payload.records in CSV?
Scegli $.data.items o $.payload.records come row node se quel percorso contiene gli oggetti che vuoi trasformare in righe. Il percorso esatto dipende dalla struttura del JSON.
Come posso appiattire i campi JSON annidati in colonne CSV?
Attiva l’appiattimento per i percorsi degli oggetti annidati, come metrics.revenue. Prima dell’esportazione, controlla quindi nell’anteprima le colonne generate.
Come devo gestire gli array nelle righe JSON?
Unisci gli elenchi semplici, come i tag; mantieni gli array strutturati come stringhe JSON quando devi conservarli; oppure scegli un row node più profondo quando ogni elemento dell’array deve diventare una riga distinta.
Posso convertire online un file JSON di grandi dimensioni in CSV?
Sì, purché il browser e il dispositivo riescano a gestire il file. Datablist utilizza un web worker per il parsing e la conversione, ma i file molto grandi dipendono comunque dalle prestazioni locali.
Un convertitore online da JSON a CSV è sicuro per i dati privati?
Il convertitore di Datablist elabora il file localmente nel browser, senza inviarlo ai server di Datablist per la conversione. Devi comunque rispettare le regole della tua organizzazione sulla gestione dei dati.
Che cos’è un row node nella conversione da JSON a CSV?
Un row node è l’array JSON i cui elementi diventano righe del CSV. Per esempio, $.results crea una riga CSV per ogni oggetto presente nell’array results.
Che cosa succede se scelgo $.results[].contacts invece di $.results?
Il CSV conterrà una riga per contatto anziché una riga per società o account. I campi della società principale non vengono inclusi automaticamente, a meno che lo strumento non supporti questa funzione in futuro.
Che cosa devo fare dopo aver esportato il CSV?
Aprilo in Datablist o in un altro strumento per fogli di calcolo per pulire, filtrare, deduplicare, arricchire o tradurre i dati, oppure importarli in un altro sistema.






