ZF-4437: Float values containing commas are not encoded correctly
Description
A float value such as 10.3 that is represented by 10,3 in some locales is not encoded correctly. The resulting JSON string will contain an extra comma.
A float value such as 10.3 that is represented by 10,3 in some locales is not encoded correctly. The resulting JSON string will contain an extra comma.
Comments
Posted by Matthew Weier O'Phinney (matthew) on 2008-10-01T06:02:02.000+0000
Please clarify: was this result obtained using Zend_Json::encode(), or Zend_Json_Encoder::encode()? If the former, do you have ex/tjson installed? The reason I ask is that this may be an upstream (PHP) bug.
Posted by Christoph Dorn (cadorn) on 2008-10-02T13:35:22.000+0000
Json extension is instaled and loaded:
json support enabled json version 1.2.1
tested on PHP 5.2.5 and 5.2.6 - same output
And test code:
array(9) { [0]=> int(2) [1]=> float(1,14285714286) [2]=> int(3) [3]=> float(1,42857142857) [4]=> float(1,75) [5]=> float(1,33333333333) [6]=> int(0) [7]=> float(1,28571428571) [8]=> float(0,5) }
json_encode[2,1.14285714286,3,1.42857142857,1.75,1.33333333333,0,1.28571428571,0.5]
ZJE::e[2,1,14285714286,3,1,42857142857,1,75,1,33333333333,0,1,28571428571,0,5]
ZE::e[2,1.14285714286,3,1.42857142857,1.75,1.33333333333,0,1.28571428571,0.5]
Posted by Matthew Weier O'Phinney (matthew) on 2008-11-07T12:12:28.000+0000
I'm a bit loathe to alter Zend_Json_Encoder to have different results than json_encode(). Is there a bug filed on php.net to alter this behavior for ext/json? If so, I think we can make the change and indicate in the manual in what version of PHP it is (will be) fixed.
Posted by Christoph Dorn (cadorn) on 2008-11-07T12:21:12.000+0000
Hmm. Looking at the tests above it looks like json_encode() is working properly and Zend_Json_Encoder is not.
json_encode[2,1.14285714286,3,1.42857142857,1.75,1.33333333333,0,1.28571428571,0.5]
ZJE::e[2,1,14285714286,3,1,42857142857,1,75,1,33333333333,0,1,28571428571,0,5]
Posted by Benjamin Eberlei (beberlei) on 2009-03-20T07:58:00.000+0000
I reproduced this issue and committed a fix in r14400, scheduled for 1.8 release