Does JSON syntax allow duplicate keys in an object

Question

Is this valid json          a     x        a     y      http   jsonlint com  says yes   http   www json org  doesn t say anything about it being forbidden   But obviously it doesn t make much sense  does it  Most implementations probably use a hashtable so it is being overriden anyways

User · Answer

There are 2 documents specifying the JSON format:

The accepted answer quotes from the 1st document. I think the 1st document is more clear, but the 2nd contains more detail.

The 2nd document says:

Objects

An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique.

So it is not forbidden to have a duplicate name, but it is discouraged.

User · Answer

The standard does say this      Programming languages vary widely on whether they support objects  and   if so  what characteristics and constraints the objects offer  The   models of object systems can be wildly divergent and are continuing to   evolve  JSON instead provides a simple notation for expressing   collections of name value pairs  Most programming languages will have   some feature for representing such collections  which can go by names   like record  struct  dict  map  hash  or object    The bug is in node js at least   This code succeeds in node js   try        var json     name   n   name   v         console log json      outputs   name   v      catch  e         console log e

User · Answer

Posting and answer because there is a lot of outdated ideas and confusion about the standards   As of December 2017  there are two competing standards   RFC 8259 - https   tools ietf org html rfc8259  ECMA-404 - http   www ecma-international org publications files ECMA-ST ECMA-404 pdf  json org suggests ECMA-404 is the standard  but this site does not appear to be an authority   While I think it s fair to consider ECMA the authority  what s important here is  the only difference between the standards  regarding unique keys  is that RFC 8259 says the keys should be unique  and the ECMA-404 says they are not required to be unique   RFC-8259        The names within an object SHOULD be unique     The word  should  in all caps like that  has a meaning within the RFC world  that is specifically defined in another standard  BCP 14  RFC 2119 - https   tools ietf org html rfc2119   as         SHOULD   This word  or the adjective  RECOMMENDED   mean that   there    may exist valid reasons in particular circumstances to ignore   a    particular item  but the full implications must be understood and   carefully weighed before choosing a different course       ECMA-404        The JSON syntax does not impose any restrictions on the strings used   as names  does not require that name strings be unique  and does not   assign any significance to the ordering of name value pairs     So  no matter how you slice it  it s syntactically valid JSON   The reason given for the unique key recommendation in RFC 8259 is       An object whose names are all unique is interoperable in the sense   that all software implementations receiving that object will agree on   the name-value mappings   When the names within an object are not   unique  the behavior of software that receives such an object is   unpredictable   Many implementations report the last name value pair   only   Other implementations report an error or fail to parse the   object  and some implementations report all of the name value pairs    including duplicates    In other words  from the RFC 8259 viewpoint  it s valid but your parser may barf and there s no promise as to which  if any  value will be paired with that key   From the ECMA-404 viewpoint  which I d personally take as the authority   it s valid  period   To me this means that any parser that refuses to parse it is broken   It should at least parse according to both of these standards   But how it gets turned into your native object of choice is  in any case  unique keys or not  completely dependent on the environment and the situation  and none of that is in the standard to begin with

User · Answer

According to RFC-7159  the current standard for JSON published by the Internet Engineering Task Force  IETF   states  The names within an object SHOULD be unique   However  according to RFC-2119 which defines the terminology used in IETF documents  the word  should  in fact means      there may exist valid reasons in particular circumstances to ignore a particular item  but the full implications must be understood and carefully weighed before choosing a different course   What this essentially means is that while having unique keys is recommended  it is not a must  We can have duplicate keys in a JSON object  and it would still be valid   From practical application  I have seen the value from the last key is considered when duplicate keys are found in a JSON

User · Answer

The short answer  Yes but is not recommended   The long answer  It depends on what you call valid      ECMA-404  The JSON Data Interchange Syntax  doesn t say anything about duplicated names  keys     However  RFC 8259  The JavaScript Object Notation  JSON  Data Interchange Format  says      The names within an object SHOULD be unique    In this context SHOULD must be understood as specified in BCP 14      SHOULD This word  or the adjective  RECOMMENDED   mean that there   may exist valid reasons in particular circumstances to ignore a   particular item  but the full implications must be understood and   carefully weighed before choosing a different course     RFC 8259 explains why unique names  keys  are good      An object whose names are all unique is interoperable in the sense   that all software implementations receiving that object will agree on   the name-value mappings   When the names within an object are not   unique  the behavior of software that receives such an object is   unpredictable   Many implementations report the last name value pair   only   Other implementations report an error or fail to parse the   object  and some implementations report all of the name value pairs    including duplicates        Also  as Serguei pointed out in the comments  ECMA-262  ECMAScript   Language Specification   reads      In the case where there are duplicate name Strings within an object  lexically preceding values for the same key shall be overwritten    In other words  last-value-wins     Trying to parse a string with duplicated names with the Java implementation by Douglas Crockford  the creator of JSON  results in an exception   org json JSONException  Duplicate key  status   at org json JSONObject putOnce JSONObject java 1076

