Hi JSJ,

What version of PHP are you using? I know there was a fix in
json_decode that went into the latest version (at least for 64 bit
version).

There is a thread discussing a similar workaround here:
http://www.sitepoint.com/forums/showthread.php?t=628346

-Chad

On Fri, Aug 21, 2009 at 12:00 PM, JSJ<jimstj...@gmail.com> wrote:
>
> That is helpful to know. So possibly this is isolated to the PHP
> json_decode() functionality.
>
> In my case, I get the following JSON decoded string from twitter
> (happens to be empty result set):
>
> {"results":[],"since_id":3448308315,"max_id":
> 3450048057,"refresh_url":"?
> since_id=3450048057&q=text","results_per_page":10,"completed_in":
> 0.034427,"page":1,"query":"text"}
>
> but following its processing by json_decode the since_id and max_id
> parameters are not decoded properly:
>
> stdClass Object
> (
>   [results] => Array
>        (
>        )
>   [since_id] => -846658981
>   [max_id] => -844919239
>   [refresh_url] => ?since_id=3450048057&q=text
>   [results_per_page] => 10
>   [completed_in] => 0.034427
>   [page] => 1
>   [query] => text
> )
>
>
> My current solution is to force the encoded return string to change as
> follows prior to json_decode:
>
> "since_id":"3448308315","max_id":"3450048057"
>           ^          ^          ^          ^
>
> But this is not a great fix.
>
> JSJ
>
>
>
> On Aug 21, 11:37 am, Cameron Kaiser <spec...@floodgap.com> wrote:
>> > Recently my twitter search API code stopped working properly (using
>> > search.json). After tracking down the issue here is what I think is
>> > going on:
>>
>> > - Recently, the status/message IDs returned by the search API began
>> > exceeding the maximum positive integer allowed on 32-bit OS platforms
>> > (2,147,483,647). For example, in a recent API call I am getting
>> > message IDs such as 3,448,308,315.
>> > - The twitter API returns these within the JSON string using integer
>> > encoding. From PHP, when I decode the return JSON string using
>> > json_decode on 32-bit Windows, I end up with ID values such as
>> > -958,581,221 rather than 3,xxx,xxx,xxx.
>>
>> I think this is PHP's problem. Perl doesn't have it; it sees this tweet
>> as ID 3 451 486 259, not a negative one relative to 2 147 483 647, and this
>> is on a very old Perl to boot. This is the actual dump from TTYtter's
>> internal hash:
>>
>> [{'text','@mom2twinsplus1 you\'re welcome. alas, browser options are thin 
>> for Mac OS 9, which is why we\'re working on 
>> it.','to_user_id',276359,'to_user','mom2twinsplus1','from_user','doctorlinguist','id',3451486259,'from_user_id',2769,
>>
>> As you can see, the ID is handled correctly.
>>
>> --
>> ------------------------------------ personal:http://www.cameronkaiser.com/--
>>   Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com
>> -- If I am not for myself, who will be for me? -- Pirkei Avot 
>> -----------------
>

Reply via email to