Какой минимальный допустимый JSON?

Я внимательно прочитал описание JSON http://json.org/, но не уверен, что знаю ответ на простой вопрос. Какие строки являются минимально возможным допустимым JSON?

• "string" допустимая строка JSON?
• 42 допустимо ли простое число JSON?
• true логическое значение является допустимым JSON?
• {} пустой объект является допустимым JSON?
• [] пустой массив является допустимым JSON?

На момент написания статьи JSON был описан исключительно в RFC4627 . Он описывает (в начале «2») текст JSON как сериализованный объект или массив.

Это означает, что только {} и []являются действительными, полные строки JSON в синтаксических анализаторах и строковых преобразователях, которые соответствуют этому стандарту.

Однако , введение ECMA-404 меняет это, и обновленный совет можно прочитать здесь . Я также написал сообщение в блоге по проблеме.

Однако, чтобы еще больше запутать этот вопрос, JSONобъект (например, JSON.parse()и JSON.stringify()), доступный в веб-браузерах, ситуацию , стандартизирован в ES5 , и это четко определяет приемлемые тексты JSON, например, так:

Формат обмена JSON, используемый в этой спецификации, в точности соответствует RFC 4627 с двумя исключениями:

• JSONText верхнего уровня для грамматики JSON ECMAScript может состоять из любого JSONValue, а не быть JSONObject или JSONArray, как указано в RFC 4627.

• пропущено

Это будет означать, что все значения JSON (включая строки, нули и числа) принимаются объектом JSON, даже если объект JSON технически соответствует RFC 4627.

Обратите внимание, что вы могли бы поэтому преобразовать число в соответствующий браузер через JSON.stringify(5), который был бы отклонен другим синтаксическим анализатором, который соответствует RFC4627, но у которого нет определенного исключения, перечисленного выше. Например, может показаться , что Ruby является одним из таких примеров, который принимает в качестве корневого объекта только объекты и массивы . PHP, с другой стороны, специально добавляет исключение, что «он также будет кодировать и декодировать скалярные типы и NULL».

В Интернете есть как минимум четыре документа, которые можно считать стандартами JSON. RFCs, на которые все ссылаются, описывают тип пантомимы application/json. Вот что каждый должен сказать о значениях верхнего уровня и о том, разрешено ли что-либо кроме объекта или массива наверху:

RFC-4627 : Нет.

Текст JSON - это последовательность токенов. Набор токенов включает шесть структурных символов, строки, числа и три литеральных имени.

Текст JSON - это сериализованный объект или массив.

JSON-текст = объект / массив

Обратите внимание, что RFC-4627 был помечен как «информационный», а не «предлагаемый стандарт», и что он устарел в RFC-7159 , который, в свою очередь, устарел в RFC-8259.

RFC-8259 : да.

Текст JSON - это последовательность токенов. Набор токенов включает шесть структурных символов, строки, числа и три литеральных имени.

Текст JSON является сериализованным значением. Обратите внимание, что некоторые предыдущие спецификации JSON ограничивали текст JSON объектом или массивом. Реализации, которые генерируют только те объекты или массивы, для которых требуется текст JSON, будут совместимы в том смысле, что все реализации примут их как соответствующие тексты JSON.

JSON-текст = значение ws ws

RFC-8259 датирован декабрем 2017 года и имеет пометку «ИНТЕРНЕТ СТАНДАРТ».

ECMA-262 : да.

Синтаксическая грамматика JSON определяет допустимый текст JSON в терминах токенов, определенных лексической грамматикой JSON. Целью грамматики является JSONText.

Синтаксис JSONText:

JSONValue

JSONValue:

JSONNullLiteral

JSONBooleanLiteral

JSONObject

JSONArray

JSONString

JSONNumber

ECMA-404 : да.

Текст JSON - это последовательность токенов, сформированная из кодовых точек Unicode, которая соответствует грамматике значений JSON. Набор токенов включает в себя шесть структурных токенов, строки, числа и три токена буквальных имен.

