Analyser du JSON
L’inspecteur JSON vérifie la syntaxe RFC 8259 dans votre navigateur et indique les comptes par type, la profondeur et les correspondances entre langages. Il montre aussi quels tokens numériques originaux changeraient en devenant des Number JavaScript. L’inspection laisse le texte source inchangé ; les convertisseurs de valeurs refusent ces conversions dangereuses.
Collez un document JSON ou cliquez sur « Charger un exemple » pour examiner sa structure.
Comment fonctionne Analyser du JSON ?
« Est-ce que ça se parse ? » est la question à laquelle répond le validateur. Cet outil répond à la suivante, généralement la plus intéressante : en quoi a-t-il été analysé ? Un document peut être parfaitement valide et ne quand même pas être ce à quoi votre code s’attend, et cet écart se voit rarement à la lecture.
Le parseur est écrit sur mesure plutôt que d’appeler JSON.parse. Une pile de travail explicite et itérative permet d’inspecter les documents profondément imbriqués sans débordement de la pile d’appels. Le contenu après la valeur racine est refusé. Chaque clé est affectée comme propriété propre avec une protection : __proto__ reste une clé normale au lieu de modifier le prototype de l’objet.
L’analyse parcourt ensuite la valeur obtenue et compte ce qui s’y trouve : combien d’objets, de tableaux, de chaînes, de nombres, de booléens et de null, jusqu’où va l’imbrication, et combien de clés distinctes apparaissent. Cela suffit souvent à lui seul à repérer le problème — un tableau qui devait contenir des objets et ne contient que des chaînes, une structure trois niveaux plus profonde que ce que le schéma autorise, un document qui est 90% de null parce qu’une jointure en amont a échoué.
JSON possède un seul type numérique. JSON.parse de JavaScript le convertit en double IEEE-754, qui représente tous les entiers exactement seulement jusqu’à 2^53−1. Par exemple, 9007199254740993 devient 9007199254740992 sans erreur de syntaxe native. Cet inspecteur vérifie les tokens numériques originaux, décimaux et exposants compris, et signale toute valeur décimale modifiée comme un risque de conversion. Il compte la structure sans exporter de valeurs arrondies. Le formateur JSON et le minificateur JSON conservent les tokens originaux ; les convertisseurs de valeurs refusent ces nombres dangereux.
La même table montre le reste de la correspondance, car les hypothèses varient selon le langage. Go vous donne float64 pour chaque nombre, sauf si vous décodez vers une struct typée. Python distingue int de float et conserve donc exactement les grands entiers. Java et C# recourent à BigDecimal ou decimal quand ils sont configurés pour.
Document
{ "id": 9007199254740993, "price": 0.1 }Structure et risque numérique
3 values · depth 1 · 2 distinct keys number 2 → number (IEEE-754 double) JavaScript Number conversion risk (source unchanged): 9007199254740993 → 9007199254740992
Document → Structure et risque numérique
Document
{
"id": 42,
"name": "Ada"
"active": true
}Structure et risque numérique
Missing comma between object key-value pairs. Line 4, column 3 "active": true ^
Quelles options et quels cas limites Analyser du JSON prend en charge ?
| Paramètre | Type | Valeur par défaut | Comportement et cas limites |
|---|---|---|---|
| Grammaire | RFC 8259 | strict | Pas de commentaires, virgules finales, apostrophes simples, clés sans guillemets, NaN ou Infinity. Ce sont des règles de syntaxe JSON ; une API peut aussi imposer son schéma et ses propres limites de taille ou de nombres. JSON5 et JSONC sont refusés. |
| Contenu en trop | rejeté | — | RFC 8259 §2 définit un document comme exactement une valeur. Deux objets concaténés sont un symptôme courant d’une ligne de journal qui a été mal scindée, et sont signalés plutôt que tronqués silencieusement au premier. |
| Précision des nombres | IEEE-754 | signalé | Les tokens numériques originaux sont comparés à leur aller-retour décimal en Number JavaScript. Les entiers et décimaux modifiés, dépassements et valeurs ramenées à zéro sont signalés. Le texte source reste inchangé et aucun document arrondi n’est exporté. |
| Clés dupliquées | la dernière gagne | — | RFC 8259 laisse cela non défini ; presque chaque analyseur conserve la dernière occurrence, et celui-ci correspond à cela. Bon à savoir, car c’est une surface d’attaque réelle lorsque deux systèmes dans une chaîne ne sont pas d’accord. |
| __proto__ | propriété propre | — | Assigné via defineProperty, il devient une clé normale plutôt que de réorienter le prototype. Correspond à JSON.parse, et c’est la garde que la plupart des analyseurs manuels manquent. |
| Profondeur d’imbrication | itérative | aucune limite | L’analyseur utilise une pile explicite, donc la profondeur est limitée par la mémoire plutôt que par la pile d’appels. Un document de 20 000 niveaux est couvert par un test. |
| Unicode | UTF-8 | — | Les échappements \uXXXX sont décodés, et les paires de substitution sont recombinaisonnées afin que les caractères astraux survivent. Un marqueur d’ordre d’octet avant la racine est signalé plutôt que traité comme du contenu. |
| Taille d’entrée | bytes | 8 MB | Plafond du thread principal. Au-delà, l’analyse est refusée plutôt que tentée. Aucun fichier n’est envoyé, quelle que soit la taille. |
Questions fréquentes
En quoi est-ce différent du Validateur JSON ?
Le validateur se concentre sur les erreurs de syntaxe JSON et leur réparation. Cet inspecteur indique aussi les comptes par type, la profondeur, les clés distinctes, les correspondances entre langages et les risques de conversion numérique. Un JSON valide peut contenir des nombres modifiés lors d’un aller-retour en JavaScript ; l’inspection montre le token original et un aperçu Number clairement identifié sans changer le document.
Mon ID a changé de valeur après l’analyse. Que s’est-il passé ?
JSON.parse natif de JavaScript utilise des nombres IEEE-754 et peut arrondir les grands identifiants sans erreur de syntaxe : 9007199254740993 devient 9007199254740992. Cet inspecteur montre ce risque à partir du token original. Les convertisseurs de valeurs ToolsByUs refusent les conversions qui perdraient des chiffres, tandis que le formateur et le minificateur préservent le texte. Transmettez les identifiants exacts sous forme de chaînes ou utilisez un parseur avec des entiers de précision arbitraire, tel que le décodeur JSON par défaut de Python.
Que se passe-t-il en cas de clés dupliquées ?
La dernière occurrence gagne, ce que font presque tous les parseurs et ce que la RFC 8259 refuse de spécifier. Cela vaut la peine de le savoir plutôt que de l’ignorer : si deux systèmes d’une chaîne de requêtes résolvent les doublons différemment, un payload peut être validé selon une interprétation et traité selon une autre — une vraie classe de failles de sécurité.
Pourquoi mon JSON avec commentaires est-il refusé ?
Parce que la RFC 8259 n’a pas de commentaires, et qu’un parseur strict a justement pour rôle de vous dire ce qu’une API acceptera. Si votre fichier est une configuration — tsconfig.json, .eslintrc.json — c’est du JSONC, et le Formateur JSON accepte les commentaires et les virgules finales, et peut les supprimer pour vous.
Est-ce que 0.1 vaut exactement 0.1 après l’analyse ?
Non, et ce n’est pas un problème de JSON — c’est le binaire à virgule flottante. 0.1 n’a aucune représentation exacte en double dans aucun langage, d’où le fameux 0.1 + 0.2 qui ne vaut pas 0.3. Pour les montants monétaires, la réponse standard consiste à porter des sous-unités entières (pence, centimes) ou une chaîne décimale, jamais un flottant.
Mon document est-il envoyé quelque part ?
Non. L’analyse s’exécute dans votre navigateur sans téléverser le document. Une fois cette page et ses ressources chargées, l’inspection JSON elle-même fonctionne sans connexion réseau.