JSON

«Json» перенаправляется сюда. Чтобы узнать о людях с похожими именами, см. J Son .

Обозначение объектов JavaScript

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

JSON ( JavaScript Object Notation , произносится / ˈ dʒ eɪ s ən / или / ˈ dʒ eɪ ˌ s ɒ n / ) — это открытый стандартный формат файлов и обмена данными формат , который использует удобочитаемый текст для хранения и передачи объектов данных, состоящих из атрибутов. –пары значений и массивы (или другие сериализуемые значения). Это широко используемый формат данных, который широко используется при электронном обмене данными , включая веб-приложения с серверами .

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

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

Именование и произношение

2017 года Международный стандарт (ECMA-404 и ISO/IEC 21778:2017) определяет, что «JSON» «произносится / ˈ dʒ eɪ . s ə n / , как в « Джейсон и аргонавты » . Первое (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 и описывают только разрешенный синтаксис, тогда как / IEC RFC охватывает некоторые соображения безопасности и совместимости.

История

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

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

Крокфорд первым определил и популяризировал формат JSON. Эта аббревиатура возникла в компании State Software, соучредителями которой были Крокфорд и другие в марте 2001 года. Соучредители согласились создать систему, которая использовала бы стандартные возможности браузера и предоставляла веб-разработчикам уровень абстракции для создания веб-приложений с отслеживанием состояния, которые имели постоянное дуплексное соединение с веб-сервер, удерживая открытыми два соединения протокола передачи гипертекста (HTTP) и перезапуская их до истечения стандартного времени ожидания браузера, если дальнейший обмен данными не осуществлялся. Соучредители провели круглый стол и проголосовали за то, называть ли формат данных JSML (язык разметки JavaScript) или JSON (нотация объектов JavaScript), а также под каким типом лицензии сделать его доступным. JSON.org веб-сайт был запущен в 2001 году. В декабре 2005 года Yahoo! начала предлагать некоторые из своих веб-сервисов в формате JSON.

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

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 г. Рабочая группа по проектированию Интернета упразднила RFC   7159 , когда он был опубликован RFC   8259 — текущая версия интернет -стандарта STD 90.

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

Синтаксис

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

{ 
   "first_name"  :   "Джон"  , 
   "last_name"  :   "Смит"  , 
   "is_alive"  :   true  , 
   "age"  :   27  , 
   "address"  :   { 
     "street_address"  :   "21 2nd Street"  , 
     "city"  :   "Новый Йорк"  , 
     "штат"  :   "Нью-Йорк"  , 
     "postal_code"  :   "10021-3100" 
   }, 
   "phone_numbers"  :   [ 
     { 
       "type"  :   "home"  , 
       "number"  :   "212 555-1234" 
     }, 
     { 
       " тип"  :   "офис"  , 
       "номер"  :   "646 555-4567" 
     } 
   ], 
   "дети"  :   [ 
     "Кэтрин"  , 
     "Томас"  , 
     "Тревор" 
   ], 
   "супруга"  :   null 
 } 

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

Хотя Крокфорд изначально утверждал, что JSON — это строгое подмножество JavaScript и ECMAScript , его спецификация фактически допускает действительные документы JSON, которые не являются допустимыми документами JavaScript; JSON позволяет использовать терминаторы строк в Юникоде. U+2028 РАЗДЕЛИТЕЛЬ СТРОК и U+2029 Разделитель абзацев будет отображаться в строках в кавычках без экранирования, а в ECMAScript 2018 и более ранних версиях — нет. Это следствие того, что JSON запрещает использование только «управляющих символов». Для максимальной переносимости эти символы должны быть экранированы обратной косой чертой.

Обмен JSON в открытой экосистеме должен быть закодирован в UTF-8 . Кодировка поддерживает полный набор символов Юникода, включая символы за пределами базовой многоязычной плоскости (от U+0000 до U+FFFF). Однако, если они экранированы, эти символы должны быть записаны с использованием суррогатных пар UTF-16 . Например, чтобы включить Emoji символ U+1F610 😐 НЕЙТРАЛЬНОЕ ЛИЦО в JSON:

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

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

Типы данных

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

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

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

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

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

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

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

Совместимость

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

• Некоторые реализации JSON принимают только тексты JSON, представляющие объект или массив. Для обеспечения совместимости приложения, обменивающиеся JSON, должны передавать сообщения, которые являются объектами или массивами.
• Спецификации допускают объекты JSON, содержащие несколько элементов с одинаковым именем. Поведение реализаций, обрабатывающих объекты с повторяющимися именами, непредсказуемо. Для обеспечения совместимости приложениям следует избегать дублирования имен при передаче объектов JSON.
• В спецификациях конкретно сказано, что порядок членов в объектах JSON не имеет значения. Для обеспечения совместимости приложениям следует избегать присвоения значения порядку членов, даже если программное обеспечение синтаксического анализа делает этот порядок видимым.
• Хотя спецификации не накладывают ограничений на величину или точность числовых литералов JSON, широко используемая реализация JavaScript хранит их как величины IEEE754 «binary64». В целях совместимости приложениям следует избегать передачи чисел, которые невозможно представить таким образом, например 1E400 или 3.141592653589793238462643383279.
• Хотя спецификации не ограничивают кодировку символов Юникода в тексте JSON, подавляющее большинство реализаций предполагают UTF-8 кодировку ; для обеспечения совместимости приложения всегда должны кодировать сообщения JSON только в UTF-8.
• Спецификации не запрещают передачу последовательностей байтов, которые неправильно представляют символы Юникода. Для обеспечения совместимости приложения должны передавать сообщения, не содержащие таких последовательностей байтов.
• Спецификация не ограничивает способы сравнения строк Юникода в приложениях. Для обеспечения совместимости приложения всегда должны выполнять такие сравнения код за блоком.

В 2015 году IETF опубликовал RFC   7493 , описывающий «Формат сообщения I-JSON», ограниченный профиль JSON, который ограничивает синтаксис и обработку JSON, чтобы избежать, насколько это возможно, этих проблем совместимости.

Семантика

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

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

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

Схема JSON определяет формат на основе JSON для определения структуры данных JSON для проверки, документирования и управления взаимодействием. Он предоставляет контракт для данных JSON, необходимых данному приложению, и способы изменения этих данных. Схема JSON основана на концепциях XML-схемы (XSD), но основана на JSON. Как и в XSD, одни и те же инструменты сериализации/десериализации могут использоваться как для схемы, так и для данных, и они самоописываются. Он указан в интернет-проекте IETF, причем последней версией по состоянию на 2024 год является «Проект 2020-12». Для разных языков программирования доступно несколько валидаторов. каждый с разным уровнем соответствия. Стандартное расширение имени файла — .json.

Стандарт JSON не поддерживает ссылки на объекты , но существует проект стандарта IETF для ссылок на объекты на основе JSON.

Использует

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

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

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

MongoDB использует данные в формате JSON для своей документо-ориентированной базы данных .

В некоторые реляционные базы данных, такие как PostgreSQL и MySQL, добавлена ​​поддержка собственных типов данных JSON. Это позволяет разработчикам хранить данные JSON непосредственно в реляционной базе данных без необходимости конвертировать их в другой формат данных.

Безопасность

JSON, являющийся подмножеством JavaScript, может привести к неправильному представлению о том, что передавать тексты JSON в JavaScript безопасно. eval()функция. Это небезопасно из-за некоторых допустимых текстов JSON, особенно тех, которые содержат U+2028 РАЗДЕЛИТЕЛЬ СТРОК или U+2029 PARAGRAPH SEPARATOR не является действительным кодом JavaScript до тех пор, пока спецификации JavaScript не будут обновлены в 2019 году, поэтому старые движки могут его не поддерживать. Чтобы избежать многих ловушек, вызванных выполнением произвольного кода из Интернета, появилась новая функция: JSON.parse(), впервые был добавлен в пятое издание ECMAScript, который по состоянию на 2017 год поддерживается всеми основными браузерами. Для неподдерживаемых браузеров API-совместимая библиотека JavaScript предоставлена ​​Дугласом Крокфордом . Кроме того, предложение TC39 «Подключить JSON» сделало ECMAScript строгим расширенным набором JSON начиная с версии языка 2019 года. Различные реализации парсера JSON пострадали от атак типа «отказ в обслуживании» и уязвимостей массового присвоения .

Альтернативы

См. также: Сравнение форматов сериализации данных.

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

XML

Основная статья: XML

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

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

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

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

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

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

Суперсеты

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

ЯМЛ

См. также: YAML § JSON.

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

КСОН

CSON (« Нотация объекта CoffeeScript ») использует значительные отступы , ключи без кавычек и предполагает объявление внешнего объекта. Он использовался для настройки GitHub на текстового редактора Atom .

Существует также несвязанный проект под названием CSON («Нотация объектов рукописного сценария»), который синтаксически более похож на JSON.

ХОКОН

HOCON («нотация объекта конфигурации, оптимизированная для человека») — это формат удобочитаемых данных, расширенный набор JSON. Использование HOCON:

• В основном он используется в сочетании с платформой Play , и разработан Lightbend .
• Он также поддерживается в качестве формата конфигурации для проектов .NET через Akka.NET. и Марионетка .
• Трансляция TIBCO: HOCON — это основной формат файла конфигурации для потоковой передачи TIBCO. семейство продуктов (StreamBase, LiveView и Artifact Management Server), начиная с TIBCO Streaming Release 10.
• Это также основной формат файла конфигурации для нескольких подсистем Exabeam Advanced Analytics.
• Jitsi использует его как «новую» систему конфигурации, а .properties -Files как запасной вариант.

JSON5

JSON5 («Формат обмена данными JSON5») — это расширение синтаксиса JSON, которое, как и JSON, также является допустимым синтаксисом JavaScript. Спецификация была начата в 2012 году и завершена в 2018 году версией 1.0.0. Основные отличия от синтаксиса JSON:

• Необязательные завершающие запятые
• Ключи объекта без кавычек
• Строки с одинарными кавычками и многострочные строки
• Дополнительные числовые форматы
• Комментарии

Синтаксис JSON5 поддерживается в некоторых программах как расширение синтаксиса JSON, например, в SQLite .

JSONC

JSONC (JSON с комментариями) — это подмножество JSON5, используемое в коде Microsoft Visual Studio :

• поддерживает однострочные комментарии ( //) и блокировать комментарии ( /* */)
• принимает конечные запятые, но они не рекомендуются, и редактор выводит предупреждение

Производные

Несколько форматов сериализации были созданы на основе спецификации JSON. Примеры включают в себя

• GeoJSON — формат, предназначенный для представления простых географических объектов.

• JSON-LD — метод кодирования связанных данных с использованием JSON.
• JSON-RPC — протокол удаленного вызова процедур, закодированный в JSON.
• JsonML — легкий язык разметки, используемый для сопоставления XML и JSON.
• Улыбка (формат обмена данными)
• UBJSON — двоичный компьютерный формат обмена данными, имитирующий JSON, но требующий меньшего количества байтов данных.

См. также

• БСОН
• Сравнение форматов сериализации данных
• Amazon Ion — расширенный набор JSON.
• Джексон (API)
• jaql — функциональный язык обработки данных и запросов, наиболее часто используемый для обработки запросов JSON.
• jq — «язык запросов JSON» и язык программирования высокого уровня.
• JSONiq — JSON-ориентированный язык запросов и обработки на основе XQuery.
• Потоковая передача JSON
• S-выражение
• Модуль Википедии ТНТ

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

• Официальный веб-сайт