JSON

редактировать
Текстовый открытый стандарт, разработанный для удобочитаемого обмена данными
Нотация объектов JavaScript
JSON vector logo.svg
Расширение имени файла .json
Тип интернет-носителя application / json
Код типа ТЕКСТ
Тип форматаОбмен данными
Расширенный отJavaScript
Стандартный STD 90 (RFC 8259 ), ECMA-404, ISO / IEC 21778: 2017
Открытый формат ?Да
Веб-сайтjson.org

Нотация объектов JavaScript (JSON, произносится как ; также ) - это открытый стандартный формат файла и формат обмена данными, в котором используется читаемый человеком текст для хранения и передачи объектов данных, состоящих из пары атрибут – значение и массивы типов данных (или любое другое сериализуемое значение ). Это очень распространенный формат данных с широким спектром приложений, например, он служит заменой для XML в системах AJAX.

JSON - это независимый от языка формат данных. Он был получен из JavaScript, но многие современные языки программирования включают код для генерации и анализа данных в формате JSON. Официальный Интернет медиа-тип для JSON - это application / json. Имена файлов JSON используют расширение .json.

Дуглас Крокфорд изначально указал формат JSON в начале 2000-х годов. JSON был впервые стандартизирован в 2013 году как ECMA-404. RFC 8259, опубликованный в 2017 году, является текущей версией Интернет-стандарта <120.>STD 90 и остается совместимым с ECMA-404. В том же году JSON был стандартизирован как ISO / IEC 21778: 2017. Стандарты ECMA и ISO описывают только разрешенный синтаксис, тогда как RFC охватывает некоторые вопросы безопасности и взаимодействия.

Содержание
  • 1 История
  • 2 Типы данных и синтаксис
    • 2.1 Пример
    • 2.2 Проблемы переносимости данных
    • 2.3 Семантика
  • 3 Метаданные и схема
    • 3.1 Тип MIME
    • 3.2 Схема JSON
    • 3.3 Ссылки на объекты
  • 4 Приложения
    • 4.1 JSON-RPC
    • 4.2 AJAJ
    • 4.3 Как язык конфигурации
  • 5 Соображения безопасности
  • 6 Сравнение с другими форматами
    • 6.1 YAML
    • 6.2 XML
    • 6.3 Примеры
      • 6.3.1 Пример JSON
      • 6.3.2 Пример YAML
      • 6.3.3 Примеры XML
  • 7 См. Также
  • 8 Примечания
  • 9 Ссылки
  • 10 Внешние ссылки
История
Дуглас Крокфорд в здании Yahoo. (2007)

JSON возник из-за потребности в протоколе обмена данными между сервером и браузером в реальном времени без сохранения состояния без использования плагинов браузера, таких как Flash или Java апплеты, доминирующие методы, использовавшиеся в начале 2000-х.

Дуглас Крокфорд первым определил и популяризировал формат JSON. Аббревиатура возникла в State Software, компании, основанной Крокфордом и другими в марте 2001 года. Соучредители согласились создать систему, которая использует стандартные возможности браузера и обеспечивает уровень абстракции для создания веб-разработчиками. Web-приложения с отслеживанием состояния, которые имели постоянное дуплексное соединение с Web-сервером, удерживая два соединения Hypertext Transfer Protocol (HTTP) открытыми и повторно используя их перед стандартными тайм-аутами браузера, если обмен данными не производился. Соучредители провели обсуждение за круглым столом и проголосовали, следует ли называть формат данных JSML или JSON, а также под каким типом лицензии сделать его доступным. Крокфорд добавил в лицензию JSON пункт, в котором говорится, что «Программное обеспечение должно использоваться во благо, а не во зло», чтобы открывать библиотеки JSON, высмеивая корпоративных юристов и тех, кто слишком педантичен. Чип Морнингстар разработал идею State Application Framework в State Software. С другой стороны, этот пункт привел к совместимости лицензии проблемам лицензии JSON с другими лицензиями с открытым исходным кодом.

