Formattatore JSONL

Informazioni su GeekFormat

Incolla qui JSONL o NDJSON. Le righe vuote vengono ignorate automaticamente e ogni riga di dati deve essere un oggetto JSON completo.

Il risultato formattato verrà mostrato qui.

Ogni riga non vuota dovrebbe essere un oggetto JSON completo.

Righe totali: 1Righe non vuote: 0Righe valide: 0Righe non valide: 0

Incolla JSONL per avviare subito la formattazione.

Una pagina leggera di formattazione JSONL pensata per log, archivi di sessione ed export in streaming. Incolla a sinistra gli oggetti JSON separati da interruzioni di riga e visualizza subito a destra il risultato formattato di ciascun record, vedendo direttamente quale riga è errata.

Raccomandazioni correlate

Formattatore JSON

Riparare JSON

Compressione JSON

JSON Stringify

Validatore di Schema JSON

Che cos'è la formattazione JSONL?

JSONL (JSON Lines) è un formato testuale che organizza i record JSON per righe. La sua caratteristica centrale non è «assomigliare a JSON», ma che «ogni record occupa una riga a sé». Nell'ingegneria reale ciò si traduce quasi sempre in: ogni riga non vuota è un oggetto JSON completo, con gli oggetti separati da interruzioni di riga invece di essere ulteriormente racchiusi in un grande array `[{...},{...}]`.

Questa organizzazione è particolarmente adatta a log, flussi di eventi, archivi di sessione, export di massa ed elaborazione in streaming: il programma non deve caricare l'intero file in memoria, ma può consumare i record riga per riga. Se una riga è danneggiata, si individua direttamente il suo numero invece di contare parentesi e cercare virgole alla cieca dentro un array JSON lunghissimo.

La formattazione JSONL non è la stessa della formattazione JSON normale. Un formattatore normale presume che l'input sia un unico documento JSON completo; un formattatore JSONL deve invece analizzare, convalidare e segnalare errori riga per riga, preservando la semantica dei record separati da interruzioni. Per log e file di export questa differenza è fondamentale.

Questa pagina è progettata attorno a questa semantica reale: a sinistra si inseriscono i record oggetto separati da righe, a destra viene mostrato il risultato formattato per record, mentre le righe errate, troncate e non-oggetto vengono indicate direttamente. Così, analizzando un file `.jsonl`, vedi «quale record ha problemi» invece di ricevere un generico `SyntaxError`.

Casi d'uso

Abbellire record per record il JSONL esportato dai log dell'applicazione prima di esaminare campo per campo, invece di fissare una lunga sequenza di oggetti compressi su una sola riga
Controllare i file di archivio delle sessioni in cui ogni riga è un oggetto evento, verificando che ogni record sia completo e leggibile
Quando fallisce un export bulk di una pipeline dati, di una piattaforma di tracking o di Elasticsearch, individuare subito quale riga dell'oggetto JSON è scritta male
Nel debug di interfacce a output in streaming, verificare che il server produca davvero «un oggetto per riga» in modo continuo invece di emettere in anticipo un oggetto a metà
Incollare NDJSON copiato da terminale, pannelli di monitoraggio o piattaforme di log cloud: prima riorganizzare la struttura, poi proseguire l'analisi
Controllare se nei risultati a oggetti riga per riga generati dall'IA qualche riga contiene per errore un array, una stringa o JSON incompleto
Prima di importare in flussi basati su record di riga come ClickHouse, BigQuery o Kafka Connect, riesaminare manualmente il contenuto JSONL
Nel riesame di log di audit, eventi di rischio o flussi di eventi di tracking, verificare record per record se la struttura degli oggetti resta stabile e coerente
Quando un file JSONL è troncato o scaricato in modo incompleto, vedere subito qual è l'ultimo oggetto non chiuso
Formattare prima il JSON delimitato da righe esportato dagli strumenti interni, poi inviarlo a un collega per code review o verifica dati
Prima di scrivere uno script che analizzi JSONL, confermare manualmente livelli dei campi, oggetti annidati e posizione degli array per ridurre i tempi di debug dello script
Nel trattare export storici con righe vuote ed errate mescolate, filtrare prima i problemi strutturali prima di decidere se proseguire con la conversione in CSV o l'import in database

Come utilizzare

