php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #65780 failed json_decode forced non-object to array conversion issue
Submitted: 2013-09-28 10:31 UTC Modified: 2016-05-15 15:05 UTC
From: taligahack at gmail dot com Assigned: bukka (profile)
Status: Wont fix Package: JSON related
PHP Version: Irrelevant OS: Windows NT 6.1 build 7601
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2013-09-28 10:31 UTC] taligahack at gmail dot com
Description:
------------
---
From manual page: http://www.php.net/function.json-decode
---

All php/json versions are affected.

The reason i'm writing this bug report/feature request is because the failed 
conversion of the empty string to array is falls back to string output, but not 
resulting NULL or an empty array. There's 
also no way to find out the conversion is failed while the optional parameter 
should force the method to do the conversion (which was obviously impossible).

"Return values" foot note in the json_decode() documentation says:
"NULL is returned if the json cannot be decoded or if the encoded data is deeper 
than the recursion limit."

Which is also misleading. While the json actually decoded, the given assoc=true 
flag should invalidate this result, since the decoded content never made it to 
an object but a string. Therefore, the expected result would be NULL, not the 
string.

It is also important to note here, that the json_last_error() unfortunately 
fails to report the conversion issue, therefore json_decode() fails completely 
silent. The json_last_error() shall report an illegal object/type conversion 
error, because the json_decode() is forced to convert an illegal type.

Test script:
---------------
var_dump( json_decode( json_encode( "" ) , true ) );

var_dump( json_last_error( ) );

Expected result:
----------------
null

int ? > 0


Actual result:
--------------
string '' (length=0)

int 0

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-10-03 15:45 UTC] j26733514 at gmail dot com
i think it's easy to fix this bug at first.
however, there's some embarrassment behavior in decode and encode.
if you decode "", there's empty in the string.

so var_dump(json_decode("")) will get null.

then, i try to test your case 

json_encode(""); 

it will get """" , because you want to convert php string to json string.

the outer quot will read by php, the inner one will read by json.
so, json_encode return string(2) """"

if you decode """", it convert to "" naturally.

that's embrrass but not a wrong bahavior.
 [2013-10-06 14:38 UTC] taligahack at gmail dot com
> if you decode """", it convert to "" naturally.

As long as you leave the optional parameter 'assoc' untouched this behavior is expected yes. But, setting assoc= true one would expect an empty array (or an array with one element) as a result even in this case, but it's not guaranteed, which i found interesting how this should be implemented then. Anyway, a quick lookup at the result ( is_array( $result ) ) could help to avoid this situation, but again this is not the expected result logically. Ironically maybe.
 [2013-10-13 04:16 UTC] j26733514 at gmail dot com
set assoc = true means a json object would convert to php associative array.
there's only json empty string, so it won't return any array.
if you want to return php associative array, at least have "{" and "}", it will convert to php associative array when you set assoc = true
(if set assoc = false, it return php object)
 [2016-05-15 15:05 UTC] bukka@php.net
-Status: Open +Status: Wont fix -Package: json +Package: JSON related -Assigned To: +Assigned To: bukka
 [2016-05-15 15:05 UTC] bukka@php.net
This is not what assoc is for. It is used just for json object decoding to set if php stdObject or assoc array is used. It has nothing to do with string decoding.
 
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Sun Dec 16 13:01:25 2018 UTC