Strumenti per sviluppatori · JSON formattatore e validatore
Come un validatore JSON trova la riga e la colonna esatte di un errore
· Come funziona
json convalida flusso di lavoro dello sviluppatore
I motori del browser segnalano gli errori JSON.parse in modo diverso e alcuni forniscono solo un offset di carattere. Questo post spiega come un validatore lo trasforma in una riga e in una colonna e perché la posizione indica dove si è interrotta l'analisi anziché dove hai commesso l'errore.
Il messaggio di errore che non ti dice nulla: perché "Token imprevisto in JSON nella posizione 1432" è inutile in un file di riga 400
Un errore come "Token imprevisto" è frustrante in una configurazione lunga perché non offre alcuna posizione che puoi aprire nel tuo editor. JSON.parse è il parser autorevole del browser, ma il suo testo diagnostico differisce a seconda dei motori e delle versioni di JavaScript. ToolAcre non indovina la posizione facendo corrispondere una stringa di errore inglese instabile. Se JSON.parse fallisce, uno scanner rigoroso separato esamina il testo originale per identificare il primo carattere che la grammatica JSON non può accettare.
Cosa fa effettivamente un parser JSON mentre legge: una passeggiata attraverso la tokenizzazione e la grammatica di discesa ricorsiva che consuma un valore alla volta
JSON ha sei caratteri strutturali (parentesi graffe, parentesi, due punti e virgola) e valori che possono essere stringhe, numeri, matrici, oggetti, vero, falso o null. Uno scanner deve sapere se si trova all'interno di una stringa tra virgolette prima di chiamare una virgola un separatore: {"note":"A,B"} ha un valore, non due. Passa attraverso un valore o un membro dell'oggetto e controlla cosa può legalmente seguire dopo. RFC 8259 definisce questa grammatica e, a differenza dei letterali oggetto JavaScript, non consente commenti o virgole finali.
Dall'offset dei caratteri alla riga e alla colonna: conteggio dei ritorni a capo fino all'offset dell'errore e perché le terminazioni CRLF e i caratteri multibyte complicano il conteggio
Uno scanner solitamente inizia con un offset in base zero nella stringa JavaScript originale. Per renderlo utile, conta le interruzioni di riga prima dell'offset e trova quanto dista l'errore dall'ultima interruzione. CRLF deve essere trattato come una riga finale visiva, non come due righe; le posizioni nelle stringhe JavaScript contano le unità di codice UTF-16, non UTF-8 byte sul disco. Un'emoji nonBMP può occupare due unità di codice in un editor che mostra visivamente un glifo. L'interfaccia utente riporta una riga, una colonna e un estratto in modo da poter confrontare il cursore con il file che hai incollato.
Il punto in cui l'analisi si interrompe non è dove si trova l'errore: una virgola mancante viene riportata al tasto successivo e una virgoletta vagante può spingere l'errore molte righe più in basso
Il primo token impossibile è spesso dopo l'errore originale. In un oggetto, dimenticare una virgola dopo true rende illegale la virgoletta che inizia con la proprietà successiva: il parser si aspettava una virgola o una parentesi graffa di chiusura. Una stringa senza terminazione può causare la visualizzazione dell'errore in un'interruzione di riga successiva o alla fine dell'input. Leggere all'indietro dal punto riportato per trovare il delimitatore mancante; non dare per scontato che il carattere sotto l'accento circonflesso debba essere cancellato.
Esempio funzionante: una configurazione con una virgola mancante: la posizione segnalata, i token circostanti e come tornare indietro fino alla vera causa
Prova il documento letterale di tre righe {"name":"demo", seguito da "enabled":true alla riga due e "port":8080} alla riga tre, senza virgola dopo true. ToolAcre riporta la riga 3, colonna 1, offset 31: prevedeva una virgola o } dopo la proprietà precedente e mostra un accento circonflesso sotto la prima virgoletta di "port". Inserisci una virgola alla fine della riga due, quindi convalida nuovamente. Questa è una diagnosi del primo ostacolo sintattico, non un giudizio secondo cui la parola “porta” è sbagliata.
Differenze tra i motori dei browser: V8, SpiderMonkey e JavaScriptCore esprimono lo stesso errore in modo diverso, ecco perché un report coerente di righe e colonne aiuta
V8, SpiderMonkey e JavaScriptCore hanno utilizzato termini diversi e talvolta frammenti contestuali diversi per lo stesso errore JSON.parse. Lo scanner di ToolAcre fornisce la propria ragione strutturale e posizione quando il parser nativo rifiuta il valore. Se lo scanner non è d'accordo con JSON.parse, lo strumento restituisce l'errore del motore anziché fabbricare una posizione. Questo ripiego è più sicuro che indicare con sicurezza un personaggio indovinato.
Cosa non copre: problemi semantici come tipi errati, campi mancanti o violazioni dello schema, che un validatore di sintassi non contrassegnerà mai
Un oggetto sintatticamente valido può comunque essere sbagliato per la tua applicazione: un campo obbligatorio mancante, un'età scritta come testo, due chiavi duplicate o un riferimento a un file inesistente non sono automaticamente invalidi JSON. RFC 8259 dice che i nomi dei membri dovrebbero essere univoci per l'interoperabilità, ma la semplice analisi non impone il tuo schema API. Convalida qui la sintassi e convalida i vincoli semantici nel programma che utilizza il documento.
Conclusione: leggi la posizione come "il primo token che la grammatica non ha potuto accettare" e come il formattatore e il validatore JSON riportano quella riga e colonna senza caricare il testo
Tratta la posizione riportata come “il primo segno che questa grammatica non ha potuto accettare”. Lavora a ritroso fino alla causa, risolvi un problema e riprova. Il formattatore e validatore JSON esegue questa operazione localmente senza caricare una configurazione incollata. Non incollare le credenziali di produzione reali in alcun sito Web pubblico se invece un editor offline può diagnosticare il file.