CSV e JSON sono probabilmente i due formati dati più comuni che incontrerai come sviluppatore. I file CSV compaiono nelle esportazioni di fogli di calcolo, nei dump di database e nelle pipeline di data science. JSON è ovunque sul web — REST API, file di configurazione, database NoSQL. Entrambi sono testo semplice, entrambi sono leggibili dall'uomo, ed entrambi fanno il lavoro. Ma sono stati costruiti per forme diverse di dati, e scegliere quello sbagliato crea problemi reali. Questo articolo esamina le differenze fondamentali, ti mostra esempi concreti di dove ogni formato brilla (e si rompe), e ti fornisce una guida pratica per scegliere tra i due.

La Differenza Fondamentale: Tabelle vs Alberi

CSV — definito in RFC 4180 — è un formato piatto e tabulare. Ogni riga ha le stesse colonne, ogni valore è una stringa. Tutto qui. Si mappa perfettamente su un foglio di calcolo o una tabella di database: righe in giù, colonne di traverso.

JSON — specificato in RFC 8259 e descritto su json.org — è un formato gerarchico. I valori possono essere oggetti, array, stringhe, numeri, booleani o null. Gli oggetti si annidano all'interno di oggetti, gli array contengono forme diverse. Si mappa su come i dati vivono effettivamente nel codice — record con relazioni, liste di cose diverse, valori tipizzati.

Riassunto in una riga: CSV è una tabella. JSON è un albero. Se i tuoi dati sono una tabella, CSV è più semplice e più piccolo. Se i tuoi dati hanno qualsiasi nidificazione, CSV perderà informazioni o ti costringerà a soluzioni alternative dolorose.

Gli Stessi Dati in Entrambi i Formati

Qui la differenza diventa concreta. Immagina un catalogo prodotti per un negozio e-commerce. I prodotti hanno un nome, un prezzo e se sono in stock — semplice. Ma hanno anche varianti (taglie, colori) e attributi (materiale, peso). Vediamo come appaiono quei dati in entrambi i formati.

In JSON, questo è naturale:

json
[
  {
    "id": "SHOE-001",
    "name": "Trail Runner Pro",
    "price": 129.99,
    "inStock": true,
    "attributes": {
      "material": "mesh",
      "weightGrams": 280
    },
    "variants": [
      { "size": 9,  "color": "black", "sku": "TR-9-BLK",  "qty": 12 },
      { "size": 9,  "color": "white", "sku": "TR-9-WHT",  "qty": 4  },
      { "size": 10, "color": "black", "sku": "TR-10-BLK", "qty": 7  }
    ]
  },
  {
    "id": "SHOE-002",
    "name": "City Walker",
    "price": 89.99,
    "inStock": true,
    "attributes": {
      "material": "leather",
      "weightGrams": 340
    },
    "variants": [
      { "size": 8,  "color": "brown", "sku": "CW-8-BRN",  "qty": 6  },
      { "size": 9,  "color": "brown", "sku": "CW-9-BRN",  "qty": 15 }
    ]
  }
]

Ora prova a metterlo in un CSV. Hai due opzioni, entrambe scomode. Opzione uno: appiattisci tutto e ripeti i dati del genitore per ogni riga variante:

csv
product_id,product_name,price,inStock,material,weightGrams,variant_size,variant_color,sku,qty
SHOE-001,Trail Runner Pro,129.99,true,mesh,280,9,black,TR-9-BLK,12
SHOE-001,Trail Runner Pro,129.99,true,mesh,280,9,white,TR-9-WHT,4
SHOE-001,Trail Runner Pro,129.99,true,mesh,280,10,black,TR-10-BLK,7
SHOE-002,City Walker,89.99,true,leather,340,8,brown,CW-8-BRN,6
SHOE-002,City Walker,89.99,true,leather,340,9,brown,CW-9-BRN,15

Il nome del prodotto, il prezzo e gli attributi vengono ripetuti per ogni variante. Questa è ridondanza dei dati — non è un grosso problema per cinque righe, ma per un catalogo di 50.000 prodotti con 8 varianti ciascuno, si accumula. Opzione due: serializzare le varianti come stringa JSON all'interno di una colonna CSV — ma ora stai incorporando JSON all'interno di CSV per aggirare le limitazioni di CSV, che è un code smell se mai ne ho visto uno.

Dove CSV Vince

