Come appiattire JSON annidato in CSV: 5 strategie e matrice decisionale

Il problema della geometria

Sbatti contro lo stesso muro ogni volta. Una API restituisce JSON annidato e l’analista su Slack vuole soltanto un foglio di calcolo. mongoexport produce wrapper $oid e tre livelli di metadati, mentre BigQuery si aspetta una tabella piatta. Appiattire JSON annidato in CSV non è un problema di sintassi. È un problema di geometria. JSON è un albero, CSV è una griglia, e non puoi spostare un albero dentro una griglia senza decidere come collassano i rami.

Esistono esattamente cinque strategie di collasso. Scegli quella sbagliata e spedisci 200 colonne a Excel, perdi precisione su un ID Twitter o rompi il round-trip da cui dipende la tua pipeline. Scegli quella giusta e la conversione diventa una one-liner.

Strategia	One-liner	Adatta a
Notazione a punti	customer.address.city	Analisi in Excel/Sheets
Underscore	customer_address_city	Colonne SQL-friendly
Array indicizzati	items.0.sku, items.1.sku	Array di dimensione fissa
Esplosione di righe	Ripeti il genitore per ogni figlio	Analisi con Pandas/BigQuery
Stringify	"{\"city\":\"Seattle\"}" in una cella	Round-trip senza perdita

Questa guida ti accompagna in ogni strategia, ti consegna una matrice decisionale per consumatore (Excel, Pandas, BigQuery, Postgres) e mostra quattro payload reali in cui la strategia giusta non è quella ovvia. Se ti serve anche la panoramica bidirezionale generale (librerie di parsing, streaming, trappole di codifica), consulta la Conversione CSV in JSON: metodi, insidie ed esempi di codice.

Perché JSON annidato non sta in un CSV

JSON porta tre tipi di struttura che CSV non ha. La gerarchia è un oggetto dentro un oggetto. La sequenza è un array. Il misto è la combinazione: array di oggetti, oggetti con array, array di array. Un tipico ordine e-commerce è tutti e tre insieme.

CSV ha esattamente due dimensioni: righe e colonne. Non c’è un terzo asse per “questa colonna contiene tre figli”. Quando pretendi una griglia da un albero, qualcosa cede. Distribuisci i figli su più colonne (e convivi con nomi come items.0.options.0.value), li distribuisci su più righe (i campi genitore si ripetono), oppure li comprimi in una cella come testo e smetti di trattarli come struttura.

Ogni strategia qui sotto risponde a quella domanda in modo diverso. Alcune preservano la leggibilità e perdono la sicurezza del round-trip. Altre fanno l’opposto. Nessuna è universale. Adatta la risposta a chi leggerà il file dopo di te.

5 strategie di appiattimento a confronto

Strategia 1: notazione a punti (customer.address.city)

La notazione a punti percorre dalla radice alla foglia e usa . per unire le chiavi. Ogni oggetto annidato diventa una colonna per foglia, con il percorso codificato nel nome della colonna.

{ "customer": { "address": { "city": "Seattle" } }, "email": "alice@example.com" }

diventa

customer.address.city,email
Seattle,alice@example.com

In Pandas basta una riga:

import pandas as pd

data = [{"customer": {"address": {"city": "Seattle"}}, "email": "alice@example.com"}]
df = pd.json_normalize(data, sep='.')
df.to_csv("out.csv", index=False)

In JavaScript una piccola funzione ricorsiva è sufficiente:

function flattenDot(obj, prefix = '', acc = {}) {
  for (const [k, v] of Object.entries(obj)) {
    const key = prefix ? `${prefix}.${k}` : k;
    if (v && typeof v === 'object' && !Array.isArray(v)) {
      flattenDot(v, key, acc);
    } else {
      acc[key] = v;
    }
  }
  return acc;
}

Pro: leggibile, default di Pandas, preserva il percorso originale. Contro: i nomi di colonna possono diventare molto lunghi (le spec Kubernetes producono nomi come spec.template.spec.containers.0.resources.limits.memory) e il punto diventa ambiguo se una chiave reale contiene . (i parametri evento di Google Analytics 4 lo fanno).

