ZF-504: Json encdoing bug for php objects (plus improvements needed in decoding)

Issue Type: Bug Created: 2006-11-08T04:37:34.000+0000 Last Updated: 2007-07-05T14:43:25.000+0000 Status: Resolved Fix version(s): - 0.6.0 (16/Dec/06)

Reporter: Gaetano Giunta (ggiunta) Assignee: Matthew Weier O'Phinney (matthew) Tags: - Zend_Json

Related issues: Attachments:



1 - when encoding a php object as json 'struct', an extra field 'classname' is added, but one field of the existing object is discarded

2 - empty php arrays get encoded as json structs, whereas all other php json libs encode them as json arrays


1 - json number in the form 010 are interpreted as decimal 10. They should either be unsupported or treated as octal

2 - newline chars inside strings are accepted. The ECMA specs says they are forbidden. Maybe making the parser stricter would be an improvement?

3 - parsing of arrays happily accepts borked stuff such as [a"], ["a], [][] (two arrays one after another in a single json string), {"a":}. Surely making parser stricter would be an improvement


Posted by Bill Karwin (bkarwin) on 2006-11-08T12:13:07.000+0000

Assigning to Matthew.

Posted by Bill Karwin (bkarwin) on 2006-11-28T17:55:45.000+0000

Scheduling for release 0.7.0.

Posted by Matthew Weier O'Phinney (matthew) on 2006-12-07T16:00:55.000+0000

I cannot reproduce your first encoding issue; my tests are showing all properties encoded for an object. The second encoding issue I can fix with a quick check for an empty() array.

I agree with your first decoding issue, and will put in a fix for it. As for the second, regarding newline characters, says they are valid JSON notation.

As for your last decoding point, I need to do some tests to see that this is the case. What should it do in this situation? Throw an exception?

Posted by Matthew Weier O'Phinney (matthew) on 2006-12-08T12:57:44.000+0000

The final decoding issue you bring up actually results in an Illegal Token exception being thrown by Zend_Json_Decoder already.

Posted by Matthew Weier O'Phinney (matthew) on 2006-12-08T13:25:51.000+0000

Encoding issue 2 (empty array encoding) fixed. Decoding issue with 'borked' input -- unable to verify, but added test case. Decoding issue with octals -- JS octal values now generate an exception, as JSON spec does not allow for octal notation.

All other issues either unverifiable or implementation follows JSON spec properly.

Posted by Gaetano Giunta (ggiunta) on 2006-12-11T03:24:49.000+0000

"As for the second, regarding newline characters, says they are valid JSON notation"

Sort of, but it also states that "It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999", which clearly forbids them (par. 7.3)

Imho, whether ecma or json takes precedence is dictated by 'strictness', ie the intersection of the two specs is the best thing to adehre to (the same guiding principle is very useful when writing xmlrpc code: the spec is very brief, but it clearly mentions xml and http conformance).

We could of course discuss this further on the json mailing list, but I see no major drawback in allowing in input a bit more than the spec says.

As for the unverifiable issues, I tested on php 516 windows with the json dll gotten from pecl4win. I see there is no dll available for version 52 yet, so I guess I'll have to test on unix...

Posted by Matthew Weier O'Phinney (matthew) on 2006-12-11T10:02:32.000+0000

Run the tests from the most recent SVN revisions, as these bypass ext/json in order to simply test the Zend_Json implementation (Zend_Json::encode() and ::decode() will actually use ext/json instead of the Zend_Json encoder and decoder implementations if ext/json is installed). I can only fix/verify behaviours in Zend_Json, not in ext/json.

Posted by Gavin (gavin) on 2007-02-26T16:37:14.000+0000

Changed "Affects Versions" to the correct version (the bug affected ZF 0.2) and was fixed in ZF 0.6.

Posted by Gaetano Giunta (ggiunta) on 2007-04-20T16:49:05.000+0000

About issue 1: + object fields discarded have nothing to do with the extra 'classname', but it is simply all fileds with a NULL value... + the 'classname' trick, while nice, is not really consistent with the new capabilty of using php-json to do the ecoding. As of now, using zend to encode a php object will have different results depending on wheter php-json is enabled or not...

Have you found an issue?

See the Overview section for more details.


© 2006-2020 by Zend by Perforce. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.