Outils de développement · JSON formateur et validateur
Clés en double dans JSON : ce que RFC 8259 autorise et ce que font les analyseurs
· Contexte
json normes validation
JSON autorise la même clé deux fois, la spécification dit seulement que les noms « devraient » être uniques et les analyseurs ne sont pas d'accord sur la valeur qui l'emporte. Cet article explique pourquoi cela est important pour l'exactitude et la sécurité.
Quel « rôle » le serveur a-t-il lu ?
Considérez `{"role":"viewer","role":"editor"}`. Les deux membres sont grammaticalement complets, donc ToolAcre signale un JSON valide. Lorsque le texte atteint `JSON.parse`, l'objet résultant possède une propriété `role` dont la valeur est `"editor"`. Le membre précédent n’est pas conservé comme historique masqué. Une vérification de syntaxe réussie ne répond donc pas à la question de savoir si les noms d'objet sont apparus plus d'une fois.
Le formatage rend la perte visible seulement après qu'elle se soit produite : la sortie contient `{"role":"editor"}` dans la mise en page choisie. Il ne peut pas reproduire le membre `viewer` supprimé, car la sérialisation reçoit l'objet analysé, et non la séquence de membres d'origine. Si les noms répétés sont importants pour une révision, conservez et inspectez le texte source avant d'appuyer sur Format plutôt que de vous fier au résultat normalisé.
La grammaire le permet, la spécification le décourage
RFC 8259 indique que les noms dans un objet doivent être uniques. Ce « devrait » favorise une sortie interopérable sans intégrer l’unicité dans la grammaire des objets de base. Un nom répété se compose toujours d'une chaîne valide, de deux points et d'une valeur séparée par des virgules. Par conséquent, un validateur de grammaire peut accepter le document tandis qu'une politique d'application le rejette.
Cette distinction est facile à ignorer car de nombreuses erreurs sont des échecs de syntaxe obligatoires : un deux-points manquant ou une virgule finale ne peuvent pas du tout former un objet JSON. Les doublons sont différents. Ils créent une question d'interopérabilité une fois que l'analyseur a reconnu chaque jeton. ToolAcre s'arrête intentionnellement à la syntaxe et n'ajoute pas de règle de nom en double, son résultat Valid ne doit donc pas être lu comme une garantie d'unicité.
Que font JSON.parse et ToolAcre
`JSON.parse` utilise l'occurrence la plus récente lorsque les noms d'objets se répètent. ToolAcre hérite de ce comportement car il analyse avant le formatage. Pour `{"limit":10,"limit":25,"unit":"items"}`, la validation réussit, la limite analysée est 25 et la sortie formatée contient un `limit`. Le tri facultatif par clé peut repositionner cette propriété survivante mais ne peut pas exposer l'occurrence écrasée.
Ne généralisez pas ce résultat à chaque analyseur ou configuration. Certains systèmes peuvent rejeter les doublons et d'autres piles de traitement peuvent appliquer une politique différente ou inspecter les jetons avant de construire un objet. La déclaration de sécurité inter-systèmes est étroite : les noms répétés ne sont pas interopérables de manière fiable. Vérifiez les modes d'analyseur réels utilisés à chaque limite lorsque la distinction est importante, plutôt que de vous fier à une revendication à l'échelle de la langue.
Quand le désaccord des analyseurs devient un risque
Les doublons ne deviennent un problème de sécurité que dans un chemin concret à plusieurs étapes où les composants interprètent différemment le même texte. Par exemple, un filtre de requête peut inspecter une occurrence pendant que l'application en consomme une autre. La question de savoir si cela peut se produire dépend des analyseurs exacts, des options, du comportement de transfert et de l'utilisation du champ. La syntaxe dupliquée à elle seule ne constitue pas un contournement exploitable.
Le contrôle défendable consiste à établir une politique à la limite de confiance et à tester la pile réelle. Rejetez les noms en double avant la construction d'objets avec perte lorsque l'ambiguïté est inacceptable, ou assurez-vous que chaque composant reçoit la même représentation déjà analysée. ToolAcre peut démontrer son propre comportement de formatage des derniers gains, mais il ne peut pas auditer les passerelles, les frameworks ou les services qui ne font pas partie de l'outil de navigation.
Exemple concret : un document avec une clé répétée
Collez `{"theme":"light","prefs":{"density":"roomy","density":"compact"},"theme":"dark"}`. ToolAcre accepte le texte car chaque membre est syntaxiquement valide. L'analyse laisse le thème racine comme `dark` et la densité imbriquée comme `compact`. Le formatage émet une copie de chaque nom, de sorte que les deux valeurs précédentes disparaissent du document affiché.
Cet exemple montre également pourquoi la recherche du résultat formaté est trop tardive. La détection des doublons doit observer les noms de membres lors de la lecture du flux de jetons d'origine, à chaque profondeur d'objet. Les tableaux n'ont pas besoin de règle de duplication de nom, bien que des règles d'application distinctes puissent se soucier des valeurs d'éléments répétées. Conservez la source inchangée, exécutez un analyseur ou un linter prenant en compte les doublons et décidez si la politique est un avertissement ou un rejet.
Détection volontaire des doublons
Utilisez un outil qui promet explicitement la détection des noms en double sur la source JSON. Les approches appropriées incluent un mode analyseur qui échoue lors des répétitions, un gestionnaire de jetons de streaming qui suit les noms de chaque objet ouvert ou un linter avec une règle de clé en double documentée. Vérifiez les objets imbriqués et les noms d'échappement : `"name"` et `"name"` décodent avec le même nom de membre même si leurs orthographes sources diffèrent.
JSON Le schéma n'est pas un substitut une fois que l'analyse ordinaire a écarté les occurrences antérieures. Un validateur de schéma reçoit généralement la valeur construite et voit une propriété, et non l'historique du jeton en double. Exécutez une vérification d'unicité avant ou pendant l'analyse, puis appliquez des vérifications de schéma à la valeur sans ambiguïté. ToolAcre n'effectue ni détection des doublons ni validation de schéma, les deux nécessitent donc une étape distincte et spécialement conçue.
Ce que cela ne couvre pas
Les noms d'objet répétés ne sont pas identiques aux valeurs répétées dans les enregistrements. `[ {"id":7}, {"id":7} ]` contient deux objets distincts, chacun avec un `id` ; en détectant un identifiant en double, il existe une règle d'ensemble de données. De même, deux éléments de tableau avec la même chaîne restent deux positions intentionnelles à moins qu'un contrat d'application n'indique que le tableau représente un ensemble.
Cet article ne prétend pas à une politique universelle du premier gagnant, du dernier gagnant ou du rejet pour les grands écosystèmes linguistiques. Il enregistre le comportement `JSON.parse` observable de ToolAcre et explique pourquoi un autre composant doit être vérifié directement. Il ne détermine pas non plus l’exploitabilité à partir d’un seul duplicata. L’impact sur la sécurité nécessite la preuve que des interprétations différentes traversent une limite d’autorisation, de routage ou de validation pertinente.
À retenir : un JSON valide n'est pas toujours sans ambiguïté JSON
Un résultat ToolAcre Valid signifie que la séquence de jetons est stricte JSON ; cela ne signifie pas que chaque nom d'objet est unique. `JSON.parse` conserve la dernière valeur d'un nom répété et le formatage sérialise uniquement ce survivant. Étant donné que l'occurrence précédente est effacée, la sortie formatée ne constitue pas une preuve appropriée pour décider si la source originale contenait des doublons.
Lorsque l'unicité est importante, inspectez le texte original avec des outils de détection des doublons avant l'analyse ou le formatage ordinaire. Appliquez ensuite la validation du schéma et du domaine à la valeur sans ambiguïté résultante. Pour l'examen de la sécurité, tracez le chemin réel de la requête et les paramètres de l'analyseur au lieu de supposer un désaccord. La règle pratique est simple : l'acceptation de la syntaxe, la politique de doublon et la signification en aval sont des contrôles distincts avec des preuves distinctes.