Strategia 2: notazione underscore (customer_address_city)

Stessa idea, separatore diverso. Sostituisci . con _ e il risultato è SQL-safe: SELECT customer_address_city FROM events funziona senza dover quotare l’identificatore. BigQuery, Snowflake e Postgres preferiscono tutti questa forma.

import pandas as pd
df = pd.json_normalize(data, sep='_')

La scelta tra punto e underscore dipende esclusivamente dallo strumento a valle. Gli analisti Excel leggono il punto in modo più naturale; i motori SQL accettano l’underscore senza protestare. Cambia tutto modificando un solo argomento.

Pro: nomi di colonna SQL-safe, identificatori conformi a BigQuery, nessuna quotazione richiesta. Contro: l’ambiguità resta se una chiave contiene _ (meno comune di . ma comunque possibile).

Strategia 3: array indicizzati (items.0.sku, items.1.sku)

Gli oggetti si appiattiscono in modo pulito perché le chiavi sono uniche. Gli array no, perché la lunghezza non è limitata. La strategia indicizzata tratta le posizioni dell’array come segmenti di percorso: items[0] diventa items.0.

{ "id": "ord-001", "items": [{"sku": "A"}, {"sku": "B"}] }

diventa

id,items.0.sku,items.1.sku
ord-001,A,B

Questo è il comportamento Flatten predefinito nel nostro Convertitore JSON in CSV. Ogni foglia ottiene la propria colonna; la posizione viene registrata nel nome.

Pro: ogni valore ottiene la propria cella, la posizione è preservata, nessuna duplicazione di righe. Contro: il numero di colonne esplode (100 elementi = 100 colonne); righe con lunghezze di array diverse producono tabelle frastagliate; l’aggregazione a valle si rompe (niente SUM(items.*.qty)).

Strategia 4: esplosione di righe (array su righe multiple)

Invece di allargare la tabella per contenere l’array, allungala. Ripeti i campi genitore una volta per ogni elemento dell’array e lascia che ogni elemento diventi la propria riga.

{ "order_id": "ord-001", "customer": "Alice", "items": [{"sku": "A", "qty": 2}, {"sku": "B", "qty": 1}] }

diventa

order_id,customer,items.sku,items.qty
ord-001,Alice,A,2
ord-001,Alice,B,1

In Pandas una riga fa sia l’esplosione sia la normalizzazione:

import pandas as pd

orders = [{"order_id": "ord-001", "customer": "Alice",
           "items": [{"sku": "A", "qty": 2}, {"sku": "B", "qty": 1}]}]
df = pd.json_normalize(orders, record_path='items', meta=['order_id', 'customer'])
df.to_csv("orders.csv", index=False)

In SQL, UNNEST fa la stessa cosa:

SELECT order_id, item.sku, item.qty FROM orders, UNNEST(items) AS item;

Pro: Pandas e BigQuery trattano nativamente questa forma, le aggregazioni funzionano (GROUP BY order_id), lo schema resta stretto. Contro: i campi genitore si duplicano in ogni riga figlia (gonfia lo storage), il confine 1-a-molti è implicito (ti serve un order_id) e due array allo stesso livello producono un prodotto cartesiano se non li applichi con UNNEST con cura.

Strategia 5: Stringify (JSON-in-cella)

L’opzione radicale: non appiattire affatto. Serializza l’intero valore annidato come stringa JSON e mettilo in una singola cella. La tabella esterna resta piatta; la struttura è preservata verbatim all’interno.

{ "id": "ord-001", "items": [{"sku": "A"}, {"sku": "B"}] }

diventa

id,items
ord-001,"[{""sku"":""A""},{""sku"":""B""}]"

Questa è la modalità Stringify nel nostro Convertitore JSON in CSV. Il numero di colonne non esplode mai, la forma originale è preservata byte per byte e il viaggio inverso ricostruisce l’input esattamente.

