La syntaxe JSON autorise-t-elle la duplication des clés dans un objet?

Est-ce un json valide?

{
    "a" : "x",
    "a" : "y"
}

http://jsonlint.com/ dit oui.

http://www.json.org/ ne dit rien sur l'interdiction.

Mais évidemment, cela n'a pas beaucoup de sens, n'est-ce pas? La plupart des implémentations utilisent probablement une table de hachage donc elle est de toute façon annulée.

De la norme (p. Ii) :

Il est prévu que d'autres normes se réfèrent à celui-ci, respectant strictement le format de texte JSON, tout en imposant des restrictions sur divers détails d'encodage. Ces normes peuvent nécessiter des comportements spécifiques. JSON lui-même ne spécifie aucun comportement.

Plus bas dans la norme (p. 2), la spécification d'un objet JSON:

Une structure d'objet est représentée comme une paire de jetons entre crochets entourant zéro ou plusieurs paires nom / valeur. Un nom est une chaîne. Un seul jeton deux-points suit chaque nom, séparant le nom de la valeur. Un seul jeton virgule sépare une valeur d'un nom suivant.

Il ne fait aucune mention de clés en double non valides ou valides, donc selon la spécification, je suppose que cela signifie qu'elles sont autorisées.

Le fait que la plupart des implémentations des bibliothèques JSON n'acceptent pas les clés en double n'entre pas en conflit avec la norme, en raison de la première citation.

Voici deux exemples liés à la bibliothèque standard C ++. Lors de la désérialisation d'un objet JSON en un, std::mapil serait logique de refuser les clés en double. Mais lors de la désérialisation d'un objet JSON en un, std::multimapil serait logique d'accepter les clés en double comme d'habitude.

La réponse courte: oui mais n'est pas recommandée.
La réponse longue: cela dépend de ce que vous appelez valide ...

ECMA-404 "La syntaxe d'échange de données JSON" ne dit rien sur les noms (clés) dupliqués.

Cependant, la RFC 8259 "Le format d'échange de données JSON (JavaScript Object Notation)" dit:

Les noms dans un objet DEVRAIENT être uniques.

Dans ce contexte, DEVRAIT être compris comme spécifié dans le BCP 14 :

DEVRAIT Ce mot, ou l'adjectif «RECOMMANDÉ», signifie qu'il peut exister des raisons valables dans des circonstances particulières d'ignorer un élément particulier, mais toutes les implications doivent être comprises et soigneusement pesées avant de choisir un cours différent.

La RFC 8259 explique pourquoi les noms uniques (clés) sont bons:

Un objet dont les noms sont tous uniques est interopérable dans le sens où toutes les implémentations logicielles recevant cet objet seront d'accord sur les mappages nom-valeur. Lorsque les noms d'un objet ne sont pas uniques, le comportement du logiciel qui reçoit un tel objet est imprévisible. De nombreuses implémentations signalent uniquement la paire nom / valeur. D'autres implémentations signalent une erreur ou ne parviennent pas à analyser l'objet, et certaines implémentations signalent toutes les paires nom / valeur, y compris les doublons.

En outre, comme l'a souligné Serguei dans les commentaires: ECMA-262 "ECMAScript® Language Specification", se lit comme suit:

Dans le cas où il existe des chaînes de nom en double dans un objet, les valeurs lexicalement précédentes pour la même clé doivent être écrasées.

En d'autres termes, la dernière valeur l'emporte.

Essayer d'analyser une chaîne avec des noms en double avec l' implémentation Java par Douglas Crockford (le créateur de JSON) entraîne une exception :

org.json.JSONException: Duplicate key "status"  at
org.json.JSONObject.putOnce(JSONObject.java:1076)

Il existe 2 documents spécifiant le format JSON:

1. http://json.org/
2. https://tools.ietf.org/html/rfc7159

La réponse acceptée cite le premier document. Je pense que le 1er document est plus clair, mais le 2e contient plus de détails.

Le 2ème document dit:

4. Objets

   Une structure d'objet est représentée comme une paire de crochets entourant zéro ou plusieurs paires nom / valeur (ou membres). Un nom est une chaîne. Un deux-points vient après chaque nom, séparant le nom de la valeur. Une seule virgule sépare une valeur d'un nom suivant. Les noms dans un objet DEVRAIENT être uniques.

Il n'est donc pas interdit d'avoir un nom en double, mais il est déconseillé.

Je suis tombé sur une question similaire en traitant avec une API qui accepte à la fois XML et JSON, mais ne documente pas comment il gérerait ce que vous attendez d'être des clés en double dans le JSON accepté.

