Vérifier votre JSON

Ce que le JSON interdit vraiment

La grammaire du JSON est volontairement minuscule, et presque tous les échecs de validation viennent d'une poignée d'habitudes empruntées à JavaScript que le JSON n'a jamais adoptées. Une virgule finale après le dernier élément. Des guillemets simples au lieu de doubles. Des clés sans guillemets. Des commentaires — le JSON n'en a pas, et n'en a jamais eu. NaN et Infinity, qui sont des nombres JavaScript valides mais pas du JSON valide. Et une marque d'ordre des octets (BOM) en tête de fichier, invisible dans tous les éditeurs, que certains outils Windows ajoutent en enregistrant en UTF-8 et qui fait échouer un document parfaitement correct dès son premier caractère.

Deux choses sont autorisées et vous causeront pourtant des ennuis, ce qui explique pourquoi « valide » ne veut pas dire « correct ». Les clés en double ne sont pas interdites par la spécification — et chaque parseur les résout à sa manière, la plupart gardant la dernière : un document avec une clé répétée est validé ici et signifie des choses différentes selon le langage. Et les nombres n'ont aucune limite de précision définie en JSON, alors que la plupart des parseurs les lisent en virgule flottante : un entier au-delà d'environ neuf millions de milliards est arrondi sans prévenir, ce qui explique pourquoi les grands identifiants sont si souvent transmis sous forme de chaînes.

Vous obtenez la ligne, la colonne et le caractère exacts où l'analyse s'est arrêtée, ce qui est généralement plus utile que le message lui-même. Un parseur signale l'endroit où le document a cessé d'avoir un sens, pas celui où l'erreur a été commise — une accolade fermante manquante est signalée à la fin du fichier, et une virgule manquante au jeton qui suit. Regarder juste avant la position indiquée est le réflexe qui fait gagner le plus de temps.

Bien formé ne veut pas dire correct, et la distinction compte. L'outil confirme que la syntaxe s'analyse. Que le document contienne les champs exigés par votre API, qu'une valeur soit dans la bonne plage, qu'une date soit vraiment une date — rien de tout cela n'est une question de JSON. C'est la validation par schéma, elle nécessite un schéma, et un document peut être irréprochable ici et refusé aussitôt par le service auquel vous l'envoyez.

Si vous cherchez autre chose

Pour vérifier des documents par rapport à un schéma plutôt qu'à une grammaire, JSON Schema est la norme et ajv en est l'implémentation la plus rapide — il vous dira qu'un champ obligatoire manque ou qu'une valeur est hors plage, ce qui est généralement la vraie question que vous vous posez. check-jsonschema effectue les mêmes vérifications en ligne de commande et en CI.

Pour tout ce qui se fait en ligne de commande, jq est l'outil à avoir : jq empty file.json valide et n'affiche rien en cas de succès, exactement ce qu'il faut pour un script, et jq . formate. Pour les fichiers trop gros pour tenir en mémoire, jq --stream et ijson en Python analysent de façon incrémentale, ce qu'aucune page qui charge tout le document ne peut faire.