|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52829 json_decode looses data
Submitted: 2010-09-13 20:31 UTC Modified: 2010-09-14 07:55 UTC
From: pzbowen at gmail dot com Assigned:
Status: Not a bug Package: JSON related
PHP Version: 5.2.14 OS: Linux
Private report: No CVE-ID: None
 [2010-09-13 20:31 UTC] pzbowen at gmail dot com
According to RFC 4627, section 2.2, "The names within an object SHOULD be unique."  This is only a SHOULD not a MUST, so the following is valid


Unfortunately in PHP this only returns the last object member.

Test script:

Expected result:
an object with a way of accessing both members or an error raised by json_decode

Actual result:
object(stdClass)#1 (1) {


json-decode-warnings (last revision 2010-09-14 05:48 UTC by

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-09-13 21:49 UTC]
I can't see any really easy way to achieve this since properties and array keys are unique in PHP. Perhaps some overloading with objects but that would be dirty/hackish
 [2010-09-13 22:03 UTC] pzbowen at gmail dot com
Agreed, no easy way to handle it, so it should return an error when this situation is encountered.
 [2010-09-14 07:48 UTC]
The following patch has been added/updated:

Patch Name: json-decode-warnings
Revision:   1284443322
 [2010-09-14 07:48 UTC]
-Status: Open +Status: Analyzed
 [2010-09-14 07:48 UTC]
The attached patch against trunk would cause the JSON parser to emit warnings for duplicate keys. The behaviour otherwise would be unchanged; the last value would be the one in the returned object/array.

I'm holding off on committing it, though, for two reasons:

1. I'm not thrilled about emitting warnings, since they're difficult to handle. We could return false from json_decode() instead and add a return value to json_last_error() along the lines of JSON_ERROR_DUPLICATE_NAME, but that doesn't seem any better to me: I don't think this should stop decoding if the file is otherwise valid.

2. There is a performance impact from doing the extra checks. Cursory benchmarking would suggest it's on the order of a 5% slowdown in decoding speed.

So, if we decide we can live with the speed hit, I'd still like to hear any bright ideas people might have for signalling these warnings in a way that's easy for users to handle and still allows decoding to succeed where possible.
 [2010-09-14 07:55 UTC]
-Status: Analyzed +Status: Bogus
 [2010-09-14 07:55 UTC]
We meet the spec here, it says SHOULD be unique and we don't do anything that 
violates that.

What you're asking is to make something noisy for no good reason.

How does Python or Perl handle this? My tests show that the last entry 
overwrites the first, this is just how JavaScript handles it too.

Nothing to fix here.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Jul 19 15:01:28 2024 UTC