Voici une représentation XML valide de votre exemple JSON:

<object>
  <a>x</a>
  <a>y</a>
</object>

Lorsque cela est converti en JSON, vous obtenez les éléments suivants:

{
  "object": {
    "a": [
      "x",
      "y"
    ]
  }
}

Un mappage naturel à partir d'un langage qui gère ce que vous pourriez appeler des clés en double dans un autre peut servir ici de référence potentielle aux meilleures pratiques.

J'espère que cela aide quelqu'un!

La spécification JSON dit ceci:

Un objet est un ensemble non ordonné de paires nom / valeur.

La partie importante ici est "non ordonnée": elle implique l'unicité des clés, car la seule chose que vous pouvez utiliser pour faire référence à une paire spécifique est sa clé.

De plus, la plupart des bibliothèques JSON désérialisent les objets JSON en cartes / dictionnaires de hachage, où les clés sont garanties uniques. Ce qui se passe lorsque vous désérialisez un objet JSON avec des clés en double dépend de la bibliothèque: dans la plupart des cas, vous obtiendrez soit une erreur, soit seule la dernière valeur de chaque clé en double sera prise en compte.

Par exemple, en Python, json.loads('{"a": 1, "a": 2}')renvoie {"a": 2}.

DEVRAIT être unique ne signifie pas DOIT être unique. Cependant, comme indiqué, certains analyseurs échoueraient et d'autres utiliseraient simplement la dernière valeur analysée. Cependant, si la spécification a été nettoyée un peu pour permettre les doublons, je pourrais voir une utilisation où vous pourriez avoir un gestionnaire d'événements qui transforme le JSON en HTML ou dans un autre format ... dans de tels cas, il serait parfaitement valide pour analyser le JSON et créer un autre format de document ...

[
  "div":
  {
    "p":"hello",
    "p":"universe"
  }
  "div":
  {
    "h1":"Heading 1",
    "p":"another paragraph"
  }
]

pourrait alors facilement analyser en html par exemple

<body>
 <div>
  <p>hello</p>
  <p>universe</p>
 </div>
 <div>
  <h1>Heading 1</h1>
  <p>another paragraph</p>
 </div>
</body>

Je peux voir le raisonnement derrière la question, mais en l'état ... je n'y ferais pas confiance.

Demander à des fins, il existe différentes réponses:

À l'aide de JSON pour sérialiser des objets (JavaScriptObjectNotation), chaque élément de dictionnaire est mappé à une propriété d'objet individuelle, de sorte que différentes entrées définissant une valeur pour la même propriété n'ont aucune signification.

Cependant, je suis tombé sur la même question à partir d'un cas d'utilisation très spécifique: en écrivant des échantillons JSON pour les tests d'API, je me demandais comment ajouter des commentaires dans notre fichier JSON sans casser l'utilisabilité. La spécification JSON ne connaît pas les commentaires, j'ai donc proposé une approche très simple:

Pour utiliser des clés en double pour commenter nos exemples JSON . Exemple:

{ "property1" : "value1", "REMARK" : "... prop1 controls ...", "property2" : "value2", "REMARK" : "... value2 raises an exception ...", }

Les sérialiseurs JSON que nous utilisons n'ont aucun problème avec ces doublons "REMARK" et notre code d'application ignore simplement ce petit surcoût.

Ainsi, même s'il n'y a aucune signification sur la couche application, ces doublons pour nous fournissent une solution de contournement précieuse pour ajouter des commentaires à nos échantillons de test sans rompre l'utilisabilité du JSON.

Publication et réponse car il y a beaucoup d'idées obsolètes et de confusion sur les normes. En décembre 2017, il y avait deux normes concurrentes:

RFC 8259 - https://tools.ietf.org/html/rfc8259

ECMA-404 - http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

json.org suggère que l'ECMA-404 est la norme, mais ce site ne semble pas être une autorité. Bien que je pense qu'il est juste de considérer l'ECMA comme l'autorité, ce qui est important ici, c'est que la seule différence entre les normes (concernant les clés uniques) est que la RFC 8259 dit que les clés doivent être uniques, et l'ECMA-404 dit qu'elles ne sont pas tenues d'être unique.

RFC-8259:

"Les noms dans un objet DEVRAIENT être uniques."

