File JSON grande non si apre? Scegli lo strumento giusto in base alla dimensione

Un file JSON da 45 MB si parsa in 249 millisecondi. Il mezzo minuto di attesa arriva dal rendering di cinque milioni di righe di testo e 3,5 milioni di nodi dell'albero. Se confondi le due cose, incolpi sempre il colpevole sbagliato.

Uno: misura prima — il parsing non è mai il collo di bottiglia

Doppio clic su un export .json di decine di MB, l'editor gira per trenta secondi, e il riflesso dice «il parsing JSON è lento». Le misurazioni dicono il contrario. Sulla nostra macchina (Node 22) abbiamo generato un campione di 500.000 record da cinque campi ciascuno (id, email, active, score, tags), 45 MB in forma compatta:

Il parsing è finito in un quarto di secondo. Il parser aveva concluso prima che lasciassi il mouse. Tutti i secondi successivi sono finiti nello strato «mostrare il risultato a una persona»: l'editor di testo deve impaginare cinque milioni di righe, applicare l'evidenziazione della sintassi e mantenere un buffer di annullamento; la vista ad albero deve creare un elemento DOM per ognuno dei 3,5 milioni di nodi — e i browser inciampano intorno a centomila nodi, perdendo la reattività ben prima del milione.

La conclusione punta in una direzione completamente diversa: smetti di lottare con il rendering e prendi uno strumento che non renderizza tutto.

Due: perché si blocca — il numero di righe e nodi è il vero costo

La dimensione del file è solo la superficie. Due numeri derivati rompono davvero gli strumenti:

1. Numero di righe. Un JSON compatto da 45 MB diventa cinque milioni di righe una volta formattato. Qualunque porzione tu stia guardando, l'editor deve prima costruire la struttura di righe dell'intero file, risolvere lo stato dell'evidenziazione e allocare i buffer — costi proporzionali al totale delle righe.
2. Numero di nodi. Mezzo milione di record × (un oggetto + cinque campi) fa 3,5 milioni di nodi. Qualsiasi visualizzatore che costruisce l'albero completo prima di mostrare paga la stessa memoria e lo stesso tempo, che tu apra un ramo o tutti.

Da qui due corollari controintuitivi. Formattare prima di guardare danneggia — il file cresce da 45 a 71 MB e le righe si moltiplicano per quaranta, pura pressione aggiuntiva per lo strumento. Buttare il file con cat nel terminale danneggia ugualmente — il buffer di scorrimento diventa il nuovo collo di bottiglia; per i primi byte basta head -c 2000.

Tre: scegliere lo strumento per dimensione — tabella decisionale

Dimensioni diverse richiedono strumenti completamente diversi. Combinando le misurazioni sopra con i riferimenti pubblicati (OpenFormatter pone la zona di conforto degli strumenti online a 2-5 MB; PureJSON stima 2-4 GB di memoria dopo il parsing di un documento da 500 MB), la tabella è questa:

Lo strumento /parse di questo sito copre il primo gradino: vista ad albero e validazione. File più grandi appartengono all'app desktop, così che decine di MB non finiscano incollati in una pagina web.

Quattro: non aprire il file — chiedi prima la sua struttura

Davanti a un grande JSON sconosciuto, il primo gesto non è aprire ma spendere qualche secondo per capirne la forma. jq risponde a tre domande in circa 200 ms:

复制# In cima un array o un oggetto? Quanti record?
jq 'if type == "array" then {type: "array", count: length} else {type: "object", keys: (keys|length)} end' huge.json

# Come appare il primo record (uno solo, senza alluvione)?
jq '.[0]' huge.json | head -40

# Tutti i nomi dei campi (presi dal primo record)
jq '.[0] | keys' huge.json

Conosciuta la struttura, la maggior parte delle richieste si riduce a «estrarre un campo» — il file non va nemmeno aperto. Per esempio, per prendere l'email di ogni utente:

复制jq -r '.[].email' huge.json | less
# Sovrapponi un filtro
jq -r '.[] | select(.active == true) | .email' huge.json

La regola è semplice: per guardare, un visualizzatore con rendering virtualizzato; per cercare ed estrarre, jq. Non mescolare i due ruoli in un unico strumento.

Cinque: la scarpata di memoria — modalità normale contro streaming, 150 volte di differenza

Sullo stesso campione da 45 MB, /usr/bin/time -v ha misurato il picco di memoria di jq in due modalità:

La modalità normale legge l'intero file e costruisce il grafo di oggetti; il picco di 542 MB conferma la regola «grafo di oggetti ≈ 7-12× la dimensione del testo». --stream consuma l'input token per token, mantenendo la memoria a pochi MB — al prezzo di un tempo totale maggiore. Oltre la soglia del gigabyte, questa differenza separa «gira» da «ucciso dall'OOM killer»:

复制# Per file più grandi della memoria: --stream è l'unico modo che non carica mai tutto
jq --stream -n 'fromstream(1|truncate_stream(inputs))' huge.json

L'equivalente Python è ijson: ijson.items(f, 'item') produce gli elementi dell'array uno alla volta con la stessa memoria costante. Il prezzo comune di questi strumenti è rinunciare all'accesso casuale — uno stream è un solo passaggio in avanti, e un secondo passaggio significa rileggere il file.

Sei: quanto può mostrare il browser — i limiti dell'elaborazione locale

Gli strumenti online funzionano, entro limiti. Una scheda moderna del browser ha circa 1-4 GB di memoria; un file da 45 MB parsato in grafo più albero di solito sopravvive. Alcune centinaia di MB sono già al bordo della scarpata. Scegliendo un visualizzatore online, esigi tre cose:

1. L'elaborazione avviene localmente (il contenuto incollato non viene mai inviato a un server), il che protegge i dati e risparmia il tempo di caricamento — tutti gli strumenti di questo sito girano interamente nel browser e funzionano offline;
2. Il parsing gira in un Web Worker — il thread principale non si congela, e un blocco costa una scheda, non l'intero browser;
3. L'albero è virtualizzato o a espansione pigra — i rami ripiegati non costano quasi nulla, viene renderizzato solo ciò che apri.

Su questo sito: /parse è adatto all'esplorazione della struttura e alla localizzazione degli errori fino a qualche decina di MB; oltre, jq o l'app desktop, riservando il browser a piccoli frammenti.

Sette: il formato giusto elimina metà dei problemi

Se puoi influenzare come il file viene prodotto, un visualizzatore migliore è il rimedio sbagliato — fai in modo che non diventi «un unico array gigantesco»:

• NDJSON/JSONL: un record per riga. L'aggiunta non riscrive il file, e head, grep, tail, split funzionano direttamente; un file troncato perde solo l'ultima riga. Il nostro manuale JSONL copre in dettaglio il trattamento delle righe rotte.
• Export paginati: un'API che restituisce 100.000 record dovrebbe accettare parametri di paginazione — 100 alla volta è più comodo per entrambe le parti.
• I dati tabulari non sono JSON: un record per riga, campi fissi senza annidamento — è una tabella. CSV o Parquet sono più compatti e hanno ecosistemi più ricchi.

Una cifra da ricordare: taglia a metà un array di 500.000 record, e la prima metà resta un file NDJSON valido (metà dei record sopravvive), mentre l'array unico corrispondente si perde del tutto. 500 record recuperati su 501 valgono più di zero.

Otto: checklist

• Sonda prima la struttura con jq '.[0] | keys' o un campione di 500 record;
• Non formattare mai solo per aprire un file — raddoppiare le righe lo rende solo più lento;
• Sotto 2 MB: vista ad albero online; sopra 20 MB: riga di comando; sopra 1 GB: sempre --stream o ijson;
• Verifica che lo strumento online elabori localmente (il contenuto incollato non lascia il browser);
• Se controlli il generatore, passa a NDJSON o alla paginazione ed elimina gli array giganteschi alla fonte.

FAQ

Perché l'editor impiega decine di secondi ad aprire il JSON se il programma lo parsa in 200 ms?

Il parsing è codice nativo che converte testo in strutture dati: 249 ms sul nostro campione da 45 MB. L'editor si impiglia sulla presentazione: cinque milioni di righe da impaginare, evidenziare e bufferizzare per l'annullamento; l'albero costruisce un DOM di 3,5 milioni di nodi. Un visualizzatore virtualizzato o l'estrazione diretta con jq aggira tutto.

jq va in overflow su JSON oltre 1 GB?

In modalità normale sì: carica l'intero documento e il grafo di oggetti culmina a 7-12× la dimensione del file. Con --stream l'input viene consumato token per token: il nostro test da 45 MB è culminato a 3,6 MB, e la memoria resta piatta qualunque sia la dimensione — al prezzo di un solo passaggio sequenziale.

Quanto grandi possono essere i file per gli strumenti JSON online?

La maggior parte è a suo agio fino a 2-5 MB e si degrada chiaramente oltre i 10 MB. Il tetto rigido è la memoria della scheda (circa 1-4 GB), ma già a qualche decina di MB l'attesa per parsing e costruzione dell'albero pesa. Oltre i 20 MB passa a uno strumento locale o alla riga di comando.

Come leggo il valore di un solo campo in un JSON enorme?

Estrai con jq senza aprire il file: jq -r '.[].email' huge.json stampa tutte le email; con filtro, jq -r '.[] | select(.active == true) | .email'. Per i primi record, jq '.[0:5]' huge.json — ordini di grandezza più veloce che aprire il file.

Formattare prima di aprire aiuta?

No. La formattazione trasforma 45 MB compatti in 71 MB e una riga in cinque milioni, aggiungendo puro onere a editor e visualizzatore. Riserva la formattazione a ciò che una persona leggerà — e solo se il file è abbastanza piccolo.