Comment formater et valider du JSON

Pour formater du JSON, collez-le dans un formateur qui ajoute indentation et sauts de ligne afin de rendre la structure facile à lire ; pour le valider, passez-le dans un analyseur qui vérifie la syntaxe et pointe l’endroit exact où ça casse. Le formatage (aussi appelé embellissement ou mise en forme lisible) et la validation vont généralement de pair : un bon outil réindente le JSON valide et, quand l’entrée est cassée, vous dit précisément ce qui ne va pas. Voici ce que fait réellement chaque action, quand formater plutôt que minifier, et comment lire et corriger les erreurs renvoyées par un analyseur.

Formater, minifier, valider : trois tâches distinctes

On emploie ces trois mots de façon interchangeable, mais ils font des choses bien différentes à vos données.

• Le formatage (embellissement) ajoute indentation et sauts de ligne pour que les objets et tableaux imbriqués s’alignent visuellement. Il ne modifie pas les données — seulement les espaces — ce qui rend bien plus facile la lecture à l’œil d’un fichier de configuration ou d’une réponse d’API.
• La minification fait l’inverse : elle supprime chaque espace, tabulation et retour à la ligne non essentiels pour que la charge utile soit aussi petite que possible. Les données sont identiques, simplement compactées sur une seule ligne, en pratique.
• La validation vérifie si le texte est, de fait, du JSON valide. Un validateur analyse l’entrée et soit confirme qu’elle est bien formée, soit signale la première erreur de syntaxe rencontrée.

En pratique, vous formatez pendant que vous lisez et déboguez, et vous minifiez juste avant d’envoyer les données sur le réseau ou de les stocker. La validation sous-tend les deux — vous ne pouvez pas formater ni minifier de façon fiable un texte qui n’est pas du JSON valide au départ.

Quand formater plutôt que minifier

Optez pour le formatage chaque fois qu’un humain a besoin de regarder les données :

• Inspecter une réponse d’API pendant le débogage.
• Examiner ou modifier un package.json, un tsconfig.json ou tout autre fichier de configuration.
• Comparer deux fichiers JSON dans un système de gestion de versions, où une indentation cohérente garde le diff réduit et lisible.
• Coller depuis un journal un bloc dense d’une seule ligne et vouloir réellement en comprendre la structure.

Optez pour la minification quand ce sont les octets qui comptent et qu’aucun humain ne lit :

• Faire transiter du JSON dans le corps d’une requête ou d’une réponse HTTP, où des charges utiles plus petites accélèrent les transferts.
• Intégrer une configuration dans une variable d’environnement ou une URL.
• Stocker de nombreux enregistrements, où les espaces s’accumulent sur des milliers de lignes.

Une bonne habitude : gardez vos fichiers sources formatés pour la lisibilité, et laissez votre build ou votre serveur minifier à la sortie. Vous profitez du meilleur des deux mondes — lisible dans le dépôt, compact sur le réseau.

Les erreurs JSON les plus courantes (et comment les corriger)

Le JSON est délibérément strict, et c’est ce qui le rend portable d’un langage à l’autre. Cette même rigueur fait trébucher, surtout quiconque a l’habitude d’écrire des littéraux d’objet JavaScript. Voici les erreurs qui reviennent encore et encore :

• Virgules de fin. Une virgule après le dernier élément d’un objet ou d’un tableau — {"a": 1,} — est invalide. Supprimez-la. C’est l’erreur la plus courante de toutes, car la plupart des langages de programmation l’autorisent.
• Apostrophes simples au lieu de guillemets doubles. Le JSON exige des guillemets doubles pour les clés comme pour les chaînes de caractères. {'name': 'Ada'} doit devenir {"name": "Ada"}.
• Clés non entre guillemets. Les clés sont toujours des chaînes entre guillemets. {name: "Ada"} est un objet JavaScript, pas du JSON ; il faut écrire {"name": "Ada"}.
• Virgules manquantes. Chaque élément, sauf le dernier, a besoin d’une virgule qui le sépare du suivant. Deux valeurs à la suite, sans rien entre elles, échoueront à l’analyse.
• Commentaires. Le JSON n’a pas de syntaxe de commentaire. Les lignes commençant par // ou encadrées par /* */ ne sont pas autorisées et doivent être retirées avant que le texte ne soit validé.

