JSON - JSON

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

JSON ( JavaScript Object Notation , выраженный / с ən / ; и / ˌ с ɒ п / ) является открытым стандартом формата файла и обмена данными в формате , который использует читаемый человеком текст для хранения и передачи данных объектов , состоящих из пары и массивы атрибут-значение (или другие сериализуемые значения). Это общий формат данных с разнообразным набором функций при обмене данными.в том числе связь веб-приложений с серверами .

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

Дуглас Крокфорд первоначально определил формат JSON в начале 2000-х годов.

Название и произношение

Аббревиатура возникла в State Software, компании, основанной Дугласом Крокфордом и другими в марте 2001 года.

В 2017 международный стандарт (ECMA-404 и ISO / IEC 21778: 2017) определяет "Произносится / . S ə п / , как и в ' Джейсон и The аргонавтов ' ". Первое (2013 г.) издание ECMA-404 не касалось произношения. В Руководстве по системному администрированию UNIX и Linux говорится, что « Дуглас Крокфорд , который назвал и продвигал формат JSON, говорит, что он произносится как имя Джейсон. Но почему-то« JAY-sawn », кажется, стало более распространенным в техническом сообществе». Крокфорд сказал в 2011 году: «Есть много споров о том, как вы это произносите, но меня это строго не волнует».

Стандарты

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

История

Дуглас Крокфорд в здании Yahoo (2007)

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

Предшественник библиотек JSON использовался в детском игровом проекте по торговле цифровыми активами под названием Cartoon Orbit на сайте Communities.com (над которым ранее работали соучредители State Software) для Cartoon Network, в котором использовался подключаемый модуль на стороне браузера с собственный формат сообщений для управления элементами Dynamic HTML (эта система также принадлежит 3DO). После обнаружения ранних возможностей Ajax , digiGroups, Noosh и другие использовали фреймы для передачи информации в визуальное поле пользовательских браузеров без обновления визуального контекста веб-приложения, реализуя полнофункциональные веб-приложения в реальном времени с использованием только стандартных возможностей HTTP, HTML и JavaScript. из Netscape 4.0.5+ и IE 5+.

Крокфорд первым определил и популяризировал формат JSON. Соучредители State Software согласились создать систему, которая использовала стандартные возможности браузера и обеспечивала уровень абстракции для веб-разработчиков для создания веб-приложений с отслеживанием состояния, которые имели постоянное дуплексное соединение с веб-сервером, удерживая открытыми два соединения по протоколу передачи гипертекста (HTTP). и перезапускать их до стандартных тайм-аутов браузера, если обмен данными не производился. Соучредители провели обсуждение за круглым столом и проголосовали за то, называть ли формат данных JSML (язык разметки JavaScript) или JSON (нотация объектов JavaScript), а также под каким типом лицензии сделать его доступным. Чип Морнингстар разработал идею State Application Framework в State Software.

Система была продана Sun Microsystems , Amazon.com и EDS . Веб-сайт JSON.org был запущен в 2002 году. В декабре 2005 года Yahoo! начала предлагать некоторые из своих веб-сервисов в формате JSON.

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

В октябре 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 года Engineering Task Force Интернет устарел RFC  7159 , когда он опубликовал RFC  8259 , которая является текущей версией Internet Standard STD 90.

Крокфорд добавил в лицензию JSON пункт, в котором говорится, что «Программное обеспечение должно использоваться во благо, а не во зло», чтобы открывать исходный код для библиотек JSON, высмеивая корпоративных юристов и тех, кто чрезмерно педантичен. С другой стороны, этот пункт привел к проблемам совместимости лицензии JSON с другими лицензиями с открытым исходным кодом , поскольку программное обеспечение с открытым исходным кодом и бесплатное программное обеспечение обычно не накладывают ограничений на цели использования.

Синтаксис

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

{
  "firstName": "John",
  "lastName": "Smith",
  "isAlive": true,
  "age": 27,
  "address": {
    "streetAddress": "21 2nd Street",
    "city": "New York",
    "state": "NY",
    "postalCode": "10021-3100"
  },
  "phoneNumbers": [
    {
      "type": "home",
      "number": "212 555-1234"
    },
    {
      "type": "office",
      "number": "646 555-4567"
    }
  ],
  "children": [],
  "spouse": null
}

Кодировка символов

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

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

{ "face": "😐" }
// or
{ "face": "\uD83D\uDE10" }

JSON стал строгим подмножеством ECMAScript с версии языка 2019 года.

Типы данных

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

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

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

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

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

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

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

Семантика

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

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

Официальный тип 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 основана на концепциях схемы XML (XSD), но на основе JSON. Как и в XSD, одни и те же инструменты сериализации / десериализации могут использоваться как для схемы, так и для данных, и это самоописание. Это указано в Интернет-проекте IETF, в настоящее время это черновик 2020-12 гг., Выпущенный 28 января 2021 г. Существует несколько валидаторов, доступных для разных языков программирования, каждый с разным уровнем соответствия. Стандартного расширения имени файла не существует.

Стандарт JSON не поддерживает ссылки на объекты , но существует черновик стандарта IETF для ссылок на объекты на основе JSON. Доджо Инструментарий поддерживает ссылки на объекты , используя стандартный JSON; в частности, dojox.json.refмодуль обеспечивает поддержку нескольких форм ссылок, включая циклические , множественные, ссылки между сообщениями и отложенные ссылки. Внутренне оба делают это, назначая "$ref"ключ для таких ссылок и разрешая его во время синтаксического анализа; черновик IETF определяет только синтаксис URL, но Dojo допускает больше. В качестве альтернативы существуют нестандартные решения, такие как использование переменных Mozilla JavaScript Sharp. Однако эта функциональность устарела в JavaScript 1.8.5 и была удалена в Firefox версии 12.

Использует

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

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

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

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

JSON задуман как формат сериализации данных . Однако его дизайн как подмножество JavaScript может привести к неправильному представлению о том, что передавать тексты JSON в функцию JavaScript безопасно . Это небезопасно, поскольку некоторые допустимые тексты JSON, в частности те, которые содержат U + 2028 LINE SEPARATOR или U + 2029 PARAGRAPH SEPARATOR , не являются действительным кодом JavaScript до тех пор, пока спецификации JavaScript не будут обновлены в 2019 году, и поэтому старые движки могут не поддерживать его. Чтобы избежать множества ловушек, вызванных выполнением произвольного кода из Интернета, в пятую редакцию ECMAScript, которая с 2017 года поддерживается всеми основными браузерами , впервые была добавлена новая функция . Для неподдерживаемых браузеров библиотека JavaScript, совместимая с API, предоставляется Дугласом Крокфордом . Кроме того, предложение TC39 «Subsume JSON» сделало ECMAScript строгим надмножеством JSON начиная с версии языка 2019 года. eval() JSON.parse()

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

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

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

YAML

YAML версии 1.2 является расширенным набором JSON; предыдущие версии не были строго совместимы. Например, экранирование косой черты /с помощью обратной косой черты \допустимо в JSON, но недействительно в YAML. 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. Примеры включают GeoJSON , JSON-LD , Smile (формат обмена данными) , UBJSON , JSON-RPC , JsonML и JSON → URL .

Смотрите также

использованная литература

внешние ссылки