Nonostante questa limitazione, CSV è genuinamente la scelta migliore in diversi scenari comuni.

  • Fogli di calcolo e strumenti BI. Excel, Google Sheets, Tableau, Looker, Power BI — aprono tutti CSV nativamente con un clic. Nessuna procedura guidata di importazione, nessuno schema da definire, nessun passaggio di trasformazione. Se i tuoi stakeholder vivono nei fogli di calcolo, CSV è la via di minor resistenza.
  • Dati puramente piatti. Se i tuoi dati sono genuinamente una tabella — eventi di analisi, log delle transazioni, letture dei sensori, esportazione utenti — CSV è più piccolo e più semplice. Nessuna chiave ripetuta, nessuna parentesi, nessun rumore.
  • Import/export di database. Ogni database SQL ha un comando COPY FROM CSV o equivalente. È il formato di interscambio standard per il caricamento dati in blocco ed è ordini di grandezza più veloce delle istruzioni INSERT.
  • pandas e data science. pandas.read_csv() è una delle funzioni più usate nel lavoro dati Python. L'intero ecosistema — NumPy, scikit-learn, Polars — tratta CSV come formato di input di prima classe.
  • Dimensione file per grandi tabelle piatte. Senza i nomi dei campi su ogni riga, CSV è più piccolo per tabelle larghe con molte righe. Un CSV di un milione di righe di eventi di analisi batterà comodamente l'array JSON equivalente.

Dove JSON Vince

  • Dati annidati e gerarchici. Non appena i tuoi dati hanno qualsiasi struttura oltre una tabella piatta — oggetti annidati, array di forme diverse, record correlati — JSON li gestisce naturalmente. CSV non può rappresentarli senza perdere informazioni o creare ridondanza.
  • Preservazione dei tipi. In CSV, tutto è una stringa. true, 42, null e "true" sembrano tutti uguali. Devi dedurre i tipi sul lato ricevente, il che porta a bug. JSON ha booleani, numeri e null nativi. inStock: true è inequivocabilmente un booleano — nessuna supposizione necessaria.
  • REST API e il web. JSON è il formato dati nativo del web. Ogni libreria client HTTP, ogni Fetch API del browser, ogni REST e GraphQL API parla JSON. Inviare CSV su HTTP è possibile ma insolito — avresti bisogno di parsing personalizzato su entrambi i lati.
  • Database NoSQL. MongoDB, DynamoDB, Firestore, Elasticsearch, CouchDB — tutti usano JSON (o un superset binario come BSON) come formato nativo del documento. Scrivi JSON in ingresso, ottieni JSON in uscita.
  • File di configurazione. package.json, tsconfig.json, manifest.json — la configurazione degli strumenti si è standardizzata su JSON perché supporta strutture annidate ed è facile da generare e validare a livello programmatico.
  • Validazione dello schema. JSON Schema ti permette di definire la forma esatta di un documento e validare i dati rispetto ad esso — controlli dei tipi, campi obbligatori, corrispondenza di pattern, vincoli sugli array. CSV non ha uno standard equivalente.

Dimensioni dei File: La Storia Reale

L'affermazione "CSV è più piccolo" è vera in un caso specifico: grandi tabelle piatte con molte righe. Prendi 100.000 eventi di analisi, ciascuno con otto campi fissi. In CSV, i nomi dei campi appaiono una volta nell'intestazione. In JSON, appaiono su ogni oggetto. Quella ripetizione si accumula — l'array JSON potrebbe essere del 30-50% più grande del CSV equivalente.

Ma capovolgi lo scenario su dati annidati e la matematica cambia. Il CSV appiattito del nostro catalogo di scarpe ripete il nome del prodotto, il prezzo e gli attributi su ogni riga variante. La versione JSON memorizza ogni prodotto una volta. Per dati profondamente annidati con molti campi padre ripetuti, JSON può essere effettivamente più piccolo.

In pratica, se le dimensioni del file sono una vera preoccupazione, entrambi i formati si comprimono molto bene con gzip — i nomi delle chiavi ripetitivi in JSON e i valori di riga ripetuti in CSV si comprimono pesantemente. Servire JSON gzippato su HTTP è pratica standard, e la differenza di dimensione di solito diventa trascurabile dopo la compressione.

Confronto degli Strumenti

La storia degli strumenti per ogni formato riflette dove viene usato di più.

Strumenti CSV: Excel, Google Sheets e LibreOffice Calc lo aprono nativamente. La libreria pandas rende CSV il predefinito per l'analisi dei dati in Python. Ogni database relazionale ha un comando di import/export CSV. Strumenti da riga di comando come csvkit e xsv ti permettono di filtrare, unire e aggregare file CSV senza scrivere codice. Il tipo MIME è text/csv, registrato presso IANA.

