Bug #50224 [ReO->Csd]: json_encode() does not always encode a float as a float
| From: | stas@php.net | Date: | Mon, 19 Jan 2015 18:06:37 +0000 |
| Subject: | Bug #50224 [ReO->Csd]: json_encode() does not always encode a float as a float | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-190059@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=50224&edit=1
ID: 50224
Updated by: stas@php.net
Reported by: christian dot lawrence at calorieking dot com
Summary: json_encode() does not always encode a float as a
float
-Status: Re-Opened
+Status: Closed
Type: Bug
Package: JSON related
PHP Version: 5.2SVN-2009-11-19 (snap)
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of jrbasso@gmail.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=ac7cfad3b54b04b7ff2d0e4bfd26e8b61d233613
Log: Fixed bug #50224 where float without decimals were converted to integer
Previous Comments:
------------------------------------------------------------------------
[2014-07-16 02:48:15] jrbasso at gmail dot com
I tested the lib jansson (C) and it also keeps the fraction.
json_t *array, *value;
value = json_real(1.0);
array = json_array();
json_array_insert(array, 0, value);
printf("%s\n", json_dumps(array, 0));
Outputs: [1.0]
I also tested go-lang and it gives integer value:
import "encoding/json"
fltB, _ := json.Marshal(1.0)
fmt.Println(string(fltB))
Output: 1
Javascript returns integer as well:
JSON.stringify(1.0)
Output: 1
Kevin Israel suggested on my pull request to create another flag to json_encode (see https://github.com/php/php-src/pull/642#issuecomment-48993303).
What do you guys think? I can add it to the PR.
------------------------------------------------------------------------
[2014-07-15 11:44:55] tyrael@php.net
I think it would be nice looking into how others handle this issue.
Here is a comparision for the various json modules for python:
http://deron.meranda.us/python/comparing_json_modules/numbers
"Python floating point numbers (float) should be representable as JSON. JSON represents numbers
with decimal fractions, and optional base-10 exponents. A floating-point number with a zero a
fractional part, such as 1.0, could reasonably be converted to the JSON number 1 as well as 1.0;
however no implementations choose to drop the fractional part."
the json ruby gem also seems to keep the fraction:
#!/usr/bin/ruby
require 'json'
require 'pp'
pp JSON.parse(JSON.generate([1.0]))
outputs
[1.0]
I would be curious if there are other widely used json encoder implementations which are dropping
the fraction for the integer numbers.
I think that keeping the fraction all times for floats wouldn't hurt anybody, but it could be
useful for some people, and from my quick test this seems to be the common behavior, so I think we
should follow it too.
------------------------------------------------------------------------
[2014-03-29 23:52:26] jrbasso at gmail dot com
The problem is still present in version 5.5.10.
I opened a PR to resolve it. https://github.com/php/php-src/pull/635
------------------------------------------------------------------------
[2013-07-03 13:42:20] chr dot tatu at gmail dot com
The problem is still present in version 5.4.6.
var_dump says this values is float, but after applying json_encode and json_decode
the value gets to be an int.
For the jsoncpp library there is a difference between int and float and that
difference is acknowledged by the floating point.
------------------------------------------------------------------------
[2012-07-13 23:09:50] josh dot adell at gmail dot com
This is still an issue, specifically when JSON encoding for talking to APIs that
don't allow mixed type arrays.
For instance, json_encode(array(1.2, 2.3)) properly encodes to "[1.2, 2.3]"
But, json_encode(array(1.0, 2.3)) encodes to "[1, 2.3]" which fails if the
receiving end does not allow mixed-type arrays.
Any chance on this ever being fixed?
PHP Version: 5.3.10
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=50224
--
Edit this bug report at https://bugs.php.net/bug.php?id=50224&edit=1