Pro: 100% senza perdita, numero di colonne prevedibile, round-trip sicuro se abbinato a Infer types nella conversione inversa. Contro: gli utenti Excel vedono virgolette escaped, i motori SQL hanno bisogno di funzioni JSON per interrogare il valore (JSON_EXTRACT_SCALAR in BigQuery, ->>'key' in Postgres) e le formule del foglio di calcolo non possono raggiungere l’interno della cella.

5 strategie a confronto

Stesso input su tutte e cinque: {"id":"ord-001","customer":{"name":"Alice"},"items":[{"sku":"A","qty":2},{"sku":"B","qty":1}]}.

Strategia	Colonne	Round-trip sicuro	Consumatore ideale
Notazione a punti	cresce con l’array	No	Analista Excel
Underscore	cresce con l’array	No	Warehouse SQL
Array indicizzati	2 per slot dell’array	No (ambiguo in inversione)	Array di dimensione fissa
Esplosione di righe	stretta, 1 riga per figlio	Parziale (richiede chiave)	Pandas / BigQuery
Stringify	fisso	Sì	Round-trip in pipeline

Matrice decisionale: quale strategia per quale consumatore

Cerca prima il consumatore, poi leggi la strategia consigliata.

Consumatore	Strategia consigliata	Perché
Excel / Sheets (analista)	Punto + Stringify per array grandi	Nomi di colonna leggibili; gli array grandi non fanno esplodere il foglio
Excel-EU (DE/FR/IT/ES)	Punto + delimitatore ; + BOM UTF-8	Il punto e virgola è richiesto; il BOM previene il garbling della codifica
Pandas (json_normalize + explode)	Underscore + esplosione di righe	Colonne SQL-friendly; l’esplosione si sposa bene con groupby
BigQuery / Snowflake	TSV + Stringify o esplosione	Il tab evita le trappole delle virgolette; JSON_EXTRACT interroga la cella
PostgreSQL COPY	RFC 4180 + Underscore + piatto	Colonne SQL-safe; quotazione RFC rigorosa
MongoDB → BigQuery ETL	Carica NDJSON direttamente, salta CSV	BigQuery carica NDJSON nativamente; CSV è una deviazione

Excel / Google Sheets: la trappola del locale

I nomi di colonna in Excel non hanno un limite di lunghezza pratico. Le vere trappole sono tre.

Primo, la divisione per locale. Excel europeo (Germania, Francia, Italia, Spagna) si aspetta ; come delimitatore perché , è il separatore decimale. Un CSV separato da virgole si apre con ogni riga collassata nella colonna A. Il preset Excel sul nostro strumento convertitore JSON in CSV passa a ; + CRLF + BOM UTF-8 in un solo clic.

Secondo, la notazione scientifica. Excel vede 9007199254740993 e mostra 9.00719925474E+15. Memorizza gli interi grandi come stringhe nel JSON di origine e attiva il BOM affinché Excel mantenga la cella come testo. Il nostro convertitore rileva automaticamente gli interi grandi.

Terzo, il limite pratico di colonne. Excel teoricamente supporta 16,384 colonne, ma oltre circa 500 diventa ingestibile. Applica Stringify ai sotto-alberi pesanti o pre-proietta con jq prima di convertire.

Pandas: json_normalize + explode

Il pattern standard per gli array annidati è record_path + meta in un’unica passata:

import pandas as pd

orders = [{
    "order_id": "ord-001",
    "customer": {"name": "Alice", "city": "Seattle"},
    "items": [{"sku": "SKU-100", "qty": 2}, {"sku": "SKU-205", "qty": 1}]
}]

df = pd.json_normalize(orders, record_path='items',
    meta=['order_id', ['customer', 'name'], ['customer', 'city']], sep='_')
df.to_csv("orders.csv", index=False)