Quelques autres points à surveiller : les nombres ne peuvent pas comporter de zéros en tête ni de point décimal final, les chaînes doivent échapper les caractères spéciaux comme \n et \", et les seuls littéraux autorisés en dehors des nombres et des chaînes sont true, false et null (en minuscules, sans guillemets).

Comment lire une erreur d’analyse

Quand la validation échoue, l’analyseur indique généralement une position — une ligne et une colonne, ou un décalage en nombre de caractères. Lisez cet emplacement au pied de la lettre : l’erreur est signalée au premier caractère que l’analyseur n’a pas pu interpréter, ce qui se trouve souvent juste après la véritable faute. Par exemple, une virgule manquante est fréquemment signalée au début de la clé suivante, et non à l’endroit où la virgule aurait dû se trouver. Allez à l’emplacement indiqué, puis regardez le jeton qui le précède immédiatement. Une fois la première erreur corrigée, revalidez, car un analyseur s’arrête au premier problème et il peut y en avoir d’autres derrière.

Faites-le en toute confidentialité dans votre navigateur

Beaucoup d’outils JSON en ligne envoient ce que vous collez vers un serveur distant pour le traiter. Or, avec le JSON, ce sont souvent les pires données à envoyer, car c’est précisément là que tendent à se loger les clés d’API, les jetons d’accès, les noms d’hôtes internes, les fiches clients et autres secrets.

Le formateur JSON d’Andev évite cela entièrement. Il utilise les fonctions natives JSON.parse et JSON.stringify du navigateur, ce qui signifie :

• Vos données ne sont jamais envoyées. Tout s’exécute en local sur votre appareil ; rien n’est expédié nulle part.
• Il fait apparaître l’erreur d’analyse exacte. Quand l’entrée est invalide, vous voyez le message et l’emplacement précis pour aller droit au problème.
• Vous choisissez la taille d’indentation. Formatez avec deux espaces, quatre espaces ou des tabulations pour coller au style de votre projet — ou minifiez sur une seule ligne.
• C’est instantané. Aucun aller-retour d’envoi et d’attente ; le résultat apparaît aussi vite que vous collez.

Parce qu’il s’appuie sur le même moteur JSON que vos applications utilisent déjà, la validation qu’il signale correspond au comportement réel de votre code lorsqu’il analysera la même chaîne. Cela le rend sûr à utiliser avec des configurations et des charges utiles d’API sensibles, et fiable comme rapide vérification de bon sens avant de mettre en production.

Pour des tâches voisines, la même approche locale, sans envoi, alimente l’encodeur et décodeur Base64 d’Andev ainsi que son encodeur et décodeur d’URL — tous deux pratiques quand du JSON est intégré dans une URI de données, un jeton ou une chaîne de requête.

À retenir

• Le formatage ajoute de l’indentation pour la lisibilité ; la minification supprime les espaces pour des charges utiles plus petites ; la validation vérifie la syntaxe. Ce sont trois tâches distinctes.
• Formatez pour les humains, minifiez pour le réseau — gardez les fichiers sources lisibles et laissez votre build compacter la sortie.
• La plupart des erreurs sont des pièges de rigueur : virgules de fin, apostrophes simples, clés non entre guillemets, virgules manquantes et commentaires sont tous du JSON invalide.
• Lisez les erreurs d’analyse à la position indiquée, puis examinez le jeton juste avant ; corrigez une erreur et revalidez, puisque l’analyseur s’arrête à la première.
• Gardez tout en local. Un formateur natif du navigateur n’envoie jamais vos données, ce qui compte d’autant plus pour les secrets qui se nichent dans les JSON de configuration et d’API.

Besoin de nettoyer ou de vérifier du JSON tout de suite ? Ouvrez le formateur JSON gratuit et confidentiel — sans envoi, sans inscription — ou parcourez l’ensemble des outils pour développeurs dans le navigateur.