Presque toutes les erreurs JSON que vous rencontrerez se ramènent à neuf choses. Le message du parser indique rarement laquelle, car la plupart signalent le token sur lequel ils se sont bloqués plutôt que l’erreur que vous avez commise, et ce n’est pas la même chose. Voici chaque erreur, le message que vous verrez probablement, et la correction qui la résout.
Si vous voulez tester, collez n’importe lequel de ces exemples dans le validateur JSON. Il identifie l’erreur et indique la ligne.
1. Une virgule finale
{
"name": "ana",
"role": "admin",
}La virgule après la dernière propriété est légale en JavaScript et illégale en JSON. La plupart des parsers la signalent à l’accolade fermante, une ligne en dessous de la virgule réelle, c’est pourquoi les gens fixent l’accolade sans rien voir de travers.
Supprimez la virgule. Si vous rencontrez constamment ce problème parce que vous éditez des fichiers de configuration à la main, l’outil de réparation JSON les supprime et vous montre chacune d’entre elles.
2. Guillemets simples
{ 'name': 'ana' }JSON n’a qu’une seule syntaxe pour les chaînes et elle utilise des guillemets doubles. Les guillemets simples sont une habitude JavaScript. La correction est mécanique, et il vaut mieux utiliser un outil plutôt que le faire à la main si le document est grand, car un guillemet à l’intérieur d’une chaîne doit être échappé plutôt que simplement remplacé.
3. Clés sans guillemets
{ name: "ana" }Les clés d’objet sont des chaînes, et les chaînes sont guillemetées. Les littéraux d’objet JavaScript vous permettent d’omettre les guillemets, et c’est toujours de là que vient cette erreur : quelqu’un a copié un objet depuis un fichier source et s’attendait à ce que ce soit du JSON. Ce n’est pas le cas.
4. Commentaires
{
// the account owner
"name": "ana"
}JSON n’autorise pas les commentaires. Douglas Crockford les a supprimés délibérément, car
les gens les utilisaient pour transporter des directives de parsing. // et /* */ sont
tous deux des erreurs. Si les commentaires comptent, gardez-les dans un fichier source et générez le JSON
à partir de celui-ci, ou déplacez la note dans un vrai champ comme "_comment".
5. NaN, Infinity et undefined
{ "score": NaN, "limit": Infinity }Aucun de ceux-ci n’existe en JSON. Il n’y a pas de syntaxe pour eux du tout, c’est pourquoi
l’erreur apparaît généralement comme un mot brut inattendu. Python écrit NaN et
Infinity lorsque vous exportez des flottants sans soin, et JavaScript produit
undefined à partir d’une propriété manquante.
Vous devez décider ce qu’ils doivent devenir, car il n’y a pas de réponse sans perte.
null est le choix habituel, une chaîne comme "NaN" est l’autre. L’outil
de réparation choisit null et énumère le séparément des corrections de ponctuation,
car celui-ci modifie vos données plutôt que leur formatage.
6. Mots-clés avec la mauvaise casse
{ "active": True, "deleted": NULL }Les mots-clés JSON sont en minuscules : true, false, null. True et None sont
Python, NULL est SQL et C. Un parser qui dit “unexpected token T” vous dit
la vérité de la manière la moins utile qui soit.
7. Un saut de ligne dans une chaîne
{ "note": "first line
second line" }Une chaîne JSON ne peut pas s’étendre sur plusieurs lignes. Le saut de ligne doit être écrit sous forme de \n
dans la chaîne. Ceci est courant lorsque quelqu’un colle du texte multiligne dans un
fichier de configuration à la main, et l’erreur résultante pointe souvent vers la ligne suivante, pas vers
la chaîne qui a été laissée ouverte.
8. Nombres que JSON n’autorise pas
{ "a": .5, "b": +1, "c": 007, "d": 1_000 }Quatre règles séparées. Un nombre nécessite un chiffre avant le point décimal, donc .5 est
0.5. Un plus en début n’est pas autorisé. Un zéro en début n’est pas autorisé, ce qui
rejette 007. Les séparateurs de chiffres sont une caractéristique du langage, pas de JSON.
9. Un crochet non fermé
{
"user": {
"name": "ana"
}Le parser atteint la fin du fichier et la signale là, donc le message dit quelque chose à propos de la ligne 200 d’un document de 200 lignes alors que l’accolade manquante est à la ligne 2. C’est l’erreur pour laquelle un bon outil est utile : le validateur de ce site signale la position du crochet qui a été ouvert et jamais fermé, plutôt que la fin de l’entrée.
Les deux erreurs qui ne sont pas des erreurs de syntaxe
Deux documents peuvent être parfaitement valides et quand même faux.
Une clé dupliquée se parse sans problème. La spécification l’autorise, et chaque parser que vous êtes susceptible d’utiliser conserve la dernière valeur et supprime silencieusement la précédente, de sorte que les disparaissent sans aucune erreur nulle part :
{ "region": "eu-west-1", "retries": 3, "region": "us-east-1" }Le validateur signale les doublons comme des avertissements avec les deux numéros de ligne, et considère toujours le document comme valide, car c’est ce que la spécification dit.
Un entier long se parse également sans problème, puis perd sa précision dès que quelque chose le lit en tant que double :
{ "id": 12345678901234567890 }Le lire avec une bibliothèque JSON typique donne 1234567890123567000. Les
outils ici travaillent sur le flux de tokens plutôt que de parser dans une valeur JavaScript, de sorte que
le nombre survit au formatage, à la minification et à la comparaison sans changement. C’est
aussi pourquoi l’outil diff ne qualifiera pas deux entiers de vingt chiffres
d’égaux simplement parce qu’ils s’effondrent sur la même valeur flottante.
Lire correctement un message d’erreur
Deux habitudes épargnent la plupart du temps que les gens y consacrent.
D’abord, traitez la position signalée comme l’endroit où le parser a abandonné, pas où vous avez fait erreur. Une virgule manquante est signalée au token suivant, un crochet non fermé à la fin du fichier, et une virgule finale à l’accolade fermante.
Ensuite, vérifiez le caractère avant la position signalée. Dans la grande majorité des cas, l’erreur réelle est un token plus tôt que la plainte.
Si vous préférez ne rien faire de tout cela, collez le document dans le validateur et lisez le message, qui nomme la construction erronée plutôt que de citer le token qui n’a pas pu être parsé.