L’output è una riga per articolo con order_id, customer_name e customer_city ripetuti. Questo batte l’eseguire prima explode e poi json_normalize: record_path salta la colonna oggetto intermedia e meta ti permette di controllare quali campi genitore propagare. Per input in cui gli elementi dell’array contengono oggetti annidati, imposta max_level= per limitare la profondità.

BigQuery / Snowflake: TSV + JSON-in-cella

Il LOAD DATA di BigQuery è rigoroso sulla quotazione CSV e spesso analizza male i file con virgole all’interno del testo quotato. TSV è più sicuro perché i tab quasi non compaiono mai all’interno dei campi di testo:

bq load --source_format=CSV --field_delimiter='\t' \
  dataset.orders gs://bucket/orders.tsv \
  order_id:STRING,customer:STRING,items:STRING

Quando carichi dati annidati come JSON Stringificato in una singola colonna, BigQuery può comunque interrogarli con JSON_EXTRACT_SCALAR:

SELECT order_id, JSON_EXTRACT_SCALAR(items, '$[0].sku') AS first_sku
FROM dataset.orders;

Snowflake offre la stessa capacità tramite VARIANT, con query a percorso come items:0.sku::STRING. In entrambi i motori, Stringify + query JSON path battono l’appiattimento completo quando gli array annidati sono grandi o di lunghezza variabile.

PostgreSQL COPY: RFC 4180 rigoroso

COPY ... FROM ... WITH (FORMAT csv, HEADER true) è il lettore RFC 4180 più rigoroso che incontrerai abitualmente. Due comportamenti fanno inciampare le persone.

Primo, COPY non accetta il BOM UTF-8. Il byte order mark diventa un prefisso letterale sul nome della prima colonna (id invece di id) e ogni query che fa riferimento a id fallisce silenziosamente. Disattiva il BOM per i target Postgres.

Secondo, COPY non può analizzare nativamente dati annidati. O esplodi gli array su righe multiple prima del caricamento, oppure definisci la destinazione come jsonb e applica Stringify al valore annidato:

CREATE TABLE orders (order_id text PRIMARY KEY, customer text, items jsonb);
COPY orders FROM '/tmp/orders.csv' WITH (FORMAT csv, HEADER true);
SELECT order_id, items->0->>'sku' AS first_sku FROM orders;

Per pipeline che parlano già JSON end-to-end, salta CSV e usa COPY ... FROM ... WITH (FORMAT text) con input JSON-line.

Esempi pratici con payload reali

Esempio 1: ordini e-commerce (cliente + array di articoli)

Un ordine tipico combina informazioni cliente annidate con un array di articoli a lunghezza variabile:

[{ "id": "ord-001",
   "customer": { "name": "Mario", "address": {"city": "Milano", "country": "IT"} },
   "items": [{"sku": "SKU-100", "qty": 2}, {"sku": "SKU-205", "qty": 1}] }]

La strategia giusta dipende da chi legge il file. Finance vuole una riga per articolo per calcolare i ricavi per SKU; quella è la strategia di esplosione, che produce due righe con id e customer.name ripetuti. Operations vuole una riga per ordine per le dashboard di fulfillment; quella è la notazione a punti con items Stringificato in modo che l’array non faccia esplodere il numero di colonne. Stesso input, due output, entrambi corretti per il proprio consumatore.

Provalo direttamente: incolla il payload nel nostro Convertitore JSON in CSV e commuta tra Flatten e Stringify sull’opzione Nested. L’esempio “Nested E-commerce Orders” carica la stessa forma.

Esempio 2: GitHub Issues API (array di label + oggetto user)

L’endpoint /repos/{owner}/{repo}/issues restituisce una forma annidata mista:

[{ "id": 1001, "title": "Bug: login 404", "state": "open",
   "labels": ["bug", "priority:high"], "user": {"login": "alice"} }]

user è un oggetto con un campo utile; labels è un array di stringhe di lunghezza non limitata. L’appiattimento pragmatico è ibrido: notazione a punti su user (ti interessa solo user.login) e inline-join su labels in una singola cella separata da ;:

