JSON ha lasciato fuori Infinity e NaN; Stato JSON in ECMAScript?

Qualche idea sul perché JSON abbia escluso NaN e +/- Infinity? Mette Javascript nella strana situazione in cui gli oggetti che sarebbero altrimenti serializzabili non lo sono, se contengono valori di NaN o +/- infinito.

Sembra che questo sia stato lanciato in pietra: vedi RFC4627 ed ECMA-262 (sezione 24.5.2, JSON.stringify, NOTA 4, pagina 683 del pdf ECMA-262 all'ultima modifica):

I numeri finiti sono stringiti come se chiamando ToString(number). NaN e Infinity indipendentemente dal segno sono rappresentati come String null.

Infinitye NaNnon sono parole chiave o niente di speciale, sono solo proprietà dell'oggetto globale (così com'è undefined) e come tali possono essere cambiate. È per questo motivo che JSON non li include nelle specifiche - in sostanza qualsiasi stringa JSON vera dovrebbe avere lo stesso risultato in EcmaScript se lo fai eval(jsonString)oJSON.parse(jsonString) .

Se fosse permesso, allora qualcuno potrebbe iniettare un codice simile a

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

in un forum (o qualsiasi altra cosa) e quindi qualsiasi utilizzo json su quel sito potrebbe essere compromesso.

Sulla domanda originale: sono d'accordo con l'utente "cbare" in quanto questa è una sfortunata omissione in JSON. IEEE754 li definisce come tre valori speciali di un numero in virgola mobile. Quindi JSON non può rappresentare completamente i numeri in virgola mobile IEEE754. In realtà è anche peggio, poiché JSON come definito in ECMA262 5.1 non definisce nemmeno se i suoi numeri sono basati su IEEE754. Poiché il flusso di progettazione descritto per la funzione stringify () in ECMA262 menziona i tre valori IEEE speciali, si può sospettare che l'intenzione fosse in realtà quella di supportare i numeri in virgola mobile IEEE754.

Come un altro punto dati, non correlato alla domanda: tipi di dati XML xs: float e xs: double indicano che sono basati su numeri in virgola mobile IEEE754 e supportano la rappresentazione di questi tre valori speciali (Vedi W3C XSD 1.0 Parte 2 , Tipi di dati).

Potresti adattare il modello di oggetti null e nel tuo JSON rappresentare valori come

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

Quindi, durante il controllo, è possibile verificare il tipo

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

So che in Java è possibile ignorare i metodi di serializzazione per implementare una cosa del genere. Non sono sicuro da dove provenga la serializzazione, quindi non posso fornire dettagli su come implementarlo nei metodi di serializzazione.

Le stringhe "Infinity", "-Infinity" e "NaN" vengono forzate tutti ai valori previsti in JS. Quindi direi che il modo giusto di rappresentare questi valori in JSON è come stringhe.

> +"Infinity"
Infinity

> +"-Infinity"
-Infinity

> +"NaN"
NaN

È un peccato che JSON.stringify non lo faccia per impostazione predefinita. Ma c'è un modo:

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

Se si ha accesso al codice di serializzazione, è possibile rappresentare Infinity come 1.0e + 1024. L'esponente è troppo grande per rappresentare in doppio e quando deserializzato viene rappresentato come Infinito. Funziona su webkit, incerto su altri parser json!

L'attuale IEEE Std 754-2008 include definizioni per due diverse rappresentazioni in virgola mobile a 64 bit: un tipo decimale in virgola mobile a 64 bit e un binario in virgola mobile a 64 bit.

Dopo aver arrotondato la stringa .99999990000000006è la stessa .9999999della rappresentazione binaria IEEE a 64 bit ma NON è la stessa .9999999della rappresentazione decimale IEEE a 64 bit. In virgola mobile decimale IEEE a 64 bit.99999990000000006 arrotonda al valore .9999999000000001che non è uguale al decimale.9999999 valore .

Poiché JSON considera i valori numerici solo come stringhe numeriche di cifre decimali, non esiste alcun modo per un sistema che supporti rappresentazioni in virgola mobile e decimali IEEE (come IBM Power) per determinare quale dei due possibili valori in virgola mobile IEEE è previsto.

Potenziale soluzione per casi come {"chiave": Infinito}:

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;
   });

L'idea generale è quella di sostituire le occorrenze di valori non validi con una stringa che riconosceremo durante l'analisi e sostituirla con la rappresentazione JavaScript appropriata.

Il motivo è indicato a pagina ii in Standard ECMA-404 La sintassi di interscambio di dati JSON, 1a edizione

JSON è agnostico riguardo ai numeri. In qualsiasi linguaggio di programmazione, ci possono essere una varietà di tipi numerici di varie capacità e complementi, fissi o mobili, binari o decimali. Ciò può rendere difficile l'interscambio tra diversi linguaggi di programmazione. JSON invece offre solo la rappresentazione di numeri che gli umani usano: una sequenza di cifre. Tutti i linguaggi di programmazione sanno come dare un senso alle sequenze di cifre anche se non sono d'accordo sulle rappresentazioni interne. Questo è sufficiente per consentire l'interscambio.

Il motivo non è, come molti hanno affermato, a causa delle rappresentazioni NaNe della Infinitysceneggiatura dell'ECMA. La semplicità è un principio progettuale fondamentale di JSON.

Poiché è così semplice, non si prevede che la grammatica JSON cambierà mai. Ciò conferisce a JSON, come notazione di base, un'enorme stabilità

Se come me non hai alcun controllo sul codice di serializzazione, puoi gestire i valori NaN sostituendoli con null o qualsiasi altro valore come un po 'di un hack come segue:

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

In sostanza, .fail verrà chiamato quando il parser json originale rileva un token non valido. Quindi viene utilizzata una sostituzione stringa per sostituire i token non validi. Nel mio caso è un'eccezione per il serializzatore restituire valori NaN, quindi questo metodo è l'approccio migliore. Se i risultati normalmente contengono un token non valido, sarebbe meglio non usare $ .get ma invece recuperare manualmente il risultato JSON ed eseguire sempre la sostituzione della stringa.