Validatore per JSON
Controlla se il testo rispetta la sintassi JSON standard e comprendi perché l'input viene accettato o rifiutato.
Controlla JSON prima di usare i dati
Una virgoletta, una virgola o una parentesi mancante può bloccare un'API, una configurazione o un build step. Questo validator prova a fare il parse del source text come JSON e separa il problema di syntax dalle verifiche successive dell'application.
Qui validation significa soltanto provare a fare il parse del testo come un singolo JSON value. Un parse riuscito indica che la struttura è stata accettata da JSON; non dimostra che required field, business rule o JSON Schema siano corretti.
Quando un payload passa tra più service, un controllo syntax anticipato restringe il campo del debugging. Controlla quote, comma, escape e nesting, poi applica gli schema e i domain check del project.
La pagina è utile per request body, fixture, impostazioni esportate e configuration snippet. Rimuovi token, password e dati personali dalla test copy e segui la privacy policy dell'organizzazione.
Syntax e significato dei dati sono diversi
Il JSON standard contiene object, array, string, number, true, false e null. Property name e string usano double quote, i member sono separati da comma e i bracket devono chiudersi nell'ordine corretto. Comment e trailing comma non fanno parte della JSON grammar standard.
La domanda del validator è limitata: il source può essere interpretato come un JSON value? Il tool non corregge il source, non esegue code, non chiama API e non decide se il value è utile per l'application. Mantieni separati schema e domain check.
Whitespace è di solito accettato per la leggibilità, ma ogni character dentro una string è dato. Controlla escape sequence, newline, Unicode ed encoding con lo stesso parser usato dal production consumer.
Un JSON document valido non rende valido anche il transport. HTTP header, content type, authentication, compression e size limit appartengono a layer diversi.
Come validare JSON
- Incolla un JSON value completo nel source field. Elimina comment, code fence e wrapper del programming language dalla test copy.
- Avvia il validator e leggi status e diagnostic. Controlla i token prima e dopo il marker, perché la causa può trovarsi leggermente prima.
- Se viene rifiutato, controlla quote, comma, bracket, escape e nesting. Per un document grande separa una parte piccola, trova il failing section e invia la versione corretta.
- Dopo il pass della syntax esegui i controlli di schema, type, required property, range, permission e business rule del project. Non riportarli come syntax result.
- Conserva original payload e redacted copy separati. Non inserire secret in public example, screenshot o URL.
- Fai il test finale con lo stesso parser e la stessa encoding del consumer reale. Language e library diverse possono gestire duplicate key e number precision in modo diverso.
Metodo di validation
- Leggere la grammar
Il validator usa regole di token, quote, delimiter e nesting per provare a fare il parse dell'intero source come un JSON value.
- Comunicare il risultato
Valid indica che il parsing è terminato. Failure indica che il source non corrisponde alla syntax compresa dal tool.
- Separare i controlli successivi
Schema, range, permission e domain sono semantic check e richiedono regole ed evidence separate.
Se il tool non documenta exact line number o error message, non inventare dettagli. Se serve, ripeti il test nel runtime reale.
Leggere il risultato
Valid indica che il text è stato accettato come JSON syntax. Poi controlla i value ed esegui schema o application validation.
Invalid indica che il parsing si è fermato. Controlla i character prima e dopo la posizione indicata, non solo il marker.
Se la syntax è valid ma la request fallisce, controlla content type, endpoint, authentication, schema e business rule. Syntax success non equivale a network success.
Se il message è generico, riduci l'input per trovare il failing section. Il cambiamento dopo aver aggiunto o rimosso un property è un indizio, non una policy universale di ogni parser.
Errori comuni
Incollare JavaScript con single quote, comment o trailing comma è un errore frequente. Converti il testo in standard JSON.
Considerare valid result come schema validation è sbagliato. Controlla required field, range e permission separatamente.
Correggere solo il character vicino al marker può non bastare: quote o comma mancanti possono essere precedenti.
Non confondere JSON con Python dictionary, YAML o JavaScript object. Usa la documented JSON grammar.
Clipboard può inserire smart quote o control character nascosti. Se i risultati cambiano, guarda il source in un plain text editor.
Limiti
L'input documentato è un JSON text field. Non dimostra il supporto per JSON Schema, business rule, file processing o ogni parser edge case.
Duplicate key, numeri molto grandi, document size ed encoding vanno testati separatamente quando necessario. La policy può cambiare in base alla library.
Il checker non rende sicuro un malicious payload. Server-side servono size limit, nesting limit, resource limit e security review.
Documenta separatamente production runtime, library version ed error policy. Il risultato generale della pagina non sostituisce questa evidence.
Examples
Object semplice accettato
Questo object di base è valid JSON?
Invia l'object completo.
Name tra double quote, string e boolean formano una valid object structure.
Name senza quote rifiutato
Perché un unquoted property name è invalid?
Invia source e leggi il failure.
Nel JSON standard il member name deve essere una string tra double quote.
Dati nested accettati
Un object può contenere un array di object?
Invia il nested value come un document.
Array, object, number, comma e bracket formano una valid JSON structure.
Trailing comma rifiutata
Cosa succede con una comma dopo l'ultimo member?
Invia l'object con trailing comma.
Il JSON standard non ammette trailing comma. Rimuovila e ripeti il controllo.
Usare null
null è un valid JSON value?
Invia l'object e leggi lo status.
null è un JSON value standard. Il contract del project stabilisce il significato nell'application.
Bracket mancante rifiutato
Perché un opening bracket deve essere chiuso?
Invia una structure sbilanciata.
L'array è aperto con [ ma non è chiuso con ]. Correggi il nesting prima di usare i data.
Frequently asked questions
Valid JSON significa che i dati dell'application sono valid?
No. Significa solo che il text può essere parsato. Required field, type, range, status e business rule richiedono controlli separati.
Il validator ripara automaticamente il source?
Usalo come checker. Correggi il source, conserva il diff e invia di nuovo la copy verificata.
I comment sono permessi?
Nel JSON standard no. Conserva i comment in un altro source format, genera strict JSON nel build step e valida l'output.
Perché le single quote vengono rifiutate?
Name e string nel JSON standard usano double quote. Converti un JavaScript object con un JSON serializer invece di sostituire quote a mano.
Questo tool controlla JSON Schema?
No. Esegui uno schema validator con lo schema e il draft version corretti e registra il risultato separatamente dal syntax result.
Il top-level value può essere un array?
JSON permette un array come top-level value. Tuttavia un endpoint può richiedere un object, quindi testa separatamente l'endpoint contract.
Una duplicate key viene sempre rifiutata?
Non esiste una policy universale. Il parser può mantenere il primo, l'ultimo o dare error. Evita duplicate name e testa il consumer reale.
Cosa fare dopo una validation riuscita?
Esegui schema, permission, range e integration test. Controlla content type, encoding, size, timeout e logging, poi prova il redacted payload in staging.