JSON omitió Infinity y NaN; ¿Estado JSON en ECMAScript?

¿Alguna idea de por qué JSON omitió NaN y +/- Infinity? Pone a Javascript en la extraña situación en la que los objetos que de otro modo serían serializables, no lo son, si contienen valores de NaN o +/- infinito.

Parece que esto ha sido moldeado: ver RFC4627 y ECMA-262 (sección 24.5.2, JSON.stringify, NOTA 4, página 683 del PDF de ECMA-262 en la última edición):

Los números finitos se stringifican como llamando ToString(number). NaN e Infinity independientemente del signo se representan como la Cadena null.

Infinityy NaNno son palabras clave ni nada especial, son solo propiedades en el objeto global (tal cual undefined) y, como tal, se pueden cambiar. Es por esa razón que JSON no los incluye en la especificación: en esencia, cualquier cadena JSON verdadera debería tener el mismo resultado en EcmaScript si lo hace eval(jsonString)o no JSON.parse(jsonString).

Si se permitiera, alguien podría inyectar un código similar a

NaN={valueOf:function(){ do evil }};
Infinity={valueOf:function(){ do evil }};

en un foro (o lo que sea) y luego cualquier uso de json en ese sitio podría verse comprometido.

Sobre la pregunta original: estoy de acuerdo con el usuario "cbare" en que esta es una omisión desafortunada en JSON. IEEE754 define estos como tres valores especiales de un número de coma flotante. Por lo tanto, JSON no puede representar completamente los números de coma flotante IEEE754. De hecho, es aún peor, ya que JSON como se define en ECMA262 5.1 ni siquiera define si sus números se basan en IEEE754. Dado que el flujo de diseño descrito para la función stringify () en ECMA262 menciona los tres valores IEEE especiales, se puede sospechar que la intención era de hecho admitir números de punto flotante IEEE754.

Como otro punto de datos, no relacionado con la pregunta: tipos de datos XML xs: float y xs: double afirman que están basados ​​en números de punto flotante IEEE754, y que admiten la representación de estos tres valores especiales (Ver W3C XSD 1.0 Parte 2 , Tipos de datos).

¿Podría adaptar el patrón de objeto nulo y en su JSON representar valores como

"myNum" : {
   "isNaN" :false,
   "isInfinity" :true
}

Luego, al verificar, puede verificar el tipo

if (typeof(myObj.myNum) == 'number') {/* do this */}
else if (myObj.myNum.isNaN) {/* do that*/}
else if (myObj.myNum.isInfinity) {/* Do another thing */}

Sé que en Java puedes anular los métodos de serialización para implementar tal cosa. No estoy seguro de dónde está su serialización, por lo que no puedo dar detalles sobre cómo implementarlo en los métodos de serialización.

Las cadenas "Infinity", "-Infinity" y "NaN" obligan a los valores esperados en JS. Entonces argumentaría que la forma correcta de representar estos valores en JSON es como cadenas.

> +"Infinity"
Infinity

> +"-Infinity"
-Infinity

> +"NaN"
NaN

Es solo una lástima que JSON.stringify no lo haga por defecto. Pero, hay una manera:

> JSON.stringify({ x: Infinity }, function (k,v) { return v === Infinity ? "Infinity" : v; })
"{"x":"Infinity"}"

Si tiene acceso al código de serialización, puede representar Infinity como 1.0e + 1024. El exponente es demasiado grande para representarlo en un doble y, cuando se deserializa, se representa como Infinito. Funciona en webkit, ¡no estoy seguro acerca de otros analizadores json!

El IEEE Std 754-2008 actual incluye definiciones para dos representaciones diferentes de punto flotante de 64 bits: un tipo decimal de punto flotante de 64 bits y un tipo binario de punto flotante de 64 bits.

Después de redondear la cadena .99999990000000006es la misma que .9999999en la representación binaria IEEE de 64 bits, pero NO es la misma que .9999999en la representación decimal IEEE de 64 bits. En IEEE de 64 bits, el punto flotante decimal se .99999990000000006redondea al valor .9999999000000001que no es el mismo que el .9999999valor decimal .

Dado que JSON solo trata los valores numéricos como cadenas numéricas de dígitos decimales, no hay forma de que un sistema que admita representaciones de punto flotante binario y decimal IEEE (como IBM Power) determine cuál de los dos posibles valores de punto flotante numérico IEEE es destinado a.

Posible solución para casos como {"key": Infinity}:

JSON.parse(theString.replace(/":(Infinity|-IsNaN)/g, '":"{{$1}}"'), function(k, v) {
   if (v === '{{Infinity}}') return Infinity;
   else if (v === '{{-Infinity}}') return -Infinity;
   else if (v === '{{NaN}}') return NaN;
   return v;
   });

La idea general es reemplazar las ocurrencias de valores no válidos con una cadena que reconoceremos al analizar y reemplazarla nuevamente con la representación JavaScript adecuada.

El motivo se indica en la página ii del Estándar ECMA-404 La sintaxis de intercambio de datos JSON, primera edición

JSON es agnóstico acerca de los números. En cualquier lenguaje de programación, puede haber una variedad de tipos de números de varias capacidades y complementos, fijos o flotantes, binarios o decimales. Eso puede dificultar el intercambio entre diferentes lenguajes de programación. En cambio, JSON ofrece solo la representación de números que usan los humanos: una secuencia de dígitos. Todos los lenguajes de programación saben cómo dar sentido a las secuencias de dígitos, incluso si no están de acuerdo con las representaciones internas. Eso es suficiente para permitir el intercambio.

La razón no es, como muchos han afirmado, debido a las representaciones de NaNy Infinityla escritura ECMA. La simplicidad es un principio de diseño central de JSON.

Debido a que es tan simple, no se espera que la gramática JSON cambie alguna vez. Esto le da a JSON, como notación fundamental, una tremenda estabilidad

Si, como yo, no tiene control sobre el código de serialización, puede lidiar con los valores de NaN reemplazándolos por nulos o cualquier otro valor como un truco de la siguiente manera:

$.get("file.json", theCallback)
.fail(function(data) {
  theCallback(JSON.parse(data.responseText.replace(/NaN/g,'null'))); 
} );

En esencia, se llamará a .fail cuando el analizador json original detecte un token no válido. Luego se usa un reemplazo de cadena para reemplazar los tokens no válidos. En mi caso, es una excepción que el serializador devuelva valores de NaN, por lo que este método es el mejor enfoque. Si los resultados normalmente contienen un token no válido, sería mejor no usar $ .get, sino recuperar manualmente el resultado JSON y ejecutar siempre el reemplazo de la cadena.