id,title,state,labels,user.login
1001,Bug: login 404,open,bug;priority:high,alice

Non puoi catturare sia “unisci gli array in una cella” sia “appiattisci gli oggetti con i punti” in una singola strategia. Il nostro convertitore gestisce automaticamente l’appiattimento dell’oggetto; pre-elabora le label con jq (map(.labels = (.labels | join(";")))) o accetta il comportamento predefinito di array-stringify.

Esempio 3: MongoDB mongoexport ($oid + metadati)

mongoexport --jsonArray produce wrapper Extended JSON:

[{ "_id": {"$oid": "6634a1b2c3d4e5f600000001"},
   "email": "alice@example.com",
   "metadata": { "signupDate": "2026-01-15T10:30:00Z",
                 "preferences": {"newsletter": true, "theme": "dark"} } }]

Il wrapper $oid produce una colonna letteralmente chiamata _id.$oid, che la maggior parte dei motori SQL rifiuta. Pre-elabora con jq per scartare il wrapper:

mongoexport --collection=users --jsonArray | jq 'map(._id = ._id."$oid")' > users.json

Per il blocco profondamente annidato metadata.preferences, scegli in base al consumatore. Esportazione per analista: applica dot-flatten a tutto il blocco; metadata.preferences.theme si legge bene. Round-trip in pipeline: applica Stringify a metadata per mantenere intatta la struttura. Per i pattern jq completi che si abbinano alle pipeline CSV, consulta il nostro jq Cheat Sheet.

Esempio 4: Kubernetes Pod Spec (annidamento profondo)

Una risposta kubectl get pod -o json è il caso peggiore per le strategie piatte. La struttura va abitualmente sei livelli in profondità (spec.template.spec.containers.0.resources.limits.memory). Il dot-flatten ingenuo produce nomi di colonna che superano i 70 caratteri e 200+ colonne di output. Funzionano due strategie.

Pre-proietta con kubectl jsonpath. Seleziona solo i campi che ti servono davvero:

kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\t"}{.status.phase}{"\n"}{end}' > pods.tsv

Applica Stringify allo spec, appiattisci i metadati. Mantieni metadata (name, namespace, labels) piatto e applica Stringify a spec in una singola cella:

kubectl get pods -o json | jq 'map({name: .metadata.name, namespace: .metadata.namespace, spec: (.spec | tostring)})'

Poi incolla nel convertitore con la modalità Flatten. La colonna spec diventa una cella JSON; le colonne dei metadati restano leggibili. Evita l’anti-pattern kubectl get pod -o json | json-to-csv flatten senza pre-proiezione. Il numero di colonne sarà ingestibile.

Sicurezza del round-trip: l’appiattimento è lossy, Stringify è senza perdita

Ecco un teorema che le guide concorrenti saltano. La notazione a punti, la notazione underscore, gli array indicizzati e l’esplosione di righe sono tutte proiezioni unidirezionali. Una volta appiattito con una qualsiasi di esse, il JSON originale non può essere ricostruito perfettamente dal solo CSV.

I controesempi sono facili da costruire. Una colonna chiamata customer.address.city è ambigua tra {"customer": {"address": {"city": "..."}}} e {"customer": {"address.city": "..."}}. Gli array indicizzati sembrano reversibili, ma CSV non può dire se items.0.sku debba ricostruirsi in un array o in un oggetto con una chiave numerica. L’esplosione di righe richiede una chiave di group-by; senza order_id, non puoi dire quali righe appartenessero allo stesso genitore.

Solo Stringify sopravvive al round-trip. Il valore annidato è preservato verbatim come stringa JSON, così il convertitore inverso legge la cella, ne fa il parsing e reinserisce l’originale intatto. Converti con Stringify, salva il CSV, incolla nel nostro Convertitore CSV in JSON, attiva Infer types e otterrai byte identici all’input.

La regola pratica: round-trip in pipeline → Stringify. Analisi o reporting one-shot → punto, underscore o esplosione in base al consumatore.

