# json_encode() - Thread: https://externals.io/message/42266 - Original archive: https://news-web.php.net/php.internals/42266 - Started by Rasmus Lerdorf on 2008-12-15T17:50:11+00:00 - Messages: 27 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/42266.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #42266 — Rasmus Lerdorf — 2008-12-15T17:50:11+00:00 URL: https://externals.io/message/42266#42266 Ok, so as promised I ran some of the options we have that came up last week by Douglas Crockford. 1. Document the fact that if you want to strictly conform to the JSON spec and be sure your json_encode output will work in various JSON parsers, you have to pass it a PHP array or object. 2. Remove support for basic types entirely and throw an error if you pass `json_encode()` something that is not an array or an object. 3. Wrap basic types in an array [] by default and perhaps add an option to `json_encode()` to skip the wrapper. He would prefer option 1. -Rasmus --- ## #42267 — mike — 2008-12-15T18:09:47+00:00 URL: https://externals.io/message/42266#42267 · In reply to: #42266 > 1. Document the fact that if you want to strictly conform to the JSON > spec and be sure your json_encode output will work in various JSON > parsers, you have to pass it a PHP array or object. Instead of json_encode(34) the suggestion would be json_encode(array(34)) ? Seems kind of like a lame thing to require. IMHO the language should "do the right thing" as far as the consumer (javascript/JSON parser) is concerned. However, Douglas is infinitely more educated than I am here. This is just my $0.02 as a PHP user. > 2. Remove support for basic types entirely and throw an error if you > pass `json_encode()` something that is not an array or an object. > > 3. Wrap basic types in an array [] by default and perhaps add an option > to `json_encode()` to skip the wrapper. This sounds like what I had been talking about previously. > He would prefer option 1. I'd be tempted to say #3. However that's probably a code change everyone must make, I would expect that to be in a major release like 6.0. --- ## #42270 — Uwe Schindler — 2008-12-15T20:55:29+00:00 URL: https://externals.io/message/42266#42270 · In reply to: #42266 As is noted in an earlier mail, I would prefer 1 (simply document it in the function description). In my opinion, if somebody then passes a basic type to json_encode he is aware of what he is doing (hopefully). For compatibility with current code and securely escaping strings for javascript it is the best. ----- Uwe Schindler thetaphi@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany > -----Original Message----- > From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com] > Sent: Monday, December 15, 2008 6:50 PM > To: PHP Developers Mailing List > Subject: [PHP-DEV] `json_encode()` > > Ok, so as promised I ran some of the options we have that came up last > week by Douglas Crockford. > > 1. Document the fact that if you want to strictly conform to the JSON > spec and be sure your json_encode output will work in various JSON > parsers, you have to pass it a PHP array or object. > > 2. Remove support for basic types entirely and throw an error if you > pass `json_encode()` something that is not an array or an object. > > 3. Wrap basic types in an array [] by default and perhaps add an option > to `json_encode()` to skip the wrapper. > > He would prefer option 1. > > -Rasmus --- ## #42271 — mike — 2008-12-15T21:02:29+00:00 URL: https://externals.io/message/42266#42271 · In reply to: #42270 > As is noted in an earlier mail, I would prefer 1 (simply document it in the > function description). In my opinion, if somebody then passes a basic type > to json_encode he is aware of what he is doing (hopefully). > > For compatibility with current code and securely escaping strings for > javascript it is the best. PHP 6 will require some recoding for various things. I'd like to see it "do the right thing" in PHP 6, and perhaps if people are using json_encode for escaping, make another function that is there purely for escaping javascript, not serializing/unserializing it for direct exchange with JSON consumption in javascript. After all, this is json_encode, not javascript_escape ... I was unaware that `json_encode()` [improperly] encoded non-arrays/objects, as I expected those details to be worked out in the implementation. While it does produce legitimate javascript it does not produce legitimate JSON, which is the purpose of these functions, no? --- ## #42272 — troels knak-nielsen — 2008-12-15T21:10:02+00:00 URL: https://externals.io/message/42266#42272 · In reply to: #42271 > I'd like to see it "do the right thing" in PHP 6, and perhaps if I think everybody agrees to that. The question at hand, is what the right thing is. I, for one, think that the only sane choices are 1 or 2. The third option is way too magic, and will end up confusing people. -- troels --- ## #42273 — mike — 2008-12-15T21:18:34+00:00 URL: https://externals.io/message/42266#42273 · In reply to: #42272 > I, for one, think that the only sane choices are 1 or 2. The third > option is way too magic, and will end up confusing people. In that case I would have to go for #2. Personally I want to see PHP be as standards-compliant and compatible with everything out there. I don't want non-standard behaviors in PHP to be the things that make it a harder sell when I am pushing it in everything I do. This is a language interoperability issue (more or less) and rather than being lazy and persisting the same behavior, I am trying to push very hard to make it work as JSON consumers expect. --- ## #42274 — John Carter -X johncart - PolicyApp Ltd@Cisco — 2008-12-15T21:43:41+00:00 URL: https://externals.io/message/42266#42274 · In reply to: #42273 How about a strict mode added to the list of the current `json_encode()` options? That way current code will continue to work and anyone reading the docs will know the default behaviour isn't strictly correct. John. John Carter Development Manager NAC Governance Server Cisco johncart@cisco.com +44 161 249 5825 --- ## #42276 — mike — 2008-12-15T22:34:49+00:00 URL: https://externals.io/message/42266#42276 · In reply to: #42274 On Mon, Dec 15, 2008 at 1:43 PM, John Carter -X (johncart - PolicyApp Ltd at Cisco) wrote: > How about a strict mode added to the list of the current `json_encode()` > options? > > That way current code will continue to work and anyone reading the docs > will know the default behaviour isn't strictly correct. I'd rather have a "lazy mode" option, so by default it is spitting out correct JSON (according to specs) --- ## #42277 — Mark Karpeles — 2008-12-16T04:58:34+00:00 URL: https://externals.io/message/42266#42277 · In reply to: #42276 Hi, I believe part of the job should be the programmer's job too. `json_encode()` is way too useful to pass things to javascript (the other way around is not that easy, but I have a function called "JSparse" which work nicely with .toSource() output, and an implementation of .toSource() for MSIE, I was doing json with that even before json existed). I'm in favour of #1. Lazy mode is "not that good", as it's going to break things anyway by silently doing magic stuff the final developer didn't expect because it didn't happen in previous versions. Mark Le lundi 15 décembre 2008 à 14:34 -0800, mike a écrit : > On Mon, Dec 15, 2008 at 1:43 PM, John Carter -X (johncart - PolicyApp > Ltd at Cisco) wrote: > > […] > > I'd rather have a "lazy mode" option, so by default it is spitting out > correct JSON (according to specs) --- ## #42278 — mike — 2008-12-16T05:36:59+00:00 URL: https://externals.io/message/42266#42278 · In reply to: #42277 > I believe part of the job should be the programmer's job too. I'm a programmer. I expect json_* functions to encode and decode to JSON specifications. Not PHP's original interpretation of it... > Lazy mode is "not that good", as it's going to break things anyway by > silently doing magic stuff the final developer didn't expect because it > didn't happen in previous versions. Okay, well PHP 6's behavior is going to change certain things already. Hence why I would recommend the change to be in a major version (6.x) But in the meantime, we're going to be stuck using a construct that works but does not work to actual specification and we're just going to "stick with it" because it will be a change? PHP does "magic" already on a variety of things behind the scenes, there should be no reason why this is any different. --- ## #42279 — Stan Vassilev | FM — 2008-12-16T06:34:13+00:00 URL: https://externals.io/message/42266#42279 · In reply to: #42278 Hi, JSON allows extensions. I can not understand why this is not an extension that makes sense: json_encode($var, $allowScalar = false); In PHP outputting of JS literals is a common action, so all you'll achieve by completely removing this option, is forcing people to go from this: echo 'var foo = '.json_encode("hello world"); ...to this: echo 'var foo = '.substr(json_encode(array("hi world")), 1, -1); A flag that defaults to false would be just as explicit and educational, and more efficient, than forcing hacks on us like the above one. Regards, Stan Vassilev --- ## #42284 — Richard Quadling — 2008-12-16T11:48:33+00:00 URL: https://externals.io/message/42266#42284 · In reply to: #42267 2008/12/15 mike : > > > > […] > > Instead of json_encode(34) the suggestion would be > json_encode(array(34)) ? Seems kind of like a lame thing to require. > IMHO the language should "do the right thing" as far as the consumer > (javascript/JSON parser) is concerned. However, Douglas is infinitely > more educated than I am here. This is just my $0.02 as a PHP user. I was one of those that read the PHP dox and not the RFC/standard (http://bugs.php.net/bug.php?id=38680). I would say that having PHP "correct" my mistake is wrong. If I say... json_encode(34); I am saying that I expect the result to be ... var i_SomeInt = 34; And from there I would expect to be able to say ... var i_SomeOtherInt = i_SomeInt + 10; This is not going to work if PHP "corrects" my mistake. I'd be perfectly happy for the standard to be enforced and an `E_STRICT` warning to be raised. If I want to shoot myself then I have to at least take the safety off first - turning off `E_STRICT` that is. Essentially, I don't like computers guessing my intent. If I don't state it clearly enough then it may be that I don't know what I'm doing. GIMGO (Garbage In, Maybe Garbage Out) isn't a good way to go. Richard. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #42285 — Scott MacVicar — 2008-12-16T11:57:50+00:00 URL: https://externals.io/message/42266#42285 · In reply to: #42284 Richard Quadling wrote: > 2008/12/15 mike : > > […] > > I was one of those that read the PHP dox and not the RFC/standard > (http://bugs.php.net/bug.php?id=38680). > > I would say that having PHP "correct" my mistake is wrong. > > If I say... > > json_encode(34); > > I am saying that I expect the result to be ... > > var i_SomeInt = 34; > > And from there I would expect to be able to say ... > > var i_SomeOtherInt = i_SomeInt + 10; > > This is not going to work if PHP "corrects" my mistake. > > I'd be perfectly happy for the standard to be enforced and an `E_STRICT` > warning to be raised. > > If I want to shoot myself then I have to at least take the safety off > first - turning off `E_STRICT` that is. > > Essentially, I don't like computers guessing my intent. If I don't > state it clearly enough then it may be that I don't know what I'm > doing. > > GIMGO (Garbage In, Maybe Garbage Out) isn't a good way to go. > json_encode is NOT javascript encode, you're already shooting yourself by miusing the function. The problem I'm talking about here is when native browser functions are used to decode the JSON. var json_resonse = ; var myfoo = JSON.parse(json_resonse); The result here is an exception thrown by the browser, if you try and use JSON to speak to perl, python or ruby you get a similar error. The same applies for the various frameworks out there too. For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE parameter to the options flag. So you can use json_encode($var, JSON_STRICT_ENCODE); Scott --- ## #42286 — troels knak-nielsen — 2008-12-16T12:20:57+00:00 URL: https://externals.io/message/42266#42286 · In reply to: #42285 > For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE > parameter to the options flag. So you can use > > json_encode($var, JSON_STRICT_ENCODE); > I'm really not a fan of named constants to change the semantics of a function like that. Not to mention that it's a pita to type out, so nobody would bother. It also doesn't address the crux of the matter - That the name json_encode is slightly misleading, in that it may or may not emit json. Would it be a problem to introduce a second function (js_encode?) instead? It could work as json_encode does today, and json_encode could then be changed to raise a warning on illegal input. I realise that this means breaking existing scripts, but it's a trivial change, and if it's announced in advance, people should have time to make that sed -r '/json_encode/js_encode/g' to their code base. -- troels --- ## #42287 — Scott MacVicar — 2008-12-16T12:23:18+00:00 URL: https://externals.io/message/42266#42287 · In reply to: #42286 troels knak-nielsen wrote: > > > […] > > I'm really not a fan of named constants to change the semantics of a > function like that. Not to mention that it's a pita to type out, so > nobody would bother. It also doesn't address the crux of the matter - > That the name json_encode is slightly misleading, in that it may or > may not emit json. > > Would it be a problem to introduce a second function (js_encode?) > instead? It could work as json_encode does today, and json_encode > could then be changed to raise a warning on illegal input. I realise > that this means breaking existing scripts, but it's a trivial change, > and if it's announced in advance, people should have time to make that > sed -r '/json_encode/js_encode/g' to their code base. > We already have PHP_JSON_HEX_QUOT, PHP_JSON_HEX_TAG, PHP_JSON_HEX_AMP and PHP_JSON_HEX_APOS as options for json_encode, this would just be adding another bitmask. In the future if need be we can make it the default value so it raises a warning. I have no interest in doing a js_encode functions as it opens us up to implementing a lot more functionality. The appealing this about json is that its a subset of JavaScript. Scott --- ## #42288 — Alexey Zakhlestin — 2008-12-16T12:23:37+00:00 URL: https://externals.io/message/42266#42288 · In reply to: #42286 > > > […] > > I'm really not a fan of named constants to change the semantics of a > function like that. Not to mention that it's a pita to type out, so > nobody would bother. It also doesn't address the crux of the matter - > That the name json_encode is slightly misleading, in that it may or > may not emit json. > > Would it be a problem to introduce a second function (js_encode?) > instead? It could work as json_encode does today, and json_encode > could then be changed to raise a warning on illegal input. I realise > that this means breaking existing scripts, but it's a trivial change, > and if it's announced in advance, people should have time to make that > sed -r '/json_encode/js_encode/g' to their code base. sounds like a proper way to me -- Alexey Zakhlestin http://www.milkfarmsoft.com/ --- ## #42289 — Ionut Gabriel Stan — 2008-12-16T12:29:27+00:00 URL: https://externals.io/message/42266#42289 · In reply to: #42288 > > > […] > > sounds like a proper way to me > Me too, but I rather name the function js_escape instead of js_encode. --- ## #42290 — Richard Quadling — 2008-12-16T14:06:44+00:00 URL: https://externals.io/message/42266#42290 · In reply to: #42285 2008/12/16 Scott MacVicar : > Richard Quadling wrote: > > […] > > json_encode is NOT javascript encode, you're already shooting yourself > by miusing the function. The problem I'm talking about here is when > native browser functions are used to decode the JSON. > > var json_resonse = ; > var myfoo = JSON.parse(json_resonse); > > The result here is an exception thrown by the browser, if you try and > use JSON to speak to perl, python or ruby you get a similar error. The > same applies for the various frameworks out there too. When I say "expect", it was because the PHP documentation said I could. I like the option to either have strict encoding as standard or as an option I can activate myself. Either way, I want to be told if I've done it wrong. > For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE > parameter to the options flag. So you can use > > json_encode($var, JSON_STRICT_ENCODE); +1 Would it be at all possible to have an ini setting json.strict_encode = On So, my code doesn't change, but I can activate it globally. Essentially I don't want to shoot myself. I don't want to take the safety off. > > Scott > -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #42291 — troels knak-nielsen — 2008-12-16T14:55:55+00:00 URL: https://externals.io/message/42266#42291 · In reply to: #42290 On Tue, Dec 16, 2008 at 3:06 PM, Richard Quadling wrote: > Would it be at all possible to have an ini setting json.strict_encode = On > > So, my code doesn't change, but I can activate it globally. > Essentially I don't want to shoot myself. I don't want to take the > safety off. I think we have lots of prior examples of why it's a bad idea to change language semantics with a global setting. -- troels --- ## #42292 — Robin Burchell — 2008-12-16T15:07:15+00:00 URL: https://externals.io/message/42266#42292 · In reply to: #42290 Settings which change behaviour like that aren't really all that fun for third party/portable applications developers, e.g. forum software and the likes. magic_quotes_gpc and others are good examples of this. Going back to Rasmus' mail based on his discussion with Douglas, I think that option #1 (documenting the way it works, and documenting how to do things "properly") sounds perfectly fine. On Tue, Dec 16, 2008 at 2:06 PM, Richard Quadling wrote: > 2008/12/16 Scott MacVicar : > > […] > > When I say "expect", it was because the PHP documentation said I could. > > I like the option to either have strict encoding as standard or as an > option I can activate myself. Either way, I want to be told if I've > done it wrong. > > > […] > > +1 > > Would it be at all possible to have an ini setting json.strict_encode = On > > So, my code doesn't change, but I can activate it globally. > Essentially I don't want to shoot myself. I don't want to take the > safety off. > > […] > > > > -- > ----- > Richard Quadling > Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 > "Standing on the shoulders of some very clever giants!" --- ## #42293 — Pierre Joye — 2008-12-16T15:21:07+00:00 URL: https://externals.io/message/42266#42293 · In reply to: #42266 > Ok, so as promised I ran some of the options we have that came up last > week by Douglas Crockford. > > 1. Document the fact that if you want to strictly conform to the JSON > spec and be sure your json_encode output will work in various JSON > parsers, you have to pass it a PHP array or object. +1 Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #42294 — Stan Vassilev | FM — 2008-12-16T15:38:01+00:00 URL: https://externals.io/message/42266#42294 · In reply to: #42293 > > […] > +1 Regards, Stan Vassilev --- ## #42295 — Karsten Dambekalns — 2008-12-16T16:14:08+00:00 URL: https://externals.io/message/42266#42295 · In reply to: #42266 Hi. > Ok, so as promised I ran some of the options we have that came up last > week by Douglas Crockford. > > 1. Document the fact that if you want to strictly conform to the JSON > spec and be sure your json_encode output will work in various JSON > parsers, you have to pass it a PHP array or object. +1 Karsten Dambekalns --- ## #42296 — Ilia Alshanetsky — 2008-12-16T16:37:31+00:00 URL: https://externals.io/message/42266#42296 · In reply to: #42285 The proposed solution (basic types flag) is probably the lesser evil, but I still feel were are taking things to far and current operation is correct. > Richard Quadling wrote: > > […] > > json_encode is NOT javascript encode, you're already shooting yourself > by miusing the function. The problem I'm talking about here is when > native browser functions are used to decode the JSON. > > var json_resonse = ; > var myfoo = JSON.parse(json_resonse); > > The result here is an exception thrown by the browser, if you try and > use JSON to speak to perl, python or ruby you get a similar error. The > same applies for the various frameworks out there too. > > For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE > parameter to the options flag. So you can use > > json_encode($var, JSON_STRICT_ENCODE); > > Scott > > -- > > > Ilia Alshanetsky --- ## #42297 — Richard Quadling — 2008-12-17T10:05:18+00:00 URL: https://externals.io/message/42266#42297 · In reply to: #42292 2008/12/16 Robin Burchell : > Settings which change behaviour like that aren't really all that fun > for third party/portable applications developers, e.g. forum software > and the likes. magic_quotes_gpc and others are good examples of this. > > Going back to Rasmus' mail based on his discussion with Douglas, I > think that option #1 (documenting the way it works, and documenting > how to do things "properly") sounds perfectly fine. Ok, I see. Add the optional param to the function and have a one-off hit to the userland codebase to fix the problem. So is this going to be 5.3 or 6.0? Would you expect `json_decode()` to have the param as well. Considering `json_encode()` COULD encode non JSON compliant data, should `json_decode()` also decode non JSON compliant data? Richard. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- Next page: https://externals.io/message/42266.md?page=2