Le mot "devrait" dans toutes les majuscules comme ça, a une signification dans le monde RFC, qui est spécifiquement définie dans une autre norme (BCP 14, RFC 2119 - https://tools.ietf.org/html/rfc2119 ) comme,

3. DEVRAIT Ce mot, ou l'adjectif "RECOMMANDÉ", signifie qu'il peut exister des raisons valables dans des circonstances particulières d'ignorer un élément particulier, mais toutes les implications doivent être comprises et soigneusement pesées avant de choisir un cours différent.

ECMA-404:

"La syntaxe JSON n'impose aucune restriction sur les chaînes utilisées comme noms, n'exige pas que les chaînes de nom soient uniques et n'attribue aucune signification à l'ordre des paires nom / valeur."

Donc, peu importe la façon dont vous le découpez, il s'agit d'un JSON syntaxiquement valide .

La raison donnée pour la recommandation clé unique dans la RFC 8259 est,

Un objet dont les noms sont tous uniques est interopérable dans le sens où toutes les implémentations logicielles recevant cet objet seront d'accord sur les mappages nom-valeur. Lorsque les noms d'un objet ne sont pas uniques, le comportement du logiciel qui reçoit un tel objet est imprévisible. De nombreuses implémentations signalent uniquement la paire nom / valeur. D'autres implémentations signalent une erreur ou ne parviennent pas à analyser l'objet, et certaines implémentations signalent toutes les paires nom / valeur, y compris les doublons.

En d'autres termes, du point de vue RFC 8259, c'est valide mais votre analyseur peut aboyer et il n'y a aucune promesse quant à la valeur, le cas échéant, qui sera associée à cette clé. Du point de vue ECMA-404 (que je considérerais personnellement comme l'autorité), c'est valable, point final. Pour moi, cela signifie que tout analyseur qui refuse de l'analyser est brisé. Il doit au moins analyser selon ces deux normes. Mais la façon dont il devient votre objet natif de choix est, en tout cas, des clés uniques ou non, complètement dépendantes de l'environnement et de la situation, et rien de tout cela n'est dans la norme pour commencer.

Il n'est pas défini dans la norme ECMA JSON . Et d'une manière générale, un manque de définition dans une norme signifie: «Ne comptez pas sur ce fonctionnement partout de la même manière».

Si vous êtes un joueur, "de nombreux" moteurs JSON permettront la duplication et utiliseront simplement la dernière valeur spécifiée. Ce:

var o = {"a": 1, "b": 2, "a": 3}

Devient ceci:

Object {a: 3, b: 2}

Mais si vous n'êtes pas un joueur, ne comptez pas dessus!

La norme dit ceci:

Les langages de programmation varient considérablement selon qu'ils prennent en charge des objets et, dans l'affirmative, quelles caractéristiques et contraintes offrent les objets. Les modèles de systèmes d'objets peuvent être très divergents et continuent d'évoluer. JSON fournit à la place une notation simple pour exprimer des collections de paires nom / valeur. La plupart des langages de programmation auront une fonction pour représenter de telles collections, qui peuvent s'appeler par des noms comme record, struct, dict, map, hash ou object.

Le bogue est au moins dans node.js. Ce code réussit dans node.js.

try {
     var json = {"name":"n","name":"v"};
     console.log(json); // outputs { name: 'v' }
} catch (e) {
     console.log(e);
}

Selon la RFC-7159, la norme actuelle pour JSON publiée par l'Internet Engineering Task Force (IETF), stipule que "les noms dans un objet DEVRAIENT être uniques". Cependant, selon la RFC-2119 qui définit la terminologie utilisée dans les documents de l'IETF, le mot "devrait" signifie en fait "... il peut exister des raisons valables dans des circonstances particulières d'ignorer un élément particulier, mais toutes les implications doivent être comprises et soigneusement pesé avant de choisir un cours différent. " Cela signifie essentiellement que bien qu'il soit recommandé d'avoir des clés uniques, ce n'est pas un must. Nous pouvons avoir des clés en double dans un objet JSON, et ce serait toujours valide.

De l'application pratique, j'ai vu que la valeur de la dernière clé est considérée lorsque des clés en double sont trouvées dans un JSON.

En C # si vous désérialisez en un Dictionary<string, string>il faut la dernière paire de valeurs clés:

string json = @"{""a"": ""x"", ""a"": ""y""}";
var d = JsonConvert.DeserializeObject<Dictionary<string, string>>(json);
// { "a" : "y" }

si vous essayez de désérialiser

class Foo
{
    [JsonProperty("a")]
    public string Bar { get; set; }

    [JsonProperty("a")]
    public string Baz { get; set; }
}

var f = JsonConvert.DeserializeObject<Foo>(json);

vous obtenez une Newtonsoft.Json.JsonSerializationExceptionexception.