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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

  • пропущено

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

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

Ответ 2

Существует не менее четырех документов (rfc-7159 считается продолжением rfc-7158), которые могут считаться стандартами JSON в Интернете. Первые три RFC описывают тип mime application/json. Вот что каждый должен сказать о значениях верхнего уровня:

RFC-4627: Нет

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

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

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

Обратите внимание, что RFC-4627 был отмечен как "информационный", а не "предложенный стандарт", и что он устарел RFC-7158 и RFC-7159.

RFC-7158: Да. (от rev. bis-08)

(См. RFC-7159, который в настоящее время идентичен.)

RFC-7159: Да.

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

JSON-text = ws value ws

Обратите внимание, что RFC-7159 существует просто потому, что дата публикации RFC-7158 была ошибочно опубликована как "Март 2013", когда она была обновлена ​​в марте 2014 года (source).

ECMA-262: Да.

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

Синтаксис   JSONText:

JSONValue

JSONValue:

JSONNullLiteral

     

JSONBooleanLiteral

     

JSONObject

     

JSONArray

     

JSONString

     

JSONNumber

ECMA-404: Да.

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Функция parse анализирует текст JSON (строка в формате JSON) и выдает значение ECMAScript. Формат JSON является ограниченной формой литерала ECMAScript. Объекты JSON реализуются как объекты ECMAScript. Массивы JSON реализуются как массивы ECMAScript. Строки JSON, числа, булевы и нули реализуются как Строки ECMAScript, Numbers, Booleans и 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("[]"); // []

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

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