Validatore JSON gratuito

Informazioni sulla validazione JSON

Un validatore JSON risponde a una domanda binaria, è questo un documento JSON ben formato?, passando l'input allo stesso parser che il browser usa internamente e segnalando se accetta la sintassi. Questo strumento fa quello e solo quello. Non controlla se i dati all'interno del documento significano quello che intendevi. Quella seconda domanda, il documento ha la forma, i tipi e i vincoli che la tua applicazione si aspetta?, è la validazione di schema, il territorio di strumenti come Ajv (trattato qui sotto). Le due attività si completano a vicenda e rispondono a domande diverse; usarne una quando volevi l'altra è un errore di categoria. Un'analogia utile è la distinzione spelling-check / grammar-check nei word processor: lo spelling check (sintassi) ti dice se ogni parola è una vera parola; il grammar check (schema) ti dice se la frase ha senso; entrambi sono utili, nessuno sostituisce l'altro, e nessuno ti dice se il saggio è buono. {"phoneNumber": 12345} è JSON ben formato, ma se la tua applicazione si aspettava una stringa formattata come "+1-555-555-1234", è sbagliato, e un validatore di sintassi non può dirlo.

Oltre al controllo della sintassi, questo strumento offre anche un passaggio "Risolvi problemi comuni" best-effort che riscrive i quattro modi più frequenti in cui gli sviluppatori scrivono accidentalmente JSON non valido: virgole finali, stringhe a virgolette singole, chiavi senza virgolette, e letterali undefined (riscritti come null). È un'euristica, non un parser, quindi rivedi sempre l'output corretto prima di adottarlo.

Una breve storia di JSON

JSON ha una biografia notevolmente breve. L'acronimo è stato coniato presso State Software, Inc., una piccola società di consulenza che Douglas Crockford e Chip Morningstar hanno cofondato nel marzo 2001 per costruire quelle che sarebbero state chiamate applicazioni web Ajax. Il primo messaggio JSON è stato inviato nell'aprile 2001 da un computer nel garage di Morningstar nella Bay Area. Crockford non rivendica di aver inventato JSON, il formato esisteva già all'interno del linguaggio JavaScript come sottoinsieme di literal di oggetto; il suo contributo è stato staccarlo, dargli un nome, mettere su un sito web (json.org è andato online nel 2002 con una descrizione della grammatica in tre notazioni e un parser di riferimento JavaScript), e fare lobbying per l'adozione. Dicembre 2005 è il momento che la maggior parte degli storici indica come l'attraversamento di JSON nel mainstream: quel mese, Yahoo! ha iniziato a offrire alcuni dei suoi servizi web in JSON. L'IETF lo ha raccolto dopo: RFC 4627 ("The application/json Media Type for JSON"), redatto da Crockford stesso, è stato pubblicato nel luglio 2006 come documento informativo, non Standards Track. Gli organismi di standardizzazione hanno recuperato nel 2013-2014: ECMA-404 1a edizione nell'ottobre 2013 (deliberatamente minimale, sei pagine di contenuto sostanziale), RFC 7159 nel marzo 2014 (ha allentato la restrizione di top-level così che qualsiasi valore JSON, non solo oggetti e array, potesse essere un documento completo), e la coppia attuale nel dicembre 2017: RFC 8259 (ora Internet Standard STD 90) e ECMA-404 2a edizione allineate normativamente. I due si accoppiano: ciascuno fa riferimento normativo all'altro e contiene un impegno a mantenerli coerenti. Pubblicato anche come ISO/IEC 21778:2017.

La grammatica JSON in 200 parole

