JSON class doesn't parse large number properly

[GoogleCodeExporter]

What steps will reproduce the problem?

1. var o:Object = JSON.decode('{"myNumber":123456789123456789}');
2. trace(o.myNumber);

What is the expected output? What do you see instead?

The output should be 123456789123456789, but it is 123456789123456780
instead. Actually it kind of makes sense since the number is beyond the
range of uint. However it would be useful if the parser could:

- Leave the number as a string if it can't parse it
- Or provide an option to parse numbers as strings.

Many web services these days return JSON strings and encode IDs as very
large numbers. We don't actually need to do any calculation on these
numbers so getting them as simple strings would be fine.

What version of the product are you using? On what operating system?

0.90

Original issue reported on code.google.com by laurent1...@gmail.com on 15 Jul 2008 at 11:08

[GoogleCodeExporter]

Original comment by mikechambers on 7 Nov 2008 at 7:25

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

The Number conversion is done by the Flash Player top-level Number() conversion
function.  When the parser reads numerical values in JSON, it builds a string
representing that number which the Flash Player converts then converts into an 
actual
number value.  Since Flash Player is limited to just double, int, and uint, 
there
really aren't a lot of options here for handling "really large" numbers.

If you want to parse the number as a string and leave it as a string, enclose 
it in
quotes:

{"myId":"123456789123456789"}

Original comment by darron.schall on 19 Nov 2008 at 9:13

• Changed state: WontFix
• Added labels: JSON
• Removed labels: ****

[GoogleCodeExporter]

Anyone knows of an alternative json library that could handle that case in a 
more 
graceful way then? When the xml data is coming from third party web services, 
we 
can't control the format, and don't really want go mock with the returned data 
to arbitrarily stringify big numbers....

Original comment by Denis.Am...@gmail.com on 10 Jan 2009 at 1:13

• Added labels: ****
• Removed labels: ****