Comment ça marche : Formater du JSON
L'analyseur est écrit ici, à la main, et pas emprunté au navigateur : parce que le message d'erreur du navigateur n'est normalisé par aucune spécification, et qu'il diffère d'un navigateur à l'autre. Celui-ci dit la ligne, la colonne, et ce qui était attendu, partout pareil.
Un fichier JSON refusé par un programme, et un message d'erreur qui ne dit rien : c'est le quotidien de qui touche à une configuration ou à une exportation de données. Le premier travail d'un validateur est donc de dire OÙ, précisément, et ce qui était attendu à cet endroit.
C'est pour cette raison que l'analyseur est écrit ici plutôt qu'emprunté au navigateur. La norme du langage impose le TYPE de l'exception que le navigateur doit lever, pas son texte : Firefox donne la ligne et la colonne, Chrome donne une position en octets, Safari ne donne ni l'une ni l'autre. Un outil qui recopie ce message rend donc un diagnostic différent selon le navigateur de la personne. Le nôtre compte lui-même ses lignes et ses colonnes.
Et il voit trois choses que la fonction du navigateur avale en silence. Les CLÉS EN DOUBLE : la norme dit qu'elles « devraient » être uniques et que le comportement d'un logiciel qui en reçoit est imprévisible ; en pratique, la dernière écrase la première, et une donnée disparaît sans un mot. Les demi-caractères Unicode restés seuls, qui ne codent rien et cassent la moitié des lecteurs en aval. Et la marque d'ordre d'octets en tête de fichier, que la norme interdit d'ajouter.
Comment ça marche
- Collez votre JSON. Il ne quitte pas votre appareil, ce qui compte pour une exportation de données ou une configuration qui porte des identifiants.
- Choisissez l'indentation, et le tri des clés si vous voulez comparer deux fichiers ensuite.
- Si le JSON est invalide, lisez la ligne, la colonne et le signe attendu. S'il est valide, lisez le tableau des alertes : c'est là que se cachent les clés en double.
Formats acceptés
Du JSON, tel que la norme le définit : pas de commentaires, pas de virgule en trop avant une accolade fermante, pas de clé sans guillemets. Ces trois écarts sont fréquents et l'outil les refuse en les nommant, parce qu'un programme les refusera aussi.
Du texte au format JSON
Jusqu'à 400 000 signes. Le résultat se télécharge en .json ou se copie en un clic.
Ses limites
L'outil applique la norme, sans les tolérances de certains programmes
Les commentaires, les virgules en trop et les clés sans guillemets sont acceptés par plusieurs outils de développement, mais ils ne sont PAS du JSON : la norme ne les prévoit pas, et le programme qui refuse votre fichier a raison. Nous ne les acceptons pas non plus, parce qu'un validateur permissif vous laisserait croire que votre fichier passera ailleurs.
Les clés en double sont SIGNALÉES, jamais corrigées à votre place
La norme écrit que les noms d'un objet devraient être uniques, et que si ce n'est pas le cas le comportement du logiciel qui reçoit ces données est imprévisible. En pratique, presque toutes les implémentations gardent la DERNIÈRE valeur : une donnée disparaît sans un mot. L'outil les nomme avec leur chemin et leur ligne, mais le fichier mis en forme reflète le même choix que tout le monde, la dernière valeur, parce que le contraire serait une surprise.
Un très grand nombre peut perdre des chiffres, et ce n'est pas notre fait
Le langage du navigateur ne sait représenter exactement que les entiers jusqu'à environ neuf mille milliards de milliards. Un identifiant plus grand écrit dans un JSON perd donc des chiffres dès qu'il est lu, dans n'importe quel outil qui passe par ce langage. C'est pour cette raison que les interfaces sérieuses transportent les grands identifiants sous forme de chaîne entre guillemets, et si vous en voyez un nu dans un fichier, c'est déjà un problème avant nous.
L'ordre des clés est conservé, sauf celles qui ressemblent à des nombres
Un objet JavaScript place TOUJOURS les clés qui s'écrivent comme des entiers en premier, dans l'ordre croissant, quelle que soit leur position d'origine. C'est une règle du langage, pas un choix de notre part, et aucun outil qui passe par ce langage n'y échappe. Sur un objet dont les clés sont « 10 », « 2 », « 1 », l'ordre d'origine est donc perdu. Le signaler valait mieux que le taire.
Questions sur cet outil
Mes données sont-elles envoyées quelque part ?
Non, et cela compte ici plus qu'ailleurs : une configuration au format JSON porte souvent des identifiants, des adresses internes, parfois des clés d'accès. Vérifiez en trente secondes : ouvrez l'inspecteur avec la touche F12, onglet « Réseau », videz la liste, puis collez votre JSON et validez-le. Aucune ligne n'apparaît. Coupez votre connexion et refaites-le.
Pourquoi mon JSON avec des commentaires est-il refusé ?
Parce que ce n'est pas du JSON. La norme ne prévoit aucun commentaire, et son auteur a expliqué les avoir retirés volontairement. Plusieurs outils de développement les acceptent par commodité, ce qui entretient la confusion : votre fichier passe chez vous et échoue en production. Nous refusons pour la même raison qu'un validateur doit refuser : vous dire la vérité sur ce que votre fichier est.
À quoi sert le tri des clés ?
À comparer. Deux exportations des mêmes données par deux programmes différents sortent souvent dans un ordre de clés différent : une comparaison brute rend alors des centaines de fausses différences. Triez les deux, puis collez-les dans l'outil « Comparer deux textes » du même coin : il ne restera que les vraies différences. C'est le tour de main le plus utile de cette page.
Vous parlez de clés en double : c'est vraiment autorisé ?
La norme écrit que les noms d'un objet « devraient » être uniques, et que si ce n'est pas le cas, le comportement du logiciel qui reçoit les données devient imprévisible. Ce n'est donc ni interdit ni sûr. En pratique, presque toutes les implémentations gardent la dernière valeur et jettent la première sans un mot : si vous avez deux fois la clé « prix » dans le même objet, un des deux prix n'existe déjà plus. C'est exactement le genre de problème qu'on cherche pendant deux heures, et c'est pour cela que nous le signalons.
Mon identifiant de dix-neuf chiffres est modifié après la mise en forme.
Oui, et ce n'est pas notre fait : c'est une limite du langage employé par tous les navigateurs, qui ne représente exactement les entiers que jusqu'à environ neuf mille milliards de milliards. Au-delà, les derniers chiffres changent dès la lecture, dans n'importe quel outil qui passe par ce langage. C'est pour cette raison que les interfaces sérieuses transportent les grands identifiants entre guillemets, comme des chaînes. Si le vôtre est nu dans le fichier, le problème existait avant vous.
L'analyseur est écrit ici, à la main, et pas emprunté au navigateur : parce que le message d'erreur du navigateur n'est normalisé par aucune spécification, et qu'il diffère d'un navigateur à l'autre. Celui-ci dit la ligne, la colonne, et ce qui était attendu, partout pareil.
VérifierLa preuve, pas à pasLa vérification par l'inspecteur réseau, expliquée geste par geste, captures à l'appui.
Le coinLe coin textes et donnéesCompter, comparer, mettre en forme, nettoyer. Les petits gestes qui font perdre une heure quand on ne les a pas sous la main.