5 ms·
First thing I tried was the Haskell Aeson library which keeps the first value of the key: λ> decode f :: Maybe Value Just (Object (fromList [("this_art
by tikhonj 4y ago
First thing I tried was the Haskell Aeson library which keeps the first value of the key:
λ> decode f :: Maybe Value
Just (Object (fromList [("this_article",String "// would be better")]))
There's a more flexible jsonWith function that lets you control how duplicates (and, for that matter, field order) is handled, but it's not the default.
The handful of other tools I spot-checked all keep the last pair, so it seems like almost but not quite standard behavior.
I was curious about other programs and, searching around, found a discussion[1] about standardizing the behavior to "either reject objects with duplicate keys or keep the last value"; however, from a quick scan, that wasn't added to any of the standards documents I found. Apart from the standard I linked earlier there are a couple of JSON RFCs[2][3], but they basically say "different systems do different things and if you depend on the behavior, your JSON won't be universally interoperable"
> 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.
> JSON parsing libraries have been observed to differ as to whether or
not they make the ordering of object members visible to calling
software. Implementations whose behavior does not depend on member
ordering will be interoperable in the sense that they will not be
affected by these differences.
If anything, the fact that it is almost but not quite standard behavior probably makes it worse—you can rely on it for quite a while until it unexpectedly breaks and the figuring out why it broke will be a real headache.
[1]: https://esdiscuss.org/topic/json-duplicate-keys https://esdiscuss.org/topic/json-duplicate-keys
[2]: https://datatracker.ietf.org/doc/html/rfc7159 https://datatracker.ietf.org/doc/html/rfc7159
[3]: https://datatracker.ietf.org/doc/html/rfc8259 https://datatracker.ietf.org/doc/html/rfc8259
- rektide 4y agoI found the EcmaScript specification[1]: > In the case where there are duplicate name Strings within an object, lexically preceding values for the same key shall be overwritten. So in JavaScript, it indeed will always work. But yes, other languages & libraries are under no obligation to follow this behavior. As you clearly show, the JSON spec itself highlights it's displeasure with & the unpredictability of duplicate keys, while also noting the two prevailing behaviors: accept last, or fail. [1] https://262.ecma-international.org/12.0/#sec-internalizejsonproperty https://262.ecma-international.org/12.0/#sec-internalizejson...
- dmitriid 4y agoThere are at least seven different JSON specifications. And no, the ecmascript one isn't the "canonical" one. More details if you ever wanted them, here: https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html
- rektide 4y agoPlease stop trolling my threads to piss on my statememts. You're being awful to me? I dont think I implied at all that kson was canonical nor absolute. I think I agreed thay it was unclear .