Edit report at https://bugs.php.net/bug.php?id=62422&edit=1
ID: 62422 Updated by: ahar...@php.net Reported by: arnfda at gmail dot com Summary: Function that always produces legal JSON -Status: Open +Status: Wont fix Type: Feature/Change Request Package: JSON related Operating System: OS X 10.6.8 PHP Version: 5.4.4 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2012-08-05 20:30:45] 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-06-27 02:41:03] 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-06-27 02:07:50] ahar...@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-26 14:58:55] 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"" ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=62422&edit=1