Strumenti JSON: ogni linguaggio di programmazione ha un parser JSON integrato o nella libreria standard. JSON.parse() in JavaScript, json.loads() in Python, encoding/json in Go, serde_json in Rust. Il riferimento JSON di MDN è una delle pagine più visitate su MDN. Da riga di comando: jq è indispensabile per interrogare e trasformare JSON. Gli IDE lo visualizzano e lo validano automaticamente.

Se stai lavorando con pipeline dati che attraversano entrambi i mondi — caricando risposte JSON API in un data warehouse, o esportando record di database per un foglio di calcolo — convertirai regolarmente tra i due. Il convertitore CSV to JSON e il convertitore JSON to CSV lo gestiscono rapidamente. Per riordinare i file grezzi prima dell'elaborazione, il CSV Formatter e il JSON Formatter vale la pena aggiungerli ai preferiti.

Il Formato Ibrido: JSON Lines (NDJSON)

C'è una terza opzione che vale la pena conoscere: JSON Lines, chiamato anche NDJSON (Newline-Delimited JSON). L'idea è semplice — un oggetto JSON completo per riga, senza array circostante.

json
{"id":"SHOE-001","name":"Trail Runner Pro","price":129.99,"inStock":true,"variantCount":3}
{"id":"SHOE-002","name":"City Walker","price":89.99,"inStock":true,"variantCount":2}
{"id":"SHOE-003","name":"Summit Hiker","price":159.99,"inStock":false,"variantCount":5}

Questo formato ti dà il meglio di entrambi i mondi per certi casi d'uso. Come CSV, puoi elaborarlo riga per riga in streaming senza caricare l'intero file in memoria — fondamentale per file di log di grandi dimensioni o output di pipeline dati. Come JSON, ogni riga può avere uno schema diverso e preserva i tipi. Puoi usare gli strumenti Unix standard (grep, wc -l, head) per lavorarci, ma anche passare ogni riga attraverso jq per query strutturate.

NDJSON è ampiamente utilizzato per l'aggregazione di log (è il formato di output predefinito per molti logger strutturati), le fasi della pipeline dati e le esportazioni di dati di addestramento ML. Se stai scrivendo uno script che elabora milioni di record e ogni record è un oggetto JSON, NDJSON è di solito la scelta giusta rispetto a un gigantesco array JSON — eviti di caricare tutto in memoria e puoi riprendere facilmente da un checkpoint.

python
import json

# Process a large NDJSON file without loading it all into memory
with open('products.ndjson', 'r') as f:
    for line in f:
        product = json.loads(line.strip())
        if product['inStock'] and product['price'] < 100:
            print(f"{product['name']} — ${product['price']}")

Guida alle Decisioni: CSV vs JSON

Ecco la versione pratica. Quando scegli tra i due, poniti queste domande:

  • I tuoi dati sono genuinamente piatti (nessuna nidificazione, nessun array)? Se sì, CSV è più semplice. Se no, JSON.
  • Un non-sviluppatore consumerà questo file? Analisti in Excel? Utenti aziendali in Google Sheets? Usa CSV.
  • Stai servendo o consumando un'API HTTP? Usa JSON. Fine.
  • Stai eseguendo un import o export di database in blocco? Usa CSV — ogni database lo supporta nativamente.
  • I dati hanno tipi misti (booleani, numeri, null)? Usa JSON per evitare bug di inferenza del tipo sul lato ricevente.
  • Il file verrà elaborato riga per riga in una pipeline di streaming? Considera NDJSON come via di mezzo.
  • Stai archiviando configurazioni? Usa JSON (o YAML se i commenti ti interessano).
  • Lo schema deve variare per record? JSON. CSV impone le stesse colonne su ogni riga.
Il default onesto: se stai costruendo qualcosa per altri sviluppatori o macchine da consumare, usa JSON. Se stai consegnando dati a un essere umano che li aprirà in un foglio di calcolo, usa CSV. Se stai costruendo una pipeline dati che elabora milioni di record strutturati, considera NDJSON.

Conclusione

CSV e JSON non sono davvero in competizione — risolvono problemi diversi. CSV è lo strumento giusto quando i tuoi dati sono una tabella e vuoi la massima compatibilità con gli strumenti di fogli di calcolo e database. JSON è lo strumento giusto quando i tuoi dati hanno struttura, tipi o nidificazione, e quando stai parlando con API o applicazioni.

La decisione di solito non è difficile una volta che guardi la forma effettiva dei dati. Righe piatte di letture di sensori? CSV. Una risposta API con profili utente annidati e cronologie degli ordini incorporate? JSON. Un log in streaming di eventi strutturati? NDJSON. Abbina il formato alla forma dei dati e agli strumenti su entrambi i lati, e raramente sbaglierai.

← All CSV articles Browse all categories →