Quasi tutti gli errori JSON che incontrerai si riducono a una di nove cose. Il messaggio del parser raramente dice quale, perch la maggior parte segnala il token su cui si e bloccato piuttosto dell’errore che hai commesso, e non sono la stessa cosa. Ecco ogni errore, il messaggio che vedrai probabilmente, e la correzione che lo risolve.
Se vuoi provare, incolla uno di questi esempi nel validatore JSON. Identifica l’errore e contrassegna la riga.
1. Una virgola finale
{
"name": "ana",
"role": "admin",
}La virgola dopo l’ultima proprieta e legale in JavaScript e illegale in JSON. La maggior parte dei parser la segnala alla parentesi graffa di chiusura, una riga sotto la virgola reale, per questo le persone fissano la graffa senza vedere nulla di strano.
Elimina la virgola. Se ti capita costantemente perche modifichi file di configurazione a mano, lo strumento di riparazione JSON le rimuove e ti mostra ciascuna di quelle rimosse.
2. Apici singoli
{ 'name': 'ana' }JSON ha una sola sintassi per le stringhe e usa le doppie virgolette. Gli apici singoli sono un’abitudine di JavaScript. La correzione e meccanica, e vale la pena usare uno strumento piuttosto che farlo a mano se il documento e grande, perche un apice all’interno di una stringa deve essere escaped piuttosto che semplicemente sostituito.
3. Chiavi senza virgolette
{ name: "ana" }Le chiavi degli oggetti sono stringhe, e le stringhe hanno le virgolette. I letterali di oggetto in JavaScript permettono di omettere le virgolette, e di la viene sempre questo errore: qualcuno ha copiato un oggetto da un file sorgente e si aspettava che fosse JSON. Non lo e.
4. Commenti
{
// the account owner
"name": "ana"
}JSON non ammette commenti. Douglas Crockford li ha rimossi deliberatamente, perche
le persone li usavano per trasportare direttive di parsing. Sia // che /* */ sono
errori. Se i commenti sono importanti, tienili in un file sorgente e genera il JSON
da quello, oppure sposta la nota in un campo reale come "_comment".
5. NaN, Infinity e undefined
{ "score": NaN, "limit": Infinity }Nessuno di questi esiste in JSON. Non c’e alcuna sintassi per essi, e per questo
l’errore appare solitamente come una parola libera imprevista. Python scrive NaN e
Infinity quando esporti float senza cura, e JavaScript produce
undefined da una proprieta mancante.
Devi decidere in cosa dovrebbero trasformarsi, perche non c’e una risposta senza perdita.
null e la scelta piu comune, una stringa come "NaN" e l’altra. Lo strumento
di riparazione sceglie null ed elenca la modifica separatamente dalle correzioni di punteggiatura,
perche questo cambia i tuoi dati e non solo la loro formattazione.
6. Parole chiave con maiuscole/minuscole sbagliate
{ "active": True, "deleted": NULL }Le parole chiave di JSON sono in minuscolo: true, false, null. True e None sono
di Python, NULL e di SQL e C. Un parser che dice “unexpected token T” ti sta dicendo
la verita nel modo meno utile possibile.
7. Un a capo all’interno di una stringa
{ "note": "first line
second line" }Una stringa JSON non puo estendersi su piu righe. L’a capo deve essere scritto come \n
all’interno della stringa. Questo e comune quando qualcuno incolla testo multiriga in un
file di configurazione a mano, e l’errore risultante punta spesso alla riga successiva, non alla
stringa che e stata lasciata aperta.
8. Numeri che JSON non permette
{ "a": .5, "b": +1, "c": 007, "d": 1_000 }Quattro regole separate. Un numero richiede una cifra prima del punto decimale, quindi .5 e
0.5. Un piu iniziale non e permesso. Uno zero iniziale non e permesso, il che
rifiuta 007. I separatori di cifre sono una caratteristica del linguaggio, non di JSON.
9. Una parentesi non chiusa
{
"user": {
"name": "ana"
}Il parser raggiunge la fine del file e la segnala li, quindi il messaggio dice qualcosa sulla riga 200 di un documento di 200 righe mentre la graffa mancante si trova alla riga 2. Questo e l’errore per cui vale la pena avere un buono strumento: il validatore di questo sito segnala la posizione della parentesi che e stata aperta e mai chiusa, piuttosto che la fine dell’input.
I due errori che non sono errori di sintassi
Due documenti possono essere perfettamente validi e comunque sbagliati.
Una chiave duplicata viene parsata senza problemi. La specifica lo permette, e ogni parser che userai probabilmente conserva l’ultimo valore e scarta silenziosamente il precedente, cosi che i dati spariscono senza alcun errore da nessuna parte:
{ "region": "eu-west-1", "retries": 3, "region": "us-east-1" }Il validatore segnala i duplicati come avvisi con entrambi i numeri di riga, e chiama comunque il documento valido, perche e quello che la specifica dice.
Un intero lungo viene parsato senza problemi, e poi perde precisione nel momento in cui qualcosa lo legge come un double:
{ "id": 12345678901234567890 }Leggerlo con una libreria JSON tipica restituisce 1234567890123567000. Gli
strumenti qui lavorano sul flusso di token piuttosto che fare il parse in un valore JavaScript, cosi che
il numero sopravvive alla formattazione, alla minificazione e al confronto senza modifiche. E per questo
che lo strumento diff non chiamera due interi di venti cifre
uguali solo perche collassano sullo stesso valore in virgola mobile.
Come leggere correttamente un messaggio di errore
Due abitudini risparmiano la maggior parte del tempo che le persone dedicano a questo.
Prima, tratta la posizione segnalata come il punto in cui il parser ha rinunciato, non dove tu hai sbagliato. Una virgola mancante e segnalata al token successivo, una parentesi non chiusa alla fine del file, e una virgola finale alla graffa di chiusura.
Poi, controlla il carattere prima della posizione segnalata. Nella grande maggioranza dei casi l’errore reale e un token prima della lamentela.
Se preferisci non fare nessuna delle due, incolla il documento nel validatore e leggi il messaggio, che nomina la costruzione sbagliata piuttosto che citare il token che non e stato possibile parsare.