Any idea why JSON left out NaN and +/- Infinity? It puts Javascript in the strange situation where objects that would otherwise be serializable, are not, if they contain NaN or +/- infinity values.
Looks like this has been cast in stone: see RFC4627 and ECMA-262 at the top of p. 197:
Finite numbers are stringified as if by String(number). NaN and Infinity regardless of sign are represented as the string null.
Source: Tips4all
At all "security reason" answerer:
ReplyDeleteSecurity isn't a valid point!
If someone has access to your global code to to something like
NaN={valueOf:function(){ do evil }};
then he could also do things like
JSON.parse = function(){ do evil };
Infinity and NaN aren't keywords or anything special, they are just properties on the global object (as is undefined) and as such can be changed. It's for that reason JSON doesn't include them in the spec -- in essence any true JSON string should have the same result in EcmaScript if you do eval(jsonString) or JSON.parse(jsonString).
ReplyDeleteIf it were allowed then someone could inject code akin to
NaN={valueOf:function(){ do evil }};
Infinity={valueOf:function(){ do evil }};
into a forum (or whatever) and then any json usage on that site could be compromised.
Could you adapt the null object pattern, and in your json represent such values as
ReplyDeletemyNum:{
isNaN:false,
isInfinity:true
}
Then when checking, you can check for the type
if (typeof(myObj.myNum) == 'number') {/* do this */}
else if (myObj.isNaN) {/* do that*/}
else if (myObj.isInfinity) {/* Do another thing */}
I know in Java you can override serialization methods in order to implement such a thing. Not sure where your serializing from, so I can't give details on how to implement it in the serialization methods.
Could it be because JSON is intended to be a data interchange format that can be used in a variety of platforms and allowing NaN/Infinity would make it less portable?
ReplyDeleteOn the original question: I agree with user "cbare" in that this is an unfortunate omission in JSON. IEEE754 defines these as three special values of a floating point number. So JSON cannot fully represent IEEE754 floating point numbers. It is in fact even worse, since JSON as defined in ECMA262 5.1 does not even define whether its numbers are based on IEEE754. Since the design flow described for the stringify() function in ECMA262 does mention the three special IEEE values, one can suspect that the intention was in fact to support IEEE754 floating point numbers.
ReplyDeleteAs one other data point, unrelated to the question: XML datatypes xs:float and xs:double do state that they are based on IEEE754 floating point numbers, and they do support the representation of these three special values (See W3C XSD 1.0 Part 2, Datatypes).
If you have access to the serialization code you might represent Infinity as 1.0e+1024. The exponent is too large to represent in a double and when deserialized this is represented as Infinity. Works on webkit, unsure about other json parsers!
ReplyDelete