Согласно старому определению в RFC 4627 (которое было отменено в марте 2014 года RFC 7159), все они были действительными «значениями JSON», но только последние два составляли полный «текст JSON»:

Текст JSON - это сериализованный объект или массив.

В зависимости от используемого парсера, одиночные «значения JSON» могут быть приняты в любом случае. Например (придерживаясь терминологии «значение JSON» и «текст JSON»):

• JSON.parse()функция в настоящее время стандартизировано в современных браузерах принимает любое «JSON значение»
• функция PHP json_decodeбыла введена в версии 5.2.0, принимающей только весь «текст JSON», но была исправлена, чтобы принимать любое «значение JSON» в версии 5.2.1
• Python's json.loadsпринимает любое «значение JSON» в соответствии с примерами на этой странице руководства
• валидатор на http://jsonlint.com ожидает полный «текст JSON»
• модуль Ruby JSON будет принимать только полный текст JSON (по крайней мере, согласно комментариям на этой странице руководства )

Различие немного похоже на различие между «XML-документом» и «XML-фрагментом», хотя технически <foo />это правильно сформированный XML-документ (лучше было бы записать его <?xml version="1.0" ?><foo />, но, как указано в комментариях, <?xmlобъявление технически необязательно ).

Спецификация ecma может быть полезна для справки:

http://www.ecma-international.org/ecma-262/5.1/

Функция анализа анализирует текст JSON (строка в формате JSON) и создает значение ECMAScript. Формат JSON является ограниченной формой литерала ECMAScript. Объекты JSON реализованы как объекты ECMAScript. Массивы JSON реализованы как массивы ECMAScript. Строки JSON, числа, логические значения и значения NULL реализуются как строки ECMAScript, числа, логические значения и значения NULL. JSON использует более ограниченный набор символов пробела, чем WhiteSpace, и позволяет кодовым точкам Unicode U + 2028 и U + 2029 напрямую появляться в литералах JSONString без использования escape-последовательности. Процесс синтаксического анализа аналогичен 11.1.4 и 11.1.5 и ограничен грамматикой JSON.

JSON.parse("string"); // SyntaxError: Unexpected token s
JSON.parse(43); // 43
JSON.parse("43"); // 43
JSON.parse(true); // true
JSON.parse("true"); // true
JSON.parse(false);
JSON.parse("false");
JSON.parse("trueee"); // SyntaxError: Unexpected token e
JSON.parse("{}"); // {}
JSON.parse("[]"); // []

JSON означает JavaScript Object Notation. Только {}и []определите объект Javascript. Другие примеры являются литералами значений. В Javascript есть типы объектов для работы с этими значениями, но выражение "string"представляет собой представление исходного кода буквального значения, а не объекта.

Имейте в виду, что JSON не является Javascript. Это нотация, которая представляет данные. Он имеет очень простую и ограниченную структуру. Данные JSON структурированы с использованием {},:[]символов. Вы можете использовать только литеральные значения внутри этой структуры.

Для сервера вполне допустимо отвечать либо описанием объекта, либо литеральным значением. Все парсеры JSON должны обрабатываться только для обработки буквального значения, но только для одного значения. JSON может представлять только один объект одновременно. Таким образом, чтобы сервер возвращал более одного значения, он должен был бы структурировать его как объект или массив.

Да, да, да, да и да. Все они являются допустимыми литералами значения JSON.

Однако официальный RFC 4627 гласит:

Текст JSON - это сериализованный объект или массив.

Таким образом, весь «файл» должен состоять из объекта или массива в качестве внешней структуры, которая, конечно, может быть пустой. Тем не менее, многие анализаторы JSON также принимают примитивные значения для ввода.

var x;
JSON.stringify(x); // will output "{}"

Таким образом, ваш ответ, "{}"который обозначает пустой объект.

Просто следуйте железнодорожным схемам, приведенным на странице json.org . [] и {} - минимально возможные допустимые объекты JSON. Таким образом, ответ [] и {}.