4

Possible Duplicate:
Large numbers erroneously rounded in Javascript

I am using jQuery.parseJSON() to take a json string and make it an object. The json string is placed in a script tag by our server with the initial markup. The json string contains values that reference different resources on our website.

There's problem in the implementation of this that was overlooked in development, and is now starting to rear it's head. Our server is java based. Numeric values are for the most part represented as Longs. So the json string will have things like "...'id': 25783071737028608...". This is a problem because this value exceeds the max value for a JS Number type by two whole powers of 10. In this case the number get rounded up: 25783071737028610, which causes all sorts of data inconsistency issues.

This type of pattern is ubiquitous on our website, and the values represent values from our database. I want to avoid doing a massive refactoring of the database. I also want to avoid just passing things to the browser as strings ("...'id': "25783071737028608"..." because finding every instance of a long being passed to javascript, would require a massive refactor of our database.

Is there anyway to represent a Java long type in JavaScript? If no (which I believe to be the case) is there any creative work arounds that you might have used to resolve similar issues?

Community
  • 1
  • 1
aamiri
  • 2,420
  • 4
  • 38
  • 58

3 Answers3

3

As you already mentioned your values exceed maximum integer value in JavaScript, so there's nothing you can really do other than passing your values as strings or writing your own JavaScript JSON parser (or modifying jQuery one) and parse long integer values as strings.

Maksim Vi.
  • 9,107
  • 12
  • 59
  • 85
0

You'll have to encode the number as a string at the server, or else write your own JSON parser in JavaScript to deal with too-big numeric constants.

(There's at least one other question on SO that's almost the same as this.)

edit — sorry I missed the part where you said you couldn't change the encoding. Well the good news is that you should be able to take the JSON2 parser source and modify it, perhaps to interpret all numeric constants as strings, or else ones more than a certain number of digits long.

Oops well the json2.js "parser" is just a sanitizer that ensures calling eval() won't cause a problem. Well still, I think this approach is your only option. If the structure of your JSON expressions is regular and simple enough, you might be able to "fix" them pre-parse with a regex, but if not then a JSON parser in JavaScript is it.

Pointy
  • 405,095
  • 59
  • 585
  • 614
-2

Numbers in JavaScript are double-precision floats, meaning they have around 15 digits of precision. number with more then 15 digits are approximated in the same way that 1/3 is.

Even if you could change it to a string, you wouldn't be able to manipulate the number in any way. I honestly can't think of any reason why you would have ID numbers in the quadrillions...

Niet the Dark Absol
  • 320,036
  • 81
  • 464
  • 592
  • 1
    nothing you said here was helpful. – aamiri Aug 31 '12 at 18:49
  • Well you didn't exactly give much to go on. Why do you have 25-quadrillion as an ID number? Do you really have 25-quadrillion elements to identify? – Niet the Dark Absol Aug 31 '12 at 18:50
  • @Kolink he says they're database keys, so maybe it's some sort of 64-bit encoding of various separate conceptual fields. – Pointy Aug 31 '12 at 18:53
  • @Pointy Double-precision floats are 64 bits long - those numbers are completely beyond the range of 64 bits. – Niet the Dark Absol Aug 31 '12 at 19:03
  • @Kolink It doesn't matter why i have such a huge number. The point is that these values exist and going back and changing all of them is not practical. I was looking for a frontend solution, which i stated in my question. – aamiri Aug 31 '12 at 19:06
  • @Kolink double-precision numbers are 64 bits long, but they're *floating point* - biggest integers they can hold are 53 bits. Java `long` values are 64-bit signed integers. – Pointy Aug 31 '12 at 19:25