Question

I have the typical problem with big int decoded with json_decode and try using the JSON_BIGINT_AS_STRING option, but it seems that php ignores the parameter.

I tried the php.net example code:

$json = '12345678901234567890';

var_dump(json_decode($json));
var_dump(json_decode($json, false, 512, JSON_BIGINT_AS_STRING));

The output should be:

float(1.2345678901235E+19)
string(20) "12345678901234567890"

But in my server (xampp php 5.4.7) I have:

float(1.2345678901235E+19)
float(1.2345678901235E+19)

Thanks for the help!

Answer 1

EDIT:

I had to confirm this, but this behavior has been classified as a bug in PHP. Please see the bug report for more details.

The existing behavior causes your string to be cast as int/float (number type) internally by PHP. If you provide a JSON encoded object, array, or string the function does what it describes, but for now this reflects the buggy behavior.

$json = '12345678901234567890';

var_dump(json_decode($json));           /* float(1.2345678901235E+19) */
var_dump(json_decode($json, false, 512, 
         JSON_BIGINT_AS_STRING));       /* float(1.2345678901235E+19) */

As you can see both give us a float, but when we use a valid JSON object, array, or valid JSON as a string we get the expected result.

$jsonStr = '"12345678901234567890"';        // as a string
$jsonArr = '[12345678901234567890]';        // as an array
$jsonObj = '{"num":12345678901234567890}';  // as an object

var_dump(
         json_decode($jsonStr), /* It's JSON_BIGINT_AS_STRING by default in 5.4 */
         json_decode($jsonArr),
         json_decode($jsonArr, false, 512, JSON_BIGINT_AS_STRING),
         json_decode($jsonObj),
         json_decode($jsonObj, false, 512, JSON_BIGINT_AS_STRING)
);

The output looks like the following…

string(20) "12345678901234567890"
array(1) {
  [0]=>
  float(1.2345678901235E+19)
}
array(1) {
  [0]=>
  string(20) "12345678901234567890"
}
object(stdClass)#1 (1) {
  ["num"]=>
  float(1.2345678901235E+19)
}
object(stdClass)#2 (1) {
  ["num"]=>
  string(20) "12345678901234567890"
}

This should be fixed soon, but for now I just wanted to update my answer to reflect this new information.