Предшественник библиотек JSON использовался в проекте детской игры по торговле цифровыми активами. названный Cartoon Orbit на сайте Communities.com (все соучредители штата работали в этой компании ранее) для Cartoon Network, который использовал дополнительный модуль браузера с проприетарным форматом обмена сообщениями для управления DHTML элементов (эта система также принадлежит 3DO). После обнаружения ранних возможностей Ajax, digiGroups, Noosh и другие использовали фреймы для передачи информации в визуальное поле пользовательских браузеров без обновления визуального контекста веб-приложения, реализуя полнофункциональные веб-приложения в реальном времени, используя только стандартные Возможности HTTP, HTML и JavaScript в Netscape 4.0.5+ и IE 5+. Затем Крокфорд обнаружил, что JavaScript можно использовать в качестве объектно-ориентированного формата обмена сообщениями для такой системы. Система была продана Sun Microsystems, Amazon.com и EDS. Веб-сайт JSON.org был запущен в 2002 году. В декабре 2005 года Yahoo! начал предлагать некоторые из своих веб-сервисов в формате JSON.

JSON был основан на подмножество языка сценариев JavaScript (в частности, Standard ECMA -262 3rd Edition - December 1999) и обычно используется с JavaScript, но это не зависящий от языка формат данных. Код для синтаксического анализа и генерации данных JSON легко доступен на многих языках программирования. На веб-сайте JSON перечислены библиотеки JSON по языкам.

Хотя JSON изначально рекламировался и считался строгим подмножеством JavaScript и ECMAScript, он непреднамеренно допускал использование некоторых неэкранированных символов в строках, которые были недопустимыми в строковых литералах JavaScript и ECMAScript. JSON стал строгим подмножеством ECMAScript с версии языка 2019 года. См. Проблемы переносимости данных ниже.

В октябре 2013 года Ecma International опубликовала первое издание своего стандарта JSON ECMA-404. В том же году RFC 7158 использовал ECMA-404 в качестве ссылки. В 2014 году RFC 7159 стал основным справочным материалом для использования JSON в Интернете, заменив RFC 4627 и RFC 7158 (но с сохранением ECMA-262 и ECMA-404 в качестве основных ссылок). В ноябре 2017 года ISO / IEC JTC 1 / SC 22 опубликовал ISO / IEC 21778: 2017 в качестве международного стандарта. 13 декабря 2017 года Инженерная группа Интернета отменила RFC 7159 после публикации RFC 8259, который является текущей версией Интернет-стандарта STD 90.

Типы данных и синтаксис

Основные типы данных JSON:

  • Число: десятичное число со знаком, которое может содержать дробную часть и может использовать экспоненциальную нотацию E, но не может включать нечисловые значения, такие как NaN. Формат не делает различий между целыми числами и числами с плавающей запятой. JavaScript использует формат с плавающей запятой двойной точности для всех своих числовых значений (до более поздних версий также поддерживает BigInt ), но другие языки, реализующие JSON, могут кодировать числа по-другому.
  • String : последовательность из нуля или более символов Unicode. Строки разделяются двойными кавычками и поддерживают обратную косую черту , экранирующую синтаксис.
  • Boolean : любое из значений trueили false
  • Array : упорядоченный список из нуля или более значений, каждое из которых может быть любого типа. В массивах используется нотация квадратной скобки с элементами, разделенными запятыми.
  • Объект : набор пар имя – значение, где имена (также называемые ключами) являются строками. Объекты предназначены для представления ассоциативных массивов, где каждый ключ уникален в пределах объекта. Объекты разделяются фигурными скобками и используют запятые для разделения каждой пары, в то время как внутри каждой пары символ двоеточия ':' отделяет ключ или имя от его значения.
  • null : пустое значение с использованием слова null

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

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

Пример

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

{"firstName": "John", "lastName": "Smith", "isAlive": true, "age": 27, "address": {"streetAddress": "21 2nd Street", "city" : "Нью-Йорк", "штат": "Нью-Йорк", "postalCode": "10021-3100"}, "phoneNumbers": [{"type": "home", "number": "212 555-1234"}, {"type": "office", "number": "646 555-4567"}], "children":, "spouse": null}

Проблемы с переносимостью данных

Хотя изначально Дуглас Крокфорд утверждал, что JSON является строгим подмножеством JavaScript, его спецификация фактически допускает действительные документы JSON, которые не являются действительным JavaScript; JSON позволяет использовать символы конца строки Unicode U + 2028 LINE SEPARATOR и U + 2029 PARAGRAPH SEPARATOR без экранирования в строках в кавычках, в то время как ECMAScript 2018 и старше этого не делает. Это следствие запрета JSON только на «управляющие символы». Для максимальной переносимости эти символы должны быть экранированы обратной косой чертой. Эта тонкость важна при генерации JSONP.

