CDRN

Validar a sintaxe de um JSON

  • Painel
  • Documentação
  • API
verifica a sintaxe de uma cadeia JSON e indica a linha e a coluna do menor erro

À quoi sert un validateur JSON ?

Un validateur JSON a un rôle plus modeste, mais plus précis, qu'un formateur : il ne réécrit rien. Il prend une chaîne et répond à une question binaire : ce texte est-il du JSON conforme à la RFC 8259 ? Si oui, l'outil rend la main. Si non, il indique exactement la ligne, la colonne et un extrait du JSON autour du problème, pour aider le développeur à corriger immédiatement.

En pratique, c'est l'outil que l'on utilise dès qu'un parseur quelque part renvoie un message d'erreur cryptique du genre SyntaxError: Unexpected token } in JSON at position 217. Plutôt que de compter les caractères à la main dans un éditeur, on colle la chaîne complète, on lit la position et on voit l'extrait fautif.

Validation, formatage : deux opérations distinctes

On confond souvent les deux. Notre formateur JSON prend du JSON valide et le réécrit avec une indentation lisible. Le validateur, lui, se contente d'un verdict syntaxique. Il n'effectue pas de validation sémantique : il ne sait pas si la valeur d'un champ email ressemble à un email, ni si la structure correspond à un schéma JSON Schema. Pour cela, on utilise des outils dédiés (ajv en Node, justinrainbow/json-schema en PHP).

L'enchaînement classique en debug est : valider d'abord (l'outil indique l'erreur de syntaxe), formater ensuite (le payload désormais valide devient lisible), comparer enfin avec un autre payload de référence via notre comparateur JSON.

Les erreurs JSON les plus fréquentes

  • Virgule de fin (trailing comma) : {"a": 1, "b": 2,}. Tolérée par JavaScript, ECMAScript et JSON5 ; refusée par JSON pur. C'est l'erreur n°1 quand on copie-colle depuis un éditeur de code.
  • Apostrophes au lieu de guillemets doubles : {'a': 1} est invalide. JSON n'accepte que les guillemets doubles, autour des clés comme des valeurs chaînes.
  • Clés non quotées : {a: 1}, syntaxe JavaScript valide mais JSON invalide.
  • Caractères de contrôle non échappés dans une chaîne : un saut de ligne brut, une tabulation. JSON exige \n, \t, \r.
  • Commentaires : // commentaire ou /* */. Acceptés en JSONC (config VS Code) ou JSON5, refusés en JSON pur.
  • Encodage incorrect : un BOM UTF-8 en début de fichier, du contenu en latin-1 mal converti. Le validateur retourne souvent un message générique pour ces cas.
  • Structure non terminée : un { ou [ sans fermeture, fréquent quand on tronque un payload au copier-coller.

Comment le validateur localise l'erreur

L'outil utilise json_decode() de PHP avec le drapeau JSON_THROW_ON_ERROR. PHP renvoie un message qui contient une position en octets (position 217), que nous convertissons en couple ligne/colonne en comptant les sauts de ligne avant l'offset. Un extrait d'environ 80 caractères est ensuite découpé autour de la position pour donner du contexte. C'est généralement suffisant pour repérer l'erreur : un guillemet mal placé, une virgule en trop, un crochet manquant.

Attention : la position rapportée par PHP n'est pas toujours exactement le caractère fautif. Elle est souvent après l'erreur, au moment où le parseur a renoncé. Si l'extrait montre "name": "Alice", }, l'erreur réelle est la virgule, pas l'accolade.

Cas d'usage typiques

  • Configuration corrompue : composer.json, package.json, tsconfig.json qui empêchent un build de démarrer. On colle, on voit la ligne, on corrige.
  • Réponse d'API tronquée : un proxy a coupé le payload. La structure n'est pas terminée, le validateur le signale.
  • Payload de webhook : un service tiers envoie du JSON mal formé. Le validateur permet de constater le problème côté émetteur sans plonger dans le code applicatif.
  • JSON construit par concaténation : pratique à éviter mais courante, surtout en bash ou en SQL. Le validateur révèle les guillemets doubles non échappés.

Limites de l'outil

Le validateur n'effectue pas de validation contre un schéma. Il ne dit pas qu'il manque le champ email, que la valeur n'est pas un entier ou que le tableau attendu n'a pas la bonne longueur. Pour ces vérifications structurelles, on utilise JSON Schema. Le validateur ne corrige pas non plus le JSON : il ne tente pas d'ajouter une accolade manquante, ni de retirer une virgule en trop. C'est un choix : la correction automatique masque trop souvent des erreurs réelles.

Questions fréquentes

Quelle est la différence avec un linter ?

Un linter va plus loin : il vérifie aussi des règles de style (alphabétique, conventions de nommage), détecte les valeurs en double, suggère des améliorations. Le validateur reste sur la conformité syntaxique.

Mon JSON est valide, mais mon application le rejette ?

Vérifiez l'encodage (UTF-8 sans BOM), la taille limite côté serveur, les types attendus. Un JSON syntaxiquement correct peut quand même ne pas correspondre au schéma applicatif.

Le validateur conserve-t-il mon JSON ?

Non. Le traitement est synchrone côté serveur, sans persistance. Pour des données très sensibles, préférez tout de même une validation locale via jq ou un script PHP.

Exemplo de pedido

curl -X POST https://cdrn.fr/api/v1/tools/json-validator/execute \
  -H "Content-Type: application/json" \
  -d '{"input":"..."}'

Esquema de entrada

Campo Tipo Obrigatório Predefinição
input text ✓ –

Pontos de acesso

  • GET https://cdrn.fr/api/v1/tools - lista todas as ferramentas disponíveis
  • GET https://cdrn.fr/api/v1/tools/json-validator - obtém o esquema desta ferramenta
  • POST https://cdrn.fr/api/v1/tools/json-validator/execute - executa esta ferramenta com um payload JSON