JSON не включает Infinity и NaN; Статус JSON в ECMAScript?

Infinity и NaN не являются ключевыми словами или чем-то особенным, это просто свойства глобального объекта (как и undefined), и поэтому их можно изменить. Именно по этой причине JSON не включает их в спецификацию — по сути, любая истинная строка JSON должна иметь тот же результат в EcmaScript, если вы делаете eval(jsonString) или JSON.parse(jsonString).

Если бы это было разрешено, кто-то мог бы ввести код, похожий на

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

в форум (или что-то еще), и тогда любое использование json на этом сайте может быть скомпрометировано.

По исходному вопросу: я согласен с пользователем «cbare» в том, что это досадное упущение в JSON. IEEE754 определяет их как три специальных значения числа с плавающей запятой. Таким образом, JSON не может полностью представлять числа с плавающей запятой IEEE754. На самом деле это еще хуже, поскольку JSON, как определено в ECMA262 5.1, даже не определяет, основаны ли его числа на IEEE754. Поскольку процесс разработки, описанный для функции stringify() в ECMA262, действительно упоминает три специальных значения IEEE, можно предположить, что на самом деле целью была поддержка чисел с плавающей запятой IEEE754.

В качестве еще одной точки данных, не связанной с вопросом: типы данных XML xs:float и xs:double действительно заявляют, что они основаны на числах с плавающей запятой IEEE754, и они поддерживают представление этих трех специальных значений (см. W3C XSD 1.0, часть 2). , Типы данных).

Не могли бы вы адаптировать шаблон нулевого объекта и в своем JSON представить такие значения, как

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

Затем при проверке вы можете проверить тип

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

Я знаю, что в Java вы можете переопределить методы сериализации, чтобы реализовать такую ​​​​вещь. Не уверен, откуда вы сериализуете, поэтому я не могу подробно рассказать, как это реализовать в методах сериализации.

Строки «Infinity», «-Infinity» и «NaN» приводятся к ожидаемым значениям в JS. Поэтому я бы сказал, что правильный способ представления этих значений в JSON — это строки.

> +"Infinity"
Infinity

> +"-Infinity"
-Infinity

> +"NaN"
NaN

Жаль, что JSON.stringify не делает этого по умолчанию. Но есть способ:

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

Если у вас есть доступ к коду сериализации, вы можете представить Infinity как 1.0e+1024. Показатель степени слишком велик, чтобы представлять его в виде двойного числа, и при десериализации это представляется как бесконечность. Работает на webkit, не уверен насчет других парсеров json!

Причина указана на странице ii в Стандарт ECMA-404 Синтаксис обмена данными JSON, 1-е издание

JSON не зависит от чисел. В любом языке программирования может быть множество типов чисел различной разрядности и дополнений, фиксированных или с плавающей запятой, двоичных или десятичных. Это может затруднить обмен между разными языками программирования. Вместо этого JSON предлагает только представление чисел, которое используют люди: последовательность цифр. Все языки программирования умеют понимать последовательности цифр, даже если они расходятся во внутренних представлениях. Этого достаточно для обмена.

Причина не в представлениях NaN и Infinity сценария ECMA, как утверждают многие. Простота — основной принцип проектирования JSON.

Поскольку это так просто, не ожидается, что грамматика JSON когда-либо изменится. Это дает JSON, как основополагающей нотации, потрясающую стабильность.

Возможный обходной путь для таких случаев, как {"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;
   });

Общая идея состоит в том, чтобы заменить вхождения недопустимых значений строкой, которую мы распознаем при анализе, и заменить ее соответствующим представлением JavaScript.

JSON5 допускает стандартную нотацию Javascript для положительной и отрицательной бесконечности, NaN и многих других вещей, которые являются действительными ECMAScript, которые были исключены из JSON (конечные запятые и т. д.).

https://json5.org/

Это делает JSON гораздо более полезным форматом.

Однако, независимо от того, используете ли вы JSON или JSON5: из соображений безопасности всегда всегда анализируйте -- не оценивайте!!

Текущий IEEE Std 754-2008 включает определения для двух различных 64-битных представлений с плавающей запятой: десятичного 64-битного типа с плавающей запятой и двоичного 64-битного типа с плавающей запятой.

После округления строка .99999990000000006 совпадает с .9999999 в двоичном 64-битном представлении IEEE, но НЕ совпадает с .9999999 в десятичном 64-битном представлении IEEE. В 64-битном IEEE десятичное число с плавающей запятой .99999990000000006 округляется до значения .9999999000000001, которое не совпадает с десятичным значением .9999999.

Поскольку JSON просто обрабатывает числовые значения как числовые строки десятичных цифр, система, которая поддерживает как двоичные, так и десятичные представления с плавающей запятой IEEE (например, IBM Power), не может определить, какое из двух возможных числовых значений IEEE с плавающей запятой является предназначена.

Если, как и я, у вас нет контроля над кодом сериализации, вы можете иметь дело со значениями NaN, заменив их нулевым значением или любым другим значением, например, следующим образом:

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

По сути, .fail будет вызываться, когда исходный анализатор json обнаружит недопустимый токен. Затем используется замена строки для замены недопустимых токенов. В моем случае сериализатор возвращает значения NaN в качестве исключения, поэтому этот метод является лучшим подходом. Если результаты обычно содержат недопустимый токен, вам лучше не использовать $.get, а вместо этого вручную извлекать результат JSON и всегда выполнять замену строки.