JSON pominął Infinity i NaN; Status JSON w ECMAScript?

Masz pojęcie, dlaczego JSON pomijał NaN i +/- Infinity? Stawia JavaScript w dziwnej sytuacji, w której obiekty, które w innym przypadku byłyby możliwe do serializacji, nie są, jeśli zawierają wartości NaN lub +/- nieskończoności.

Wygląda na to, że zostało to odlane w kamieniu: patrz RFC4627 i ECMA-262 (sekcja 24.5.2, JSON.stringify, UWAGA 4, strona 683 ECMA-262 pdf w ostatniej edycji):

Liczby skończone są taktowane jak przez wywołanie ToString(number). NaN i Infinity niezależnie od znaku są reprezentowane jako ciąg null.

Infinityi NaNnie są słowami kluczowymi ani niczym specjalnym, są tylko właściwościami obiektu globalnego (jak jest undefined) i jako takie można je zmienić. Z tego powodu JSON nie włącza ich do specyfikacji - w zasadzie każdy prawdziwy ciąg JSON powinien mieć taki sam wynik w EcmaScript, jeśli to zrobisz eval(jsonString)lub JSON.parse(jsonString).

Gdyby było dozwolone, ktoś mógłby wstrzyknąć kod podobny do

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

na forum (lub cokolwiek innego), a następnie jakiekolwiek użycie JSON w tej witrynie może być zagrożone.

Na pierwotne pytanie: zgadzam się z użytkownikiem „cbare”, ponieważ jest to niefortunne pominięcie w JSON. IEEE754 definiuje je jako trzy specjalne wartości liczby zmiennoprzecinkowej. Zatem JSON nie może w pełni reprezentować liczb zmiennoprzecinkowych IEEE754. W rzeczywistości jest jeszcze gorzej, ponieważ JSON zdefiniowany w ECMA262 5.1 nawet nie określa, czy jego liczby są oparte na IEEE754. Ponieważ przepływ projektowania opisany dla funkcji stringify () w ECMA262 wspomina o trzech specjalnych wartościach IEEE, można podejrzewać, że w rzeczywistości chodziło o obsługę liczb zmiennoprzecinkowych IEEE754.

Jako jeden inny punkt danych niezwiązany z pytaniem: typy danych XML xs: float i xs: double informują, że są oparte na liczbach zmiennoprzecinkowych IEEE754 i obsługują reprezentację tych trzech wartości specjalnych (patrz W3C XSD 1.0 część 2 , Typy danych).

Czy możesz dostosować wzorzec obiektu zerowego, aw swoim JSON reprezentować takie wartości jak

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

Następnie podczas sprawdzania możesz sprawdzić typ

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

Wiem, że w Javie możesz zastąpić metody serializacji, aby zaimplementować coś takiego. Nie jestem pewien, skąd twoja serializacja, więc nie mogę podać szczegółów, jak zaimplementować ją w metodach serializacji.

Ciągi „Infinity”, „-Infinity” i „NaN” wszystkie wymuszają oczekiwane wartości w JS. Więc argumentowałbym, że właściwym sposobem reprezentowania tych wartości w JSON są ciągi znaków.

> +"Infinity"
Infinity

> +"-Infinity"
-Infinity

> +"NaN"
NaN

Szkoda tylko, że JSON.stringify nie robi tego domyślnie. Ale jest sposób:

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

Jeśli masz dostęp do kodu serializacji, możesz reprezentować Infinity jako 1.0e + 1024. Wykładnik jest zbyt duży, aby reprezentować go podwójnie, a po deserializacji jest reprezentowany jako Nieskończoność. Działa na zestawie internetowym, niepewny co do innych parserów json!

Obecny standard IEEE 754-2008 zawiera definicje dwóch różnych 64-bitowych reprezentacji zmiennoprzecinkowych: dziesiętnego 64-bitowego typu zmiennoprzecinkowego i binarnego 64-bitowego typu zmiennoprzecinkowego.

Po zaokrągleniu ciąg znaków .99999990000000006jest taki sam jak .9999999w binarnej reprezentacji 64-bitowej IEEE, ale NIE jest taki sam jak .9999999w reprezentacji dziesiętnej 64-bitowej IEEE. W 64-bitowym .99999990000000006zaokrągleniu dziesiętnym zmiennoprzecinkowym IEEE do wartości, .9999999000000001która nie jest taka sama jak .9999999wartość dziesiętna .

Ponieważ JSON po prostu traktuje wartości liczbowe jako ciągi liczb dziesiętnych, system nie obsługuje zarówno binarnych, jak i dziesiętnych reprezentacji zmiennoprzecinkowych IEEE (takich jak IBM Power), aby określić, która z dwóch możliwych wartości liczbowych zmiennoprzecinkowych IEEE jest zamierzony.

Potencjalne obejście takich przypadków jak {„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;
   });

Ogólną ideą jest zastąpienie wystąpień niepoprawnych wartości ciągiem, który rozpoznamy podczas analizy i zastąpienie go odpowiednią reprezentacją JavaScript.

Przyczynę podano na stronie ii w Standardowej ECMA-404 Składnia wymiany danych JSON, wydanie pierwsze

JSON jest agnostykiem co do liczb. W dowolnym języku programowania może istnieć wiele typów liczb o różnych pojemnościach i uzupełnieniach, stałych lub zmiennych, binarnych lub dziesiętnych. Może to utrudnić wymianę między różnymi językami programowania. Zamiast tego JSON oferuje tylko reprezentację liczb używanych przez ludzi: ciąg cyfr. Wszystkie języki programowania wiedzą, jak zrozumieć sekwencje cyfr, nawet jeśli nie zgadzają się co do wewnętrznych reprezentacji. To wystarczy, aby umożliwić wymianę.

Przyczyna nie jest, jak wielu twierdziło, ze względu na reprezentację NaNi Infinityskrypt ECMA. Prostota jest podstawową zasadą projektowania JSON.

Ponieważ jest to tak proste, nie oczekuje się, że gramatyka JSON kiedykolwiek się zmieni. To daje JSON, jako podstawową notację, ogromną stabilność

Jeśli, podobnie jak ja, nie masz kontroli nad kodem serializacji, możesz poradzić sobie z wartościami NaN, zastępując je wartościami null lub dowolnymi innymi wartościami w ramach hackowania w następujący sposób:

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

Zasadniczo .fail zostanie wywołany, gdy oryginalny parser json wykryje nieprawidłowy token. Następnie zastąpiono ciąg znaków, aby zastąpić nieprawidłowe tokeny. W moim przypadku serializator jest wyjątkiem, aby zwracać wartości NaN, więc ta metoda jest najlepszym podejściem. Jeśli wyniki zwykle zawierają nieprawidłowy token, lepiej byłoby nie używać $ .get, ale zamiast tego ręcznie pobrać wynik JSON i zawsze uruchamiać zamianę łańcucha.