php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #78765 enhancement to json_decode : treat a JSON string with duplicate keys as invalid
Submitted: 2019-10-31 10:31 UTC Modified: 2019-11-10 04:26 UTC
Votes:8
Avg. Score:3.9 ± 0.9
Reproduced:5 of 6 (83.3%)
Same Version:3 (60.0%)
Same OS:2 (40.0%)
From: bas5winkel at gmail dot com Assigned:
Status: Open Package: JSON related
PHP Version: 7.2.24 OS: Debian
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: bas5winkel at gmail dot com
New email:
PHP Version: OS:

 

 [2019-10-31 10:31 UTC] bas5winkel at gmail dot com 
Description:
------------
Duplicate key names are not allowed in the JSON format.
If a json string containing duplicate keys is decoded with json_decode,
json_decode simple overwrites the existing key.
Just like json_encode returns NULL for other invalid JSON strings,
could such an input also be treated as invalid?
Maybe as an optional check as this is just a rare condition?



Test script:
---------------
<?php
echo var_export(json_decode('{"a":"b","a":"c"}'),1);
?>

Expected result:
----------------
NULL or an exception

Actual result:
--------------
stdClass::__set_state(array(
   'a' => 'c',
))

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-10-31 10:43 UTC] danack@php.net 
To note one thing, although having some way of indicating duplicate keys sounds like a useful thing (as opposed to silently discarding them), the JSON format does not appear to forbid duplicate keys:


From http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

"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. These are all semantic considerations that may be defined by
JSON processors or in specifications defining specific uses of JSON for data interchange."
 [2019-10-31 10:44 UTC] requinix@php.net
-Status: Open +Status: Feedback -Type: Bug +Type: Feature/Change Request
 [2019-10-31 10:44 UTC] requinix@php.net 
Same for IETF:
> 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.
https://tools.ietf.org/html/rfc8259#section-4
 [2019-10-31 10:53 UTC] cmb@php.net 
In my opinion, that would be a sensible improvement.  From a quick
look, it might be sufficient to check whether respective entries
already exist in php_json_parser_object_update[1], and to set an
error flag in this case.  And/or add an option, and return NULL or
throw an exception if there are duplicate entries.  A pull request
would be welcome!

[1] <https://github.com/php/php-src/blob/master/ext/json/json_parser.y#L250-L269>
 [2019-11-10 04:22 UTC] php-bugs at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2019-11-10 04:26 UTC] requinix@php.net
-Status: No Feedback +Status: Open
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 19:01:28 2024 UTC