标签云

微信群

扫码加入我们

WeChat QR Code

不允许复制的钥匙在JSON语法对象?

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.


C# 's Json.NET removes the first key pair if you deserialise to a Dictionary<string, string>

2018年05月27日29分39秒

In case anyone arrives here hoping for a solution to find duplicate values in JSON strings, check out the free online json validator

2018年05月27日29分39秒

jsonlint.com says yes. it does not, it removes all but the last key-value pair and then validates it, which makes it valid

2018年05月27日29分39秒

Yes, it's valid semantically according to the stanard. But as you say, this will likely break so many places, no-one should use it this way.

2018年05月27日29分39秒

Then the standard is broken

2018年05月27日29分39秒

i guess i can accept this as an answer, though i like the mention of PatrickGoley that on json.org it is called a set of key/value-pairs which implies uniqueness which would mean it is not valid.

2018年05月28日29分39秒

clamp json.org is not the standard and, as far I can tell, is not run by Emca International. json.org seems presented anonymously. This is the specification: ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf What it says on json.org is not relevant.

2018年05月27日29分39秒

clamp Consider the std::multimap example I just added. It can be serialized as a JSON object with potentially duplicate keys.

2018年05月27日29分39秒

JSON is supposed to be valid javascript, so it's relevant to check whether duplicate keys are valid JS in literals. V8 seems to accept them: d8 -e 'x={"a":1,"a":2}; print(x.a);' This prints 2.

2018年05月27日29分39秒

Also the ECMA-262 spec for JSON.parse() explicitly says 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).

2018年05月27日29分39秒

BenCrowell: As far as I know, JSON is not supposed to be valid JavaScript and there are cases where it's not, see timelessrepo.com/json-isnt-a-javascript-subset. With that said, it was of course heavily inspired by JavaScript (it even says so in the JSON specification).

2018年05月27日29分39秒

SHOULD is not MUST, so shouldn’t the short answer be “yes”?

2018年05月28日29分39秒

binki Yes, it should. And "it depends on what you call valid" is nonsense - what's valid is what conforms to the requirements and allowances of the specification, the rest is recommendation. What this answer got right are the parts copied and pasted from the specifications, sadly the conclusions it draws based on them are wrong.

2018年05月27日29分39秒

does unordered imply uniqueness? I think set is the operative word here

2018年05月27日29分39秒

An unordered collection of colors: Blue, Green, Green, Blue, Red, Blue, Green - It has duplicates.

2018年05月28日29分39秒

The text phrase you are quoting, "An object is an unordered set of name/value pairs," does not appear in the JSON spec...

2018年05月27日29分39秒

I see now that you were quoting json.org. It's 'close' to official, but it's not the specification. Top of the page has a link to the specification, which is repeated verbatim on json.org. If you search the spec., the word "unordered" does not appear, and the word "set" appears only in contexts unrelated to JSON objects.

2018年05月27日29分39秒

Note that it says "unordered set of name/value pairs", pairs not names. That is, { (a,b), (a,c) } is a unique set. So technically under the json.org definition {"a":1,"a":2} is valid but {"a":1,"a":2,"a":1} is not. Also note that ECMA-404 (the actual standard) avoids using the word "set": An object structure is represented as a pair of curly bracket tokens surrounding zero or more name/value pairs.

2018年05月27日29分39秒

This is a bad idea. By including duplicate keys, even if you don't need to read the data in them, you're relying on undefined behaviour. Some parsers, such as Crockford's JSON-java parser, throw an exception and refuse to parse the data.

2018年05月27日29分39秒

Actually working perfectly in our environment, so serving my needs, even though I agree with you that it's some kind out of spec ;)

2018年05月28日29分39秒

RichardSmith I’d say the parsers and newer ES specs have defined the behavior.

2018年05月27日29分39秒

Your first example’s array is missing a comma. Also, it is inconsistent with itself. If you’re going to use a dictionary as an ordered collection, your outer array should also just be an object. I.e., {"div":{"p":"hello","p":"universe"}, "div":{"h1":"Heading 1","p":"another paragraph"}}. Now, lots of people and frameworks treat JSON objects as unordered dictionaries, but JavaScript and e.g. MongoDB’s API rely on ordering of keys within dictionaries, so what you’re suggesting (ordered dictionaries) is not unheard of. You’d just need a specialized parser.

2018年05月27日29分39秒

i guess that is what most (if not all) implementations do, but it doesnt answer my question if it is valid as of the specification of JSON.

2018年05月28日29分39秒

svidgen: This isn't even Microsoft's implementation... it's a third-party library.

2018年05月27日29分39秒

BoltClock Ah, touche.

2018年05月28日29分39秒

It's not a bug, and section you quoted explains why it is not: different languages behave differently, and JSON parsers will do what's most natural for that language. In any case, this answer doesn't add anything that user454322 hasn't already said above.

2018年05月27日29分39秒