Обмен JSON в открытой экосистеме должен быть закодирован в UTF-8. Кодировка поддерживает полный набор символов Unicode, включая символы за пределами Basic Multilingual Plane (от U + 10000 до U + 10FFFF). Однако в случае экранирования эти символы должны быть записаны с использованием суррогатных пар UTF-16, а некоторые парсеры JSON пропускают эту деталь. Например, чтобы включить символ Emoji U + 1F610 😐 NEUTRAL FACE в JSON:

{"face": "😐"} // или {"face": " \ uD83D \ uDE10 "}

Числа в JSON не зависят от их представления в языках программирования. Хотя это позволяет сериализовать числа произвольной точности, это может привести к проблемам с переносимостью. Например, поскольку не делается различий между целочисленными значениями и значениями с плавающей запятой, некоторые реализации могут рассматривать 42, 42.0и 4.2E + 1как одно и то же число, а другие - нет. Стандарт JSON не предъявляет требований к деталям реализации, таким как переполнение, недополнение, потеря точности, округление или нули со знаком, но он рекомендует не ожидать точность более IEEE 754 binary64 для "хорошей совместимости". При сериализации двоичного представления числа с плавающей запятой на машинном уровне (например, binary64) в удобочитаемое десятичное представление (например, числа в JSON) и обратно нет неотъемлемой потери точности, поскольку существуют опубликованные алгоритмы, позволяющие точно это делать. и оптимально.

Комментарии были намеренно исключены из JSON. В 2012 году Дуглас Крокфорд описал свое дизайнерское решение следующим образом: «Я удалил комментарии из JSON, потому что я видел, что люди использовали их для хранения директив синтаксического анализа, что привело бы к нарушению взаимодействия».

Семантика

Хотя JSON обеспечивает синтаксическую основу для обмена данными, для однозначного обмена данными также требуется соглашение между производителем и потребителем о семантике конкретного использования синтаксиса JSON. Одним из примеров того, когда такое соглашение необходимо, является сериализация типов данных, определенных синтаксисом JavaScript, которые не являются частью стандарта JSON, например Дата, функция, регулярное выражение и undefined.

Метаданные и схема

MIME-тип

Официальный MIME-тип для текста JSON: «application / json", и большинство современных реализаций приняли это.

Неофициальный тип MIME «text / json» или тип содержимого «text / javascript» также получают устаревшую поддержку многими поставщиками услуг, браузерами, серверами, веб-приложения, библиотеки, фреймворки и API. Известные примеры включают Google Search API, Yahoo !, Flickr, Facebook API, Lift framework, Dojo Toolkit 0.4 и т. Д.

Схема JSON

Схема JSON определяет JSON - формат для определения структуры данных JSON для проверки, документирования и контроля взаимодействия. Он предоставляет контракт для данных JSON, необходимых для данного приложения, и того, как эти данные могут быть изменены.

Схема JSON основана на концепциях из схемы XML (XSD), но является На основе JSON. Как и в XSD, одни и те же инструменты сериализации / десериализации могут использоваться как для схемы, так и для данных; и самоописание. Он указан в Internet Draft в IETF, в настоящее время в проекте 2019-09, который был выпущен 19 сентября 2019 года. Для разных языков программирования доступно несколько валидаторов, каждый с разными уровнями соответствия.

Стандартного расширения имени файла не существует, но некоторые предлагают .schema.json.

Пример схемы JSON (2019-09):

{"$ schema": "http: // json-schema.org/draft/2019-09/schema "," title ":" Продукт "," type ":" object "," required ": [" id "," name "," price "]," properties ": {" id ": {" type ":" number "," description ":" Идентификатор продукта "}," name ": {" type ":" string "," description ":" Название продукта " }, "цена": {"тип": "число", "минимум": 0}, "теги": {"тип": "массив", "элементы": {"тип": "строка"}}, "запас": {"тип": "объект", "свойства": {"склад": {"тип": "число"}, "розничная торговля": {"тип": "число"}}}}}

Приведенную выше схему JSON можно использовать для проверки правильности текста JSON ниже:

{"id": 1, "name": "Foo", "price": 123, "tags": ["Bar "," Eek "]," stock ": {" склад ": 300," retail ": 20}}

Ссылки на объекты

Стандарт JSON не поддерживает ссылки на объекты , но черновик стандарта IETF для объекта на основе JSON. существует. Dojo Toolkit поддерживает ссылки на объекты с использованием стандартного JSON; в частности, модуль dojox.json.refобеспечивает поддержку нескольких форм ссылок, включая циклические, множественные, межсообщения и ленивые ссылки. На внутреннем уровне оба делают это, назначая ключ "$ ref"для таких ссылок и разрешая его во время синтаксического анализа; черновик IETF определяет только синтаксис URL, но Dojo допускает больше.