User · Answer

The JSON spec says this      An object is an unordered set of name value pairs    The important part here is  unordered   it implies uniqueness of keys  because the only thing you can use to refer to a specific pair is its key   In addition  most JSON libs will deserialize JSON objects to hash maps dictionaries  where keys are guaranteed unique  What happens when you deserialize a JSON object with duplicate keys depends on the library  in most cases  you ll either get an error  or only the last value for each duplicate key will be taken into account   For example  in Python  json loads    a   1   a   2    returns   a   2

User · Answer

From the standard  p  ii       It is expected that other standards will refer to this one  strictly adhering to the JSON text format  while    imposing restrictions on various encoding details  Such standards may require specific behaviours  JSON    itself specifies no behaviour     Further down in the standard  p  2   the specification for a JSON object      An object structure is represented as a pair of curly bracket tokens surrounding zero or more name value pairs     A name is a string  A single colon token follows each name  separating the name from the value  A single    comma token separates a value from a following name           It does not make any mention of duplicate keys being invalid or valid  so according to the specification I would safely assume that means they are allowed   That most implementations of JSON libraries do not accept duplicate keys does not conflict with the standard  because of the first quote   Here are two examples related to the C   standard library  When deserializing some JSON object into a std  map it would make sense to refuse duplicate keys  But when deserializing some JSON object into a std  multimap it would make sense to accept duplicate keys as normal

User · Answer

In C  if you deserialise to a Dictionary lt string  string gt  it takes the last key value pair   string json        a      x      a      y      var d   JsonConvert DeserializeObject lt Dictionary lt string  string gt  gt  json         a     y      if you try to deserialise to   class Foo        JsonProperty  a        public string Bar   get  set          JsonProperty  a        public string Baz   get  set       var f   JsonConvert DeserializeObject lt Foo gt  json     you get a Newtonsoft Json JsonSerializationException exception

User · Answer

SHOULD be unique does not mean MUST be unique  However  as stated  some parsers would fail and others would just use the last value parsed  However  if the spec was cleaned up a little to allow for duplicates then I could see a use where you may have an event handler which is transforming the JSON to HTML or some other format    In such cases it would be perfectly valid to parse the JSON and create another document format         quot div quot            quot p quot    quot hello quot        quot p quot    quot universe quot          quot div quot            quot h1 quot    quot Heading 1 quot        quot p quot    quot another paragraph quot         could then easily parse to html for example   lt body gt    lt div gt     lt p gt hello lt  p gt     lt p gt universe lt  p gt    lt  div gt    lt div gt     lt h1 gt Heading 1 lt  h1 gt     lt p gt another paragraph lt  p gt    lt  div gt   lt  body gt   I can see the reasoning behind the question but as it stands    I wouldn t trust it

User · Answer

It s not defined in the ECMA JSON standard  And generally speaking  a lack of definition in a standard means   Don t count on this working the same way everywhere    If you re a gambler   many  JSON engines will allow duplication and simply use the last-specified value  This   var o     a   1   b   2   a   3    Becomes this   Object  a  3  b  2    But if you re not a gambler  don t count on it

User · Answer

Asking for purpose  there are different answers   Using JSON to serialize objects  JavaScriptObjectNotation   each dictionary element maps to an indivual object property  so different entries defining a value for the same property has no meaning   However  I came over the same question from a very specific use case  Writing JSON samples for API testing  I was wondering how to add comments into our JSON file without breaking the usability  The JSON spec does not know comments  so I came up with a very simple approach   To use duplicate keys to comment our JSON samples  Example          property1     value1      REMARK         prop1 controls             property2     value2      REMARK         value2 raises an exception          The JSON serializers which we are using have no problems with these  REMARK  duplicates and our application code simply ignores this little overhead   So  even though there is no meaning on the application layer  these duplicates for us provide a valuable workaround to add comments to our testing samples without breaking the usability of the JSON

User · Answer

I came across a similar question when dealing with an API that accepts both XML and JSON  but doesn t document how it would handle what you d expect to be duplicate keys in the JSON accepted   The following is a valid XML representation of your sample JSON    lt object gt     lt a gt x lt  a gt     lt a gt y lt  a gt   lt  object gt    When this is converted into JSON  you get the following        object          a            x          y                A natural mapping from a language that handles what you might call duplicate keys to another  can serve as a potential best practice reference here    Hope that helps someone

[json] Does JSON syntax allow duplicate keys in an object?

Examples related to json

Examples related to standards