Un documento JSON è un singolo valore, opzionalmente circondato da spazi bianchi. Ci sono esattamente sei tipi di valore: oggetto, una collezione non ordinata di zero o più coppie nome/valore, scritto {"k": v, "k2": v2}; array, una sequenza ordinata, [v, v2, v3] (gli array preservano l'ordine per specifica); stringa, una sequenza di caratteri Unicode racchiusi tra virgolette doppie (virgolette singole non permesse; backslash escapa \", \\, \/, \b, \f, \n, \r, \t più \uXXXX; i caratteri di controllo da U+0000 a U+001F devono essere escapati); numero, una forma ASCII rigorosa (segno meno opzionale, parte intera senza zeri iniziali, parte frazionaria opzionale, esponente opzionale con e o E); true / false, booleani JSON, solo minuscolo; null, l'assenza di valore, solo minuscolo. Lo spazio bianco tra i token è permesso e ignorato. Nessun commento. Nessuna virgola finale. Le chiavi degli oggetti devono essere stringhe tra virgolette doppie. La grammatica sta su una pagina. La forma rigorosa dei numeri vieta hex (0xFF), ottale (0777), segno +, Infinity, NaN, e punti decimali finali come 1.; questo cattura chiunque scriva JSON a mano in ambienti che accettano le forme numeriche più rilassate di ECMAScript, più comunemente, chiunque abbia mai incollato un codice colore esadecimale in un file JSON.

Perché la grammatica è così rigorosa, le scelte di design di Crockford

Due omissioni deliberate spiegano la maggior parte dell'attrito che gli utenti sentono quando scrivono JSON a mano. Nessun commento. JavaScript ha sia i commenti // che /* */; JSON, il sottoinsieme di JavaScript, non ha nessuno dei due. La ragione dichiarata di Crockford, pubblicata su Google+ nel 2012, è stata citata migliaia di volte da allora: "Ho rimosso i commenti da JSON perché ho visto persone usarli per contenere direttive di parsing, una pratica che avrebbe distrutto l'interoperabilità. So che la mancanza di commenti rende alcune persone tristi, ma non dovrebbe." L'argomento è che i commenti invitano all'estensione, se // @schema foo.json è nel tuo config e il tuo strumento lo legge, allora il tuo file di config non è più JSON. Nessuna virgola finale. Una virgola è un separatore, non un terminatore. [1, 2, 3] è legale ma [1, 2, 3,] no. La ragione è la stessa dei commenti: semplicità della grammatica e uniformità tra i parser. Il costo è che chiunque modifichi un oggetto JSON multiriga, aggiungendo una proprietà, riorganizzando le proprietà, eliminando l'ultima proprietà, deve pensare alla virgola. Nessun undefined. JavaScript ha undefined; JSON no. Usa null o ometti completamente la proprietà. BOM nell'input. Un byte-order mark (U+FEFF) all'inizio di un documento JSON è proibito nel JSON trasmesso, ma i parser POSSONO ignorarne uno se appare. In pratica, i file salvati come "UTF-8 con BOM" da editor Windows più vecchi rompono silenziosamente alcuni parser e funzionano silenziosamente in altri.

Errori JSON comuni:

• Virgole finali: l'ultimo elemento di un oggetto o di un array non può avere una virgola
• Apostrofi al posto delle doppie virgolette: JSON consente solo le doppie virgolette per le stringhe
• Chiavi senza virgolette: le chiavi degli oggetti devono sempre essere tra doppie virgolette
• Commenti: JSON non supporta i commenti (anche se alcuni strumenti li accettano)
• Backslash non escapato. Dentro una stringa JSON, \ è il carattere di escape. "C:\Users\Alice" fallisce perché \U e \A non sono escape riconosciuti. La cura è raddoppiare ogni backslash: "C:\\Users\\Alice".
• Caratteri di controllo non escapati. Una newline letterale, tab, o altro carattere in U+0000-U+001F dentro una stringa JSON è proibito. La maggior parte degli utenti colpisce questo quando incolla una stringa multiriga in un valore JSON senza escapare le newline come \n.
• NaN e Infinity. Non fanno parte della grammatica JSON. Il JSON.parse del browser li rifiuterà. JSON.stringify produce null quando gli viene chiesto di serializzare NaN o Infinity, quindi il round-trip perde silenziosamente informazioni.
• Input vuoto. Lancia "Unexpected end of JSON input." La trappola è che una risposta HTTP tornata con Content-Type: application/json ma con un body vuoto produce questo errore nelle catene fetch().then(r => r.json()).

JSON Schema, lo standard per la validazione della forma

JSON Schema è un vocabolario basato su JSON per descrivere la struttura e i vincoli dei documenti JSON. La prima proposta è stata presentata da Kris Zyp nell'ottobre 2007; la serie IETF Internet-Draft è iniziata con draft-zyp-json-schema-00 il 5 dicembre 2009. Le bozze successive sono evolute attraverso una mezza dozzina di autori ed editor nel decennio e mezzo successivo. La versione stabile attuale è la bozza 2020-12 (il nome "2020-12" si riferisce alla snapshot di sviluppo da cui deriva; il rilascio formale effettivo è stato il 16 giugno 2022). Le quattro parole chiave di asserzione più usate svolgono la maggior parte del lavoro quotidiano: type (vincola un valore a uno dei sei tipi JSON o a una lista di tipi accettabili), required (una lista di nomi di proprietà che un oggetto deve contenere), properties (una mappa dal nome della proprietà al sotto-schema per il valore), e items (uno schema applicato a ogni elemento di un array). Combinate con minimum, maximum, minLength, maxLength, pattern (regex), format (date-time, email, IPv4, ecc.) e le parole chiave composite (allOf, anyOf, oneOf, not), JSON Schema può esprimere quasi qualsiasi vincolo di "forma" che i tuoi dati devono soddisfare. Lo schema stesso è un documento JSON, che è ricorsivo in un modo che alcune persone trovano elegante e altre vertiginoso.

Ajv, il validatore di schema JavaScript dominante

Se vuoi fare validazione di schema in JavaScript, la risposta canonica è Ajv (Another JSON Schema Validator) di Evgeny Poberezkin. Il suo trucco è compilare lo schema in JavaScript ottimizzato: invece di camminare lo schema e l'albero dei dati a runtime, genera una funzione che codifica ogni controllo e gira a velocità nativa. Questo lo rende drammaticamente più veloce dei validatori ingenui su documenti grandi e su percorsi di validazione caldi. Ajv supporta le bozze JSON Schema 04, 06, 07, 2019-09 e 2020-12; è il validatore integrato in express-validator, nella validazione delle richieste AWS API Gateway e in molti dei principali framework Node.js. Per Python, la scelta canonica è jsonschema di Julian Berman; per Java, json-schema-validator di Networknt. Il punto è che la validazione di schema è un problema risolto, maturo, ben strumentato, ma è un problema in cui devi optare scrivendo lo schema. Questo strumento non scrive lo schema per te; fa solo validazione sintattica.

JSON5 e JSONC, i superset rilassati

JSON5 è un superset formale di JSON specificato su json5.org, originariamente progettato da Aseem Kishore nel 2012 e ora mantenuto da Jordan Tucker. Permette tutto ciò che il JSON stretto vieta: commenti (sia // che /* */), virgole finali, stringhe a virgolette singole, chiavi di oggetto senza virgolette (quando sono identificatori ECMAScript validi), numeri esadecimali, punti decimali iniziali/finali (.5 o 5.), Infinity e NaN, e numeri con segno. I documenti JSON5 usano tipicamente l'estensione .json5 e sono parsati da librerie come il pacchetto npm json5. JSONC è la modalità informale "JSON con commenti" di Microsoft, usata nei file di impostazioni di VS Code (settings.json, launch.json, tasks.json). I commenti sono permessi dalla specifica; le virgole finali sono tollerate dal parser di riferimento ma segnalate con avvisi. Le forme rilassate sono per file di configurazione modificati da umani dove la disciplina del JSON stretto si mette in mezzo; per lo scambio di dati macchina-macchina, il JSON stretto è ancora la scelta giusta. Questo strumento usa il JSON.parse stretto del browser e quindi rifiuterà entrambi, rimuovi commenti e virgole finali prima di incollare, o usa un parser JSON5/JSONC per convertire prima in JSON stretto.

Validatori streaming per input molto grandi

Il JSON.parse del browser carica l'intero documento in memoria come un singolo albero di oggetti. Per la maggior parte degli input va bene; per file di log, export API multi-gigabyte o dump di dati sensore, no. L'approccio streaming è consumare il documento come un flusso di token ed emettere eventi ("inizio array", "valore stringa", "chiave oggetto") senza mai tenere l'intera struttura in memoria. clarinet di Marak Squires è il parser JSON streaming canonico di Node.js, modellato sul pattern del parser SAX XML. Oboe.js di Jim Higson (originato dalla sua tesi del 2013) è l'equivalente browser-friendly, progettato per consumare JSON tramite fetch mentre arriva in streaming ed emettere eventi per ogni JSONPath corrispondente; non è più mantenuto attivamente ma la tecnica che ha pionierizzato è ancora utile. JSONStream su npm avvolge clarinet per l'uso pipe-friendly in Node. Uno strumento puro-browser come questo è limitato dalla memoria disponibile; se stai validando JSON su scala gigabyte, esegui un parser streaming in Node o usa jq --stream da riga di comando.

Dove la validazione JSON conta nei flussi di lavoro reali

I file di configurazione sono il caso di massima leva: tsconfig.json, package.json, config di ESLint e Prettier, Docker Compose, policy AWS IAM. Un singolo carattere invalido può rompere il build; un validatore sintattico lo cattura prima che lo faccia il build. Le risposte API sono le successive: sviluppare contro un'API esterna spesso significa fissare un payload e chiedersi "questa cosa è effettivamente JSON valido?" prima di inseguire un bug di parsing più in profondità nel codice. I payload webhook, gli eventi Stripe, i trigger GitHub Actions, gli incoming webhook Slack, sono JSON; un rapido paste-and-validate cattura i casi dove una firma malformata o un byte spurio ha corrotto il body. Le voci di log (Splunk, Datadog, log strutturati Loki) sono JSON delimitato da righe; una riga errata rompe l'intera pipeline di ingestione. I file JSON generati (lockfile, build manifest, fixture di test) a volte derivano in modi rumorosi durante lo sviluppo normale; un validatore sintattico cattura i casi dove il passo di generazione stesso è fallito.

I limiti onesti di un validatore solo-sintassi

Un validatore sintattico non può catturare errori logici. Non può dirti che un campo "numero di telefono" contiene un intero invece di una stringa; che una stringa "data" è malformata ma capita essere una stringa valida; che un campo obbligatorio manca; che un numero che dovrebbe essere positivo è negativo; che due campi che dovrebbero corrispondere non corrispondono. Tutti questi sono problemi di validazione di schema. La pipeline giusta per un sistema di produzione è: (1) validazione sintattica come primo gate, questo si parsa come JSON? (2) validazione di schema come secondo gate, ha la forma che ti aspetti? (3) validazione di logica di business come terzo gate, i dati hanno senso dato altro stato? Esistono strumenti per tutti e tre i livelli; questo gestisce solo il primo. Il vantaggio di incollare un payload in un validatore sintattico prima è che isola la modalità di fallimento più economica e più comune (una virgola spuria, una parentesi mancante) dagli errori di schema più costosi che altrimenti la annegerebbero.

Privacy: perché il solo-browser conta qui

La validazione JSON su un server richiede di caricare il documento. Per esempi ordinari di dati pubblici questo è innocuo. Per risposte API che contengono token di autenticazione, PII cliente, record interni di dipendenti, segreti di configurazione o dati di prodotti non rilasciati, no. Anche con la politica di cancellazione più scrupolosa, l'upload rimane nei log del server, possibilmente in una cache CDN, possibilmente in una pipeline di analisi, possibilmente in un backup. Questo strumento esegue JSON.parse nel tuo browser tramite JavaScript. Il documento incollato non attraversa mai la rete, verifica nel tab Network di DevTools mentre clicchi un pulsante, o porta la pagina offline (modalità aereo) dopo che si carica e conferma che il validatore funzioni ancora. Sicuro per validare payload webhook con segreti, risposte API con header di autenticazione, file di configurazione con credenziali di database, o qualsiasi altro JSON che non vorresti copiato sull'hard drive di uno sconosciuto.

Domande frequenti

Cos'è un JSON valido?

Un JSON valido deve essere uno di questi tipi: oggetto ({}), array ([]), stringa (""), numero, booleano (true/false) o null. Tutte le stringhe e le chiavi degli oggetti devono usare doppie virgolette. I numeri non possono avere zeri iniziali. Gli spazi sono consentiti tra gli elementi.

Cosa fa «Correggi i problemi comuni»?

La funzione di correzione tenta di correggere automaticamente gli errori frequenti: virgole finali, apostrofi convertiti in doppie virgolette, chiavi senza virgolette e valori undefined convertiti in null. È uno strumento euristico che potrebbe non risolvere tutto, rivedi attentamente il risultato.

Come valido del JSON nella mia applicazione?

In JavaScript: usa JSON.parse() e cattura gli errori. In Node.js: fs.readFileSync() + JSON.parse(). In Python: json.loads() o json.load(). La maggior parte dei linguaggi dispone di librerie integrate per la validazione JSON.

Posso validare JSON5 o JSONC (JSON con commenti)?

Non direttamente. Questo strumento usa il JSON.parse stretto del browser, che segue RFC 8259, commenti, virgole finali, virgolette singole e chiavi senza virgolette sono errori di sintassi. Se il tuo input è JSON5 (json5.org, Aseem Kishore 2012, mantenuto da Jordan Tucker) o JSONC di VS Code, installa il pacchetto npm json5 o il pacchetto jsonc-parser, converti in JSON stretto, poi valida. Il passaggio "Risolvi problemi comuni" gestisce un sottoinsieme delle differenze ma non è un parser completo JSON5 / JSONC.

C'è un limite di dimensione?

Nessun limite rigido, ma il JSON.parse del browser carica l'intero documento in memoria come un singolo albero di oggetti. Decine di migliaia di righe funzionano comodamente; dump di log multi-gigabyte esauriranno la memoria. Per JSON molto grandi, esegui un parser streaming come clarinet (Marak Squires) o Oboe.js (Jim Higson, 2013), o usa jq --stream da riga di comando, che può processare documenti di dimensione arbitraria senza mai caricare l'intera cosa.

I miei documenti JSON vengono caricati?

No. JSON.parse gira nel tuo browser tramite JavaScript. Il documento incollato non attraversa mai la rete, verifica nel tab Network di DevTools mentre clicchi Valida, o porta la pagina offline dopo che si carica e conferma che lo strumento funzioni ancora. Sicuro per validare payload webhook con segreti, risposte API con header di autenticazione, o file di configurazione con credenziali di database.