В качестве альтернативы существуют нестандартные решения, такие как использование переменных Mozilla JavaScript Sharp. Однако эта функциональность устарела в JavaScript 1.8.5 и была удалена в Firefox версии 12.

Приложения

JSON-RPC

JSON-RPC - это удаленная процедура. вызовите протокол (RPC), основанный на JSON, в качестве замены XML-RPC или SOAP. Это простой протокол, который определяет лишь несколько типов данных и команд. JSON-RPC позволяет системе отправлять уведомления (информацию на сервер, которая не требует ответа) и множественные вызовы на сервер, на которые можно ответить вне очереди. Пример запроса и ответа JSON-RPC 2.0 с использованием позиционных параметров.

->{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1} <-- {"jsonrpc": "2.0", "result": 19, "id": 1}

AJAJ

Асинхронный JavaScript и JSON (или AJAJ) относится к той же методологии динамической веб-страницы, что и Ajax, но вместо XML формат данных - JSON. AJAJ - это метод веб-разработки, который обеспечивает возможность веб-страницы запрашивать новые данные после их загрузки в веб-браузер. Обычно он отображает новые данные с сервера в ответ на действия пользователя на этой веб-странице. Например, то, что пользователь вводит в поле поиска , клиентский код затем отправляет на сервер, который немедленно отвечает раскрывающимся списком из соответствие элементов базы данных.

Следующий код JavaScript является примером клиента, использующего XMLHttpRequest для запроса данных в формате JSON с сервера. (Программирование на стороне сервера опущено; оно должно быть настроено для обслуживания запросов к url, содержащему строку в формате JSON.)

let result; const request = new XMLHttpRequest (); request.open ("ПОЛУЧИТЬ", URL, истина); request.responseType = "json"; request.onreadystatechange = function () {if (request.readyState === 4 / * ВЫПОЛНЕНО * / request.status === 200 / * ОК * /) {результат = request.response; }}; request.send (ноль);

В качестве языка конфигурации

Хотя JSON является форматом сериализации данных, он видел специальное использование как язык конфигурации. В этом случае поддержка комментариев и другие функции были сочтены полезными, что привело к созданию нескольких нестандартных надмножеств JSON . Среди них HJSON, HOCON и JSON5 (который, несмотря на свое название, не является пятой версией JSON). Основная цель версии 1.2 YAML заключалась в том, чтобы сделать нестандартный формат строгим надмножеством JSON.

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

Соображения безопасности

JSON предназначен как формат сериализации данных. Однако его дизайн как подмножество JavaScript может привести к неправильному представлению о том, что тексты JSON безопасно передавать в функцию JavaScript eval (). Это небезопасно, потому что некоторые допустимые тексты JSON, в частности те, которые содержат U + 2028 LINE SEPARATOR или U + 2029 PARAGRAPH SEPARATOR, фактически не были действительным кодом JavaScript до появления JavaScript спецификации были обновлены в 2019 году, и старые движки могут не поддерживать его.

Чтобы избежать многих ловушек, вызванных выполнением произвольного кода из Интернета, новая функция JSON.parse ()была первой. добавлен в пятую редакцию ECMAScript, которая с 2017 года поддерживается всеми основными браузерами. Для неподдерживаемых браузеров библиотека JavaScript, совместимая с API, предоставляется Дугласом Крокфордом. Кроме того, предложение TC39 "Subsume JSON" сделало ECMAScript строгим надмножеством JSON начиная с версии языка 2019 года.

Различные реализации парсера JSON пострадали от атака отказа в обслуживании и уязвимость массового назначения.

Сравнение с другими форматами

JSON продвигается как альтернатива XML с низкими накладными расходами, поскольку оба этих формата широко поддерживают создание, чтение и декодирование в реальных ситуациях, где они обычно используются. Помимо XML, примеры могут включать CSV и YAML (расширенный набор JSON). Кроме того, эту роль может выполнять Google Protocol Buffers, хотя это не язык обмена данными.

YAML

YAML версии 1.2 является расширенным набором JSON; предыдущие версии не были строго совместимы. Например, экранирование косой черты /обратной косой чертой \допустимо в JSON, но недопустимо в YAML. Такое экранирование является обычной практикой при внедрении JSON в HTML для защиты от атак межсайтового скриптинга.

YAML поддерживает комментарии, а JSON - нет.

XML