Incolla il contenuto JSONL o NDJSON nell'area di input, assicurandoti che ogni riga non vuota sia un oggetto JSON indipendente
A destra verrà formattato subito riga per riga e, sulle righe errate, verranno indicati numero di riga, messaggio di errore e record originale
Correggi le righe segnalate in base ai suggerimenti finché il numero di righe non valide non arriva a zero
Dopo aver confermato che tutto è valido, copia il risultato formattato completo oppure invia i dati a script, importatori e processi di analisi a valle

Funzionalità

Analizza JSONL / NDJSON riga per riga, senza dover prima racchiudere manualmente i dati in un array JSON completo come `[{...},{...}]`
Convalida secondo la semantica reale «ogni riga non vuota è un oggetto JSON», adatta a forme dati comuni come log, flussi di eventi e archivi di sessione
Layout a due colonne: input `textarea` a sinistra e anteprima formattata in tempo reale a destra, ideale per correggere mentre si controlla
Le righe errate mostrano direttamente numero di riga, errore di parsing e contenuto originale, per riparare rapidamente record troncati, parentesi mancanti ed errori di concatenazione
La copia si sblocca solo quando tutte le righe non vuote sono valide, evitando di passare ai processi a valle dati in parte corretti e in parte danneggiati
Statistiche integrate per righe totali, non vuote, valide e non valide, per capire al volo quanti record sono danneggiati in un file grande
Include dati di esempio per provare subito la formattazione JSONL al primo avvio
Tutta l'elaborazione avviene localmente nel browser; log, eventi di sessione ed export delle API non vengono caricati

Formattatore JSONL vs formattatore JSON vs riparazione JSON

Questi strumenti si usano spesso in sequenza, ma risolvono problemi diversi. Scegliere l'ingresso giusto fa risparmiare molto tempo.

Strumento	Input più adatto	Capacità principale	Scenario d'uso
Formattatore JSONL	Un oggetto JSON per riga	Convalida e abbellisce record per record	Log, NDJSON, archivi di sessione, export in streaming
Formattatore JSON	Un oggetto o array JSON completo	Abbellisce l'intero documento JSON	Risposte API, file di configurazione, payload singoli
Riparazione JSON	Testo JSON con errori di sintassi o non standard	Ripara prima la sintassi poi passa agli strumenti successivi	Virgole finali, commenti, problemi di virgolette, JSON troncato

Best Practices

In debug mantieni la forma JSONL originale, invece di racchiuderla manualmente in un array solo per capirla

Se il sistema a valle si aspetta JSONL, cerca di analizzare i dati nella forma originale «un record per riga». Racchiuderli in un array permette di passarli a un formattatore normale, ma fa perdere la semantica dei numeri di riga originali e rende più difficile risalire alla vera posizione della riga errata.

Nei file grandi guarda prima le ultime righe

Molti file JSONL non hanno un errore strutturale nel mezzo: sono le ultime righe a essere troncate per interruzione del flusso, download fallito o scrittura incompiuta. Esaminare prima gli ultimi record è di solito più veloce che scorrere l'intero file dall'inizio.

Se l'input contiene virgolette singole, commenti o stile JSON5, passa prima dalla riparazione JSON: risparmi tempo

La pagina JSONL punta sulla convalida degli oggetti riga per riga; se i dati sorgente non sono JSON standard in partenza, riparare prima di formattare è di solito più efficiente che correggere manualmente ogni riga di un file lungo.

In vista di una reimportazione, conserva sempre la semantica di trasporto «un oggetto per riga»

Il blocco abbellito multilinea a destra è più comodo da leggere per una persona, ma se devi riscrivere i dati in un sistema di log, in una coda di messaggi o in un importatore, mantieni la struttura sorgente un oggetto per riga invece di usare l'anteprima come formato di trasporto finale.

Usa i numeri di riga come indizio principale, invece di rileggere a occhio l'intero file

Nel debug vero e proprio, il metodo più rapido è di solito fissare prima il numero di riga errato e confrontare quel record con i record validi vicini. Così si capisce più in fretta se mancano parentesi o virgolette, se un campo è troncato o se un oggetto contiene un tipo sbagliato.

Domande frequenti

Che differenza c'è tra JSON e JSONL?

Il JSON normale è di solito un intero oggetto o array da analizzare come un unico documento completo; JSONL (JSON Lines, spesso chiamato anche NDJSON) ha invece un record indipendente per riga, e nella pratica ingegneristica la forma più comune è «un oggetto JSON per riga». È più adatto a log, flussi di eventi, elaborazione in streaming e import di massa, perché si può leggere, scrivere e localizzare gli errori riga per riga.

Perché questa pagina insiste su «un oggetto JSON per riga»?