Farlo nel nostro strumento browser

Il Convertitore JSON in CSV espone direttamente due delle cinque strategie: Flatten (che combina notazione a punti e array indicizzati) e Stringify (che preserva la struttura all’interno di una cella). Le altre tre (underscore, esplosione di righe, preset SQL) sono a un passo di pre-elaborazione di distanza.

Una sessione tipica richiede cinque clic:

1. Valida l’input con il nostro Formattatore JSON in modo che gli errori di sintassi non diventino fallimenti di conversione silenziosi.
2. Incolla il JSON nel Convertitore JSON in CSV. La conversione viene eseguita istantaneamente.
3. Imposta Nested su Flatten per chiavi con punti e indicizzate, oppure su Stringify per mantenere array e oggetti in singole celle.
4. Scegli un preset: RFC 4180 per le pipeline, Excel per i fogli di calcolo EU, TSV per i warehouse, Pipe per testi ricchi di virgole.
5. Clicca su Swap direction e usa il Convertitore CSV in JSON con Infer types attivo per verificare un round-trip Stringify.

Tutto viene eseguito nel tuo browser. PII, export interni e segreti di produzione non lasciano mai la pagina; non ci sono richieste di rete dopo il caricamento. Lo strumento resta utilizzabile per dati sensibili quando caricare su un sito di terze parti non è un’opzione.

Insidie comuni

Sei modalità di fallimento si presentano in continuazione.

1. Esplosione dei nomi di colonna. Le spec Kubernetes e i thread di review delle PR GitHub producono centinaia di percorsi foglia. Soluzione: pre-proietta con jq o kubectl jsonpath, oppure applica Stringify ai sotto-alberi pesanti mentre appiattisci i metadati.
2. Lunghezze di array disallineate. La riga 1 ha 3 articoli, la riga 2 ne ha 5. Gli array indicizzati producono celle vuote in items.3.sku e items.4.sku per la riga 1. Soluzione: passa all’esplosione di righe.
3. Chiavi indice trattate come stringhe in inversione. Quando CSV-to-JSON vede items.0.sku, lo 0 è tecnicamente una chiave stringa. Alcuni convertitori inversi ricostruiscono {"0": {"sku": "A"}} invece di [{"sku": "A"}]. Soluzione: usa Stringify per i round-trip.
4. Chiavi che contengono già il separatore. Gli eventi GA4 hanno chiavi come event_params.key che contengono punti letterali; l’appiattimento con . produce percorsi ambigui. Soluzione: usa underscore o rinomina le chiavi problematiche. Consulta la nostra Guida online JSON5 e JSONC per il contesto sui formati JSON con supporto chiave esteso.
5. Tipi misti tra livelli. Alcune righe hanno address come oggetto, altre come null. L’appiattimento produce celle vuote dove l’oggetto era null. L’avviso sulle note dello schema sul nostro convertitore lo segnala in modo che tu possa verificare il consumatore a valle.
6. Interi grandi troncati da Excel. Un $oid Long, un Twitter snowflake ID o un resourceVersion K8s superano il range sicuro di JavaScript (2^53 - 1) e vengono arrotondati silenziosamente. Excel poi li mostra come 9.00719925474E+15. Soluzione: memorizza gli ID come stringhe nel JSON di origine, attiva il BOM e usa il preset Excel.

FAQ

Qual è il modo migliore per appiattire JSON annidato in CSV?

Il modo migliore per appiattire JSON annidato in CSV dipende dal consumatore a valle. Usa la notazione a punti per Excel o Google Sheets. Usa l’esplosione di righe quando Pandas o BigQuery aggregheranno i dati. Usa Stringify quando il CSV deve fare round-trip a JSON senza perdita di dati. Adatta la strategia al prossimo lettore.

Come converto un array JSON in più righe CSV?

