|In PHP <= 5.1.6 trying to decode an integer value that's > PHP_INT_MAX
will result in an intger of PHP_INT_MAX.

In PHP 5.2+ decoding an integer > PHP_INT_MAX will cause a conversion to
a float.

Neither behaviour is perfect, capping at PHP_INT_MAX is marginally
worse, but the float conversion loses precision.

If you expect to deal with large numbers at all, let alone in JSON,
ensure you're using a 64-bit system.


my thoughts:

if moving to a 64-bit system is not feasible and you aren't interesting
in hacking the (php itself) source (num_as_string json_decode() patch at, you could try xml or writing a
quick-n-dirty twitter-specific decoder.  other alternatives are looking
at a hosting provider or paying someone (ahem) to patch your PHP
instance <plug>(I do Linux only, not BSD or 'doze, but I've been doing
Linux for a long time and I'm pretty good at it)</plug>.


Joseph Cheek,
Dewald Pretorius wrote:
> I've run into a serious issue and I don't know if I am overlooking
> something.
> When retrieving ids with cursoring, and then doing a PHP json_decode
> on the data, the cursor value is converted to an exponentional number
> expression.
> For example:
> yields "next_cursor":1314614526448841129 in the raw JSON data.
> After json_decode the value is converted to 1.31461452645E+18.
> I've tried both json_decode to an object and to an associative array
> and both give the same result.
> As you will notice, even if one were to typecast that number to float,
> there is still 8 digits missing, which would yield an invalid cursor.
> So, am I missing something glaringly obvious, or does someone have a
> solution to this issue?
> Dewald

Reply via email to