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

Есть идеи, почему JSON не учел NaN и +/- Infinity? Это ставит Javascript в странную ситуацию, когда объекты, которые в противном случае были бы сериализуемыми, отсутствуют, если они содержат значения NaN или +/- бесконечность.

Похоже, что это было отлито из камня: см. RFC4627 и ECMA-262 (раздел 24.5.2, JSON.stringify, ПРИМЕЧАНИЕ 4, стр. 683 из документа ECMA-262 pdf при последнем редактировании):

Конечные числа выстраиваются как будто по телефону ToString(number). NaN и Бесконечность независимо от знака представлены в виде строки null.

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 do заявляют, что они основаны на числах с плавающей запятой IEEE754, и они поддерживают представление этих трех специальных значений (см. W3C XSD 1.0 Part 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!

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

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

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

Потенциальный обходной путь для таких случаев, как {"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.

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

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

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

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

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

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

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