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

go to bug id or search bugs for

Request #62422 Function that always produces legal JSON
Submitted: 2012-06-26 14:58 UTC Modified: 2012-08-06 01:31 UTC
From: arnfda at gmail dot com Assigned:
Status: Wont fix Package: JSON related
PHP Version: 5.4.4 OS: OS X 10.6.8
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: arnfda at gmail dot com
New email:
PHP Version: OS:

 

 [2012-06-26 14:58 UTC] arnfda at gmail dot com 
Description:
------------
json_encode generates illegal JSON when it is passed a string, boolean, or 
number. This behavior is noted here, along with a workaround: 
http://www.php.net/manual/en/function.json-encode.php#92817

json_decode accepts the illegal JSON, but other parsers that are more strict do 
not (for example, MultiJson in Ruby).

I know the documentation doesn't promise to return valid JSON text, just the 
"JSON representation" of whatever is passed into it. So strictly speaking, this 
isn't a bug. But it doesn't make sense to have a function that creates JSON 
fragments and not one that always produces legal JSON that you can safely pass 
to other systems.

It would be great if an option was added to json_encode that forced it to 
produce legal JSON strings, e.g. by wrapping single values in brackets as in the 
examples below.

Test script:
---------------
var_dump(json_encode(1));
var_dump(json_encode(true));
var_dump(json_encode("string"));


Expected result:
----------------
string(3) "[1]"
string(6) "[true]"
string(10) "["string"]"

Actual result:
--------------
string(1) "1"
string(4) "true"
string(8) ""string""

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-06-27 02:07 UTC] aharvey@php.net 
My initial gut feeling is to Won't Fix this: automatically casting a scalar input 
to an array or object is decidedly weird. I guess we could generate a notice to 
note that scalar inputs result in non-RFC output.

At any rate, Crockford himself is ambiguous on the validity of isolated JSON 
primitives. The RFC grammar doesn't permit them, but the text suggests that they 
may be permitted, the json.org grammar chart doesn't express an opinion, the 
reference encoder allows them and encodes and decodes the same way as PHP, and he 
told Joey in an e-mail (after we debated this on IRC a couple of years back and 
Joey e-mailed him) that the RFC was only written to associate the MIME type with 
the format and that "it is not the spec". (Joey can presumably furnish the entire 
details of the exchange; I'm quoting him quoting Crockford.)

In summary, even a simple spec like JSON is a bit of a choose your own adventure. 
I wouldn't be completely against a notice, but I don't think we should change the 
behaviour, both for BC and interoperability reasons.
 [2012-06-27 02:41 UTC] arnfda at gmail dot com 
It is a weird thing to do, but it's necessary in the case of serving JSON to a 
client that won't decode isolated primitives. It could be argued that that's the 
client's problem, but since the spec is ambiguous I'd say it should be given the 
benefit of the doubt. The default behavior of json_encode definitely shouldn't be 
changed, but perhaps another option similar to JSON_FORCE_OBJECT could be added, 
JSON_FORCE_ARRAY maybe?
 [2012-08-05 20:30 UTC] ajf at ajf dot me 
Shouldn't PHP error or warn here? Returning a JSON string with an array 
containing the element, instead of just the element passed, is probably not what 
the user expects.
 [2012-08-06 01:31 UTC] aharvey@php.net
-Status: Open +Status: Wont fix
 [2012-08-06 01:31 UTC] aharvey@php.net 
Having had a month to ruminate on this, and having bounced it off a couple of userland coders since, I'm going to Won't Fix this from a php-src point of view, including the possibility of a notice. Having to silence json_encode() to write E_NOTICE-clean code for a behaviour that many people want and use and that the reference encoder itself exhibits seems like a bad idea.

I will add a note to the json_encode() manual page specifying that output from a scalar input may not be interoperable with every JSON implementation, though.
 [2012-08-06 01:38 UTC] aharvey@php.net 
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=326990
Log: Add a note to json_encode() about the possibility that scalar input may result
in output that some decoders may not like, as promised in request #62422.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Dec 22 06:01:30 2024 UTC