XML использовался для описания структурированных данных и сериализации объектов. Существуют различные протоколы на основе XML для представления тех же структур данных, что и JSON, для тех же целей обмена данными. Данные можно закодировать в XML несколькими способами. Самая обширная форма с использованием пар тегов приводит к гораздо большему представлению, чем JSON, но если данные хранятся в атрибутах и ​​форме «коротких тегов», где закрывающий тег заменяется на />, представление часто сводится к того же размера, что и JSON, или немного больше. Однако атрибут XML может иметь только одно значение, и каждый атрибут может появляться не более одного раза в каждом элементе.

XML отделяет «данные» от «метаданных» (посредством использования элементов и атрибутов), тогда как JSON не имеет такой концепции.

Другое ключевое отличие - адресация значений. JSON имеет объекты с простым отображением «ключа» в «значение», тогда как в XML-адресации происходит на «узлах», которые все получают уникальный идентификатор через процессор XML. Кроме того, стандарт XML определяет общий атрибут xml: id, который может использоваться пользователем для явной установки идентификатора.

Имена тегов XML не могут содержать никаких символов ! "# $% '() * +, /; <=>? @ [\] ^` {|} ~, ни пробел, и не может начинаться с -, .или числовой цифры, тогда как ключи JSON могут (даже если кавычки и обратная косая черта должны быть экранированы).

Значения XML представляют собой строки символов, без встроенная безопасность типа . XML имеет концепцию схемы, которая допускает строгую типизацию, определяемые пользователем типы, предопределенные теги и формальную структуру, позволяя формальную проверку потока XML. JSON имеет встроенную строгую типизацию и имеет аналогичную концепцию схемы в Схема JSON.

XML поддерживает комментарии, а JSON - нет.

Примеры

Пример JSON

{"first_name": "John", "last_name": "Smith", "age": 25, "address": {"street_address": "21 2nd Street", "city": "New York", "state ":" NY "," postal_code ":" 10021 "}," phone_numbers ": [{" type ":" home "," number ":" 212 555-1234 "}, {" type ":" факс ", "number": "646 555-4567"}], "sex": {"type": "мужской" }}

Оба следующих примера по-разному передают тот же тип информации, что и приведенный выше пример JSON, за исключением того, что XML не передает тип данных.

Пример YAML

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

first_name: John last_name: Smith возраст: 25 address: street_address: 21 2nd Street город: штат Нью-Йорк: почтовый индекс штата Нью-Йорк: '10021' phone_numbers: - тип: домашний номер: 212 555-1234 - тип: номер факса: 646 555-4567 пол: тип: мужской

образцы XML

Обратите внимание, что приведенные ниже примеры XML не кодируют тип данных (например, возраст - это число), и для кодирования той же информации, что и в приведенном выше примере JSON, потребуется что-то вроде схемы . как есть. Обратите внимание, что, поскольку имена тегов XML не могут содержать пробелы (в отличие от ключей JSON и YAML), необходимо использовать другое соглашение об именах для представления ключей JSON (в этом примере теги находятся в CamelCase ).

ДжонСмит25
21 2-я улицаНью-ЙоркNY10021
дом212 555-1234факс646 555-4567мужской

Свойства также могут быть риализовано с использованием атрибутов вместо тегов:

См. также
  • Потоковая передача JSON - об ограничении JSON в потоковых протоколах
  • Сравнение форматов сериализации данных
  • Связанные форматы
    • GeoJSON - открытый формат для кодирования различных структур географических данных
    • JSON-LD - нотация объекта JavaScript для связанных данных, рекомендация W3C
    • JSON-RPC - протокол удаленного вызова процедур, закодированный в JSON
    • JsonML - язык разметки, используемый для сопоставления XML и JSON
    • S-выражение - сопоставимый формат LISP для деревьев в виде текста.
    • SOAPjr - гибрид SOAP и JR (JSON-RPC)
    • - формат аннотации последовательностей нуклеиновых кислот (ДНК и РНК )
  • Связанные двоичные кодировки
    • BSON - с типами данных, представляющими особый интерес для MongoDB
    • CBOR - частично основан на JSON
    • MessagePack - с типами данных, примерно соответствующими JSON
    • Smile - на основе JSON
    • UBJSON - двоичный формат прямая имитация JSON
    • EXI4JSON (EXI для JSON) - представление посредством стандарта Efficient XML Interchange (EXI)
  • Реализации:
    • Jackson - процессор JSON для Java
Примечания
Ссылки
Внешние ссылки
Последняя правка сделана 2021-05-24 10:19:33
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте