Razvan-Catalin Olaru Razvan-Catalin Olaru - 4 months ago 34
jQuery Question

How to generate a JSON object dynamically with duplicate keys?

I know this will sound impossible but my boss told me I MUST send a JSON over an AJAX post call with jQuery that MUST HAVE DUPLICATE KEYS. the problem is that if I write something like this:

$.post("someurl", {
"key1" : "value1",
"key2" : "value2",
"key2" : "value3",
"key2" : "value4",
"key3" : "value5"
});


, jQuery will send the request as

someurl?key1=value1&key2=value4&key3=value5


all this because Javascript overwrites properties that have the same name. The JSON object is generated dynamically and I am NOT ALLOWED to use arrays in it. Can someone tell me how could I generate the JSON object dinamicaly and with duplicate keys?

I would realy appreciate any help from you!

Answer

From what I can see, {"a": "b", "a": "c"} actually is valid JSON according to RFC 4627.

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.

...where SHOULD means:

3. 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.

So yeah, basically you can do that, it is legal, but it's also a bad idea. Different JSON decoders will probably handle this situation differently and/or in undesiderable ways. Look at what the spec requires of parsers:

A JSON parser transforms a JSON text into another representation. A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions.

An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range of numbers. An implementation may set limits on the length and character contents of strings.

...but an implementation doesn't have to handle situations like this sanely. For example:

# Python 2.7
>>> import json
>>> json.JSONDecoder().decode('{"a": "b", "a": "c"}')
`{u'a': u'c'}`
# Chrome 32
> JSON.parse('{"a": "b", "a": "c"}')
Object {a: "c"}

...and other implementations may legally give you (in Python notation):

  • {"a": "b"}
  • [("a", "b"), ("a", "c")]
  • [("a", ["b", "c"])]
  • []
  • 42
  • "your JSON is bad and you should feel bad"

...or just good old nasal daemons. Literally the only illegal thing for a JSON parser to do here is raise an exception.

The last thing you want to do in your production code is to rely on weird side cases. So the last thing you want to do is exercise your right to form nominally legal but practically useless JSON. If you want to do that, you'll have to do it by hand - build your own abstract syntax trees, your own parsers, your own generators, generators for anybody who might want to consume your data...

Comments