52

I'm transferring raw data like [{id: 12000000000002539, Name: "Some Name"}] and I'm getting the object [{id: 12000000000002540, Name: "Some Name"}] after parsing, for now server side converting id into string seems to help. But is there a better way to transfer bigint data correctly?

feipinghuang
  • 1,053
  • 1
  • 9
  • 13
  • 1
    You can't do something like `long long` in C if that is what you are asking. String is probably the better way to go. – Chad Dec 29 '11 at 02:10
  • 5
    This is essentially the same as this question from yesterday: http://stackoverflow.com/q/8641668/615754. JavaScript can represent big numbers, but with only about 15 or 16 digits of precision. – nnnnnn Dec 29 '11 at 02:27
  • http://stackoverflow.com/questions/307179/what-is-javascripts-max-int-whats-the-highest-integer-value-a-number-can-go-t , http://stackoverflow.com/questions/5812096/javascript-large-integer-round-because-precision-why –  Dec 29 '11 at 03:24

1 Answers1

94

The value is actually not exceeding the maximum numeric value in JavaScript (which is "only" 1.7308 or so).

However, the value is exceeding the range of "integral precision". It is not that the wrong number is sent: rather, it is that the literal 12000000000002539 can only be represented as precisely as 12000000000002540, and thus there was never the correct numeric value in JavaScript. (The range of integrals is about +/- 253.)

This is an interesting phenomena of using a double relative-precision (binary64 in IEEE-754 speak) type to store all numeric values, including integers:

12000000000002539 === 12000000000002540 // true

The maximum significant number of decimal digits that be precisely stored as a numeric value is 15 (15.95, really). In the above, there are 17 significant digits, so some of the least-significant information is silently lost. In this case, as the JavaScript parser/engine reads in the literal value.

The only safe way to handle integral numbers of this magnitude in JavaScript is to use a string literal or to break it down in another fashion (e.g. a custom numeric type or a "bigint library"). However, I recommend just using a string, as it is human readable, relatively compact (only two extra characters in JSON), and doesn't require special serialization. Since the value is just an "id" in this case, I hope that math does not need to be performed upon it :)

Happy coding.

  • 9
    It's worth noting that JSON ([RFC 4627](http://www.ietf.org/rfc/rfc4627)) makes no guarantees about what range of numbers JSON consumers are required to be able to represent so the answer may be different for other clients: "An implementation may set limits on the range of numbers." – Mike Samuel Dec 29 '11 at 05:20