Converti un array JSON in più righe CSV con la strategia di esplosione: duplica i campi genitore una volta per ogni elemento dell’array in modo che ognuno diventi la propria riga. In Pandas, pd.json_normalize(data, record_path='items', meta=['order_id']) lo fa in una sola chiamata. In SQL, UNNEST(items) produce la stessa forma. Le chiavi genitore si ripetono nelle righe esplose.

Posso fare round-trip dal CSV al JSON annidato originale?

Fare round-trip dal CSV al JSON annidato originale funziona solo con la modalità Stringify. La notazione a punti, l’underscore, gli array indicizzati e l’esplosione di righe sono proiezioni unidirezionali lossy; il convertitore inverso non può ricostruire perfettamente l’albero. Stringify preserva array e oggetti come JSON all’interno di una singola cella, così il round-trip completo è byte-identico quando Infer types è attivo.

Perché Excel mostra il mio JSON appiattito come una lunga colonna unica?

Excel mostra il tuo JSON appiattito come una lunga colonna unica quando sei in un locale europeo (Germania, Francia, Italia, Spagna) dove la virgola è riservata ai decimali ed Excel si aspetta i punti e virgola come delimitatore. Il preset Excel su json-to-csv passa a ; + CRLF + BOM UTF-8 in un solo clic.

Devo usare la notazione a punti o l’underscore per i nomi di colonna?

Usa la notazione a punti quando il target è Excel, Google Sheets o Pandas; i punti sono il default di json_normalize e si leggono naturalmente. Usa l’underscore quando il target è SQL: Postgres, BigQuery e Snowflake richiedono la quotazione attorno agli identificatori che contengono punti, mentre gli underscore sono accettati senza quotazione ovunque.

Come gestisce pandas json_normalize gli array di oggetti?

Pandas json_normalize gestisce gli array di oggetti tramite gli argomenti record_path e meta. pd.json_normalize(data, record_path='items', meta=['order_id']) esplode items in una riga per elemento con order_id ripetuto. Per oggetti annidati senza array, il più semplice pd.json_normalize(data, sep='_') produce nomi di colonna separati da underscore come customer_address_city. Usa max_level= per limitare la profondità su alberi profondi.

Qual è il limite di colonne quando si appiattisce JSON profondamente annidato?

Il limite di colonne quando si appiattisce JSON profondamente annidato è 16,384 in Excel ed effettivamente illimitato in CSV stesso, ma oltre le 500 colonne l’output diventa ingestibile. Le spec dei Pod Kubernetes o le risposte GraphQL lo superano facilmente. Applica Stringify ai sotto-alberi pesanti con il Convertitore JSON in CSV o pre-proietta con jq o kubectl jsonpath.

jq è un buon strumento per appiattire JSON prima della conversione in CSV?

Sì, jq è lo strumento giusto per appiattire JSON prima della conversione in CSV. Gestisce la pre-proiezione (map({id, name})), la pre-esplosione (.[] | {id, item: .items[]}) e la normalizzazione della forma in una riga. La pipeline jq viene eseguita prima dello step CSV e controlla esattamente quali campi raggiungono il convertitore. Consulta il nostro jq Cheat Sheet per i pattern.

Conclusione

Cinque punti da portare a casa:

1. JSON-in-CSV è un problema di geometria, non di sintassi. Un albero non può entrare in una griglia senza scegliere come collassano i rami.
2. Cinque strategie coprono l’universo pratico (punto, underscore, array indicizzati, esplosione di righe, Stringify). Scegli in base al consumatore.
3. Stringify è l’unica via senza perdita. Usala per i round-trip in pipeline.
4. Excel-EU e BigQuery hanno preset per una ragione. Usali.
5. I payload reali (mongoexport, spec Kubernetes, risposte GitHub) di solito hanno bisogno prima di un passo di pre-proiezione con jq o kubectl jsonpath.

Prova il tuo payload nel Convertitore JSON in CSV. Gira in locale, gestisce tutte e cinque le strategie e fa round-trip senza perdita con Stringify. Nessun upload e nessuna registrazione: i tuoi dati non lasciano mai la pagina.