Perché nel mondo reale la maggior parte dei file JSONL è organizzata così, soprattutto log, archivi di sessione, flussi di eventi ed export. Anche i tuoi campioni di archivio seguono questa forma tipica: ogni riga è un oggetto separato da un'interruzione di riga. La pagina convalida con questa semantica, molto più aderente al debug reale rispetto ad accettare in modo generico qualsiasi valore JSON.

In cosa JSONL differisce da un array JSON come `[{...},{...}]`?

Un array JSON è un documento JSON completo che va letto interamente prima di essere analizzato; JSONL invece suddivide ogni oggetto in record di riga indipendenti, può essere letto in streaming e permette di individuare direttamente la riga quando un record fallisce. Per file di log grandi e flussi di eventi, JSONL è più indicato di un array unico.

Perché le righe vuote vengono ignorate?

Le righe vuote di solito derivano da copia e incolla, rotazione dei log o modifica manuale e non rappresentano veri record di dati. Ignorarle riduce il rumore, continuando però a controllare in modo rigoroso tutte le righe che contengono contenuti.

Cosa succede se una riga è un array, una stringa o `null`?

Questa pagina la giudicherà una riga non valida, perché il formato di destinazione è «ogni riga non vuota è un oggetto JSON». Se i tuoi dati devono davvero memorizzare array o valori grezzi riga per riga, non si tratta dello scenario tipico di log JSONL per cui questa pagina è ottimizzata.

Perché con una riga errata non si può copiare subito tutto il risultato?

È un'interazione volutamente conservativa. La copia è consentita solo quando tutte le righe non vuote sono valide, per evitare di passare a importatori, script o colleghi un risultato in parte riuscito e in parte danneggiato, risparmiando un secondo giro di debug.

Può aiutarmi a scoprire file di log troncati?

Sì. Molti problemi JSONL nascono nelle ultime righe: per esempio a un oggetto manca `}`, a una stringa manca la virgoletta di chiusura oppure il flusso di rete si interrompe a metà. La pagina espone direttamente la riga errata corrispondente, particolarmente utile per download incompleti e interruzioni dell'output in streaming.

JSONL e NDJSON sono la stessa cosa?

Nella stragrande maggioranza dei contesti ingegneristici possono essere considerati sinonimi. Entrambi indicano record JSON separati da interruzioni di riga; cambia solo l'abitudine di denominazione.

La formattazione JSONL carica i miei dati?

No. Tutte le operazioni di analisi, convalida e formattazione vengono eseguite solo localmente nel browser; log, risposte API, archivi di sessione ed export di dati non vengono inviati a nessun server.

Quando usare il formattatore JSON normale invece di quello JSONL?

Se l'input è di per sé un oggetto JSON completo o un array, come il corpo di una risposta API, un file di configurazione o un pacchetto dati come `[{...},{...}]`, va usata la pagina di formattazione JSON normale; solo quando l'input è fatto di record oggetto separati da interruzioni di riga è più adatta questa pagina JSONL.

Glossario

JSONL: Formato testuale con record JSON separati da righe. La scrittura ingegneristica più comune prevede che ogni riga non vuota sia un oggetto JSON completo.
JSON Lines: Il nome esteso e un'altra denominazione comune di JSONL, di solito considerato sinonimo.
NDJSON: Newline Delimited JSON, letteralmente «JSON delimitato da interruzioni di riga». Nella maggior parte degli scenari di log e pipeline di dati è praticamente equivalente a JSONL.
Record per riga: Layout dei dati in cui ogni riga rappresenta un record completo, adatto a scrittura e lettura in streaming e alla localizzazione degli errori per riga.
Pretty Print / formattazione leggibile: Riorganizzare un JSON compresso su una sola riga in una struttura leggibile con indentazione e interruzioni di riga, per agevolare l'ispezione manuale dei livelli dei campi.
Riga errata: Una riga che non è JSON valido oppure che, pur analizzabile, non corrisponde alla struttura attesa (per esempio non è un oggetto) e quindi non può essere un record JSONL valido.
Flusso troncato: Un log o un export interrotto a metà durante trasmissione, flush o salvataggio, così che l'ultimo record non risulti completamente chiuso.
Array JSON: Nel JSON standard, un'intera collezione racchiusa tra `[` e `]`, per esempio `[{...},{...}]`. A differenza di JSONL, va analizzata come un unico documento.

Authoritative References

jsonlines.orgDescrizione ufficiale di JSON Lines
IETFSpecifica ufficiale JSON RFC 8259