Formateur JSON

Le JSON est un sous-ensemble strict de ce qu'autorisent les littéraux d'objet JavaScript, et l'écart entre les deux est exactement d'où viennent la plupart des erreurs « JSON invalide ». Une virgule finale après le dernier élément d'un tableau ou objet est légale en JavaScript moderne mais une erreur de syntaxe en JSON. Les chaînes à guillemets simples fonctionnent bien en JavaScript et sont directement rejetées par JSON, qui exige des guillemets doubles. Les clés d'objet sans guillemets — écrire `{name: "value"}` plutôt que `{"name": "value"}` — sont un raccourci JavaScript valide et invalide en JSON. Aucun de ces cas n'est obscur ; ce sont exactement les habitudes acquises en écrivant du JavaScript qui produisent silencieusement un document ressemblant à du JSON sans en être.

Les commentaires sont l'autre source fréquente de confusion, car pas mal de formats de fichiers de configuration ressemblant à du JSON — et même certains formats dérivés du JSON utilisés délibérément — autorisent des commentaires `//` ou `/* */`, tandis que la spécification JSON elle-même n'a absolument aucune syntaxe de commentaire. Coller un fichier de configuration « JSON » contenant réellement des commentaires dans un analyseur strict échoue immédiatement, et la solution est soit de supprimer les commentaires, soit de reconnaître que le fichier n'a jamais utilisé du JSON standard en premier lieu.

Un analyseur qui rapporte seulement « JSON invalide » sans dire où vous laisse scruter tout le document à l'œil nu à la recherche d'une seule virgule manquante ou d'un guillemet non échappé, ce qui devient réellement fastidieux après quelques dizaines de lignes. Rapporter la ligne et colonne exactes du premier problème transforme cette recherche en une localisation directe — l'erreur décrit un caractère précis, pas un échec vague général — ce qui fait la différence entre corriger une grosse réponse d'API en quelques secondes plutôt qu'en minutes de balayage manuel.

Cela vaut la peine de noter que l'erreur pointe toujours le *premier* problème que rencontre l'analyseur, pas nécessairement chaque problème du document : un document avec deux erreurs de syntaxe signalera la première, et la corriger peut révéler la seconde seulement à la tentative suivante, un analyseur ayant déjà échoué à comprendre la structure ne pouvant pas continuer à chercher de façon fiable d'autres problèmes au-delà du premier point où il s'est perdu.

Le JSON embelli, avec indentation et sauts de ligne cohérents, existe pour la personne qui le lit — déboguer une réponse d'API, relire un fichier de configuration, comprendre une structure de données d'un coup d'œil. Rien de cette structure ne compte pour un programme qui analyse le même JSON, c'est pourquoi la sortie minifiée supprime chaque caractère existant purement pour la lisibilité humaine : indentation, sauts de ligne, et tout espace blanc entre tokens qui n'est pas nécessaire pour les séparer. Les données représentées sont identiques dans les deux formes ; seul le nombre d'octets nécessaires pour les transmettre ou les stocker diffère, souvent substantiellement pour des structures profondément imbriquées.

La règle pratique est simple : formatez le JSON pendant que vous travaillez avec — lecture, débogage, édition à la main — et minifiez-le avant qu'il n'aille quelque part qui paie pour sa taille, comme le corps d'une requête HTTP, un paramètre de requête d'URL, ou une valeur stockée dans une variable d'environnement à longueur limitée.