JSON

JSON (англ. JavaScript Object Notation, обычно произносится как /ˈsən/ JAY-sən[3]) — текстовый формат обмена данными, основанный на JavaScript. Как и многие другие текстовые форматы, JSON легко читается людьми. Формат JSON был разработан Дугласом Крокфордом[4].

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

За счёт своей лаконичности по сравнению с XML формат JSON может быть более подходящим для сериализации сложных структур. Применяется в веб-приложениях как для обмена данными между браузером и сервером (AJAX), так и между серверами (программные HTTP-сопряжения).

Поскольку формат JSON является подмножеством синтаксиса языка JavaScript, то он может быть быстро десериализован встроенной функцией eval().

JSON-текст представляет собой (в закодированном виде) одну из двух структур:

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

Строка очень похожа на литерал одноимённого типа данных в языке Javascript. Число тоже очень похоже на Javascript-число, за исключением того, что используется только десятичный формат (с точкой в качестве разделителя). Пробелы могут быть вставлены между любыми двумя синтаксическими элементами.

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

Обратите внимание на пару "postalCode": 101101. В качестве значений в JSON могут быть использованы как числа, так и строки. Поэтому запись "postalCode": "101101" содержит строку, а "postalCode": 101101 — уже числовое значение. Из-за слабой типизации в Javascript и PHP строка может быть приведена к числу и не влиять на логику программы. Тем не менее, рекомендуется аккуратно обращаться с типом значения, так как JSON служит для межсистемного обмена.

JSON5 — предложенное расширение формата json в соответствии с синтаксисом ECMAScript 5, вызванное тем, что json используется не только для общения между программами, но и создаётся/редактируется вручную[6]. Файл JSON5 всегда является корректным кодом ECMAScript 5. JSON5 обратно совместим с JSON. Для некоторых языков программирования уже существуют парсеры json5[7].

Как функционально, так и синтаксически JSON является подмножеством языка YAML. В частности, спецификация YAML 1.2 указывает, что «любой файл в формате JSON является корректным файлом в формате YAML»[8]. Наиболее распространённый парсер YAML способен обрабатывать и JSON[9]. Спецификация YAML до версии 1.2 не полностью покрывала JSON, в первую очередь из-за отсутствия родной поддержки UTF-32 в YAML, а также требования пробела после разделителя-запятой; кроме того, спецификация JSON включала комментарии в стиле /* */.

Наиболее важным отличием YAML является набор расширений синтаксиса, которым нет аналогов в JSON:

JSON Schema — один из языков описания структуры JSON-документа. Использует синтаксис JSON. Базируется на концепциях XML Schema, RelaxNG, Kwalify. JSON Schema — самоописательный язык: при его использовании для обработки данных и описания их допустимости могут использоваться одни и те же инструменты сериализации/десериализации[10].

Стандарт JSON не поддерживает ссылки на объекты, но желаемого результата можно достичь при помощи дополнительных соглашений. Рекомендацией W3C для связанных данных является JSON-LD, в котором использована модель данных RDF. В JSON-LD к данным добавляется контекст (context), связывающий свойства объектов JSON-документа с элементами онтологий[11].

Следующий пример Javascript-кода показывает, как браузер может использовать XMLHttpRequest, чтобы запрашивать с сервера объект в формате JSON (серверная часть программы опущена; в ней должен быть размещён код, отправляющий данные в формате JSON-строки в ответ на запросы по url).

Заметим, что данный пример применения XMLHttpRequest не поддерживает Internet Explorer до версии 6 включительно, так что для них следует использовать несколько иной код. Возможности применения XMLHttpRequest ограничены из-за правила ограничения домена (same origin policy): URL-ответ на запрос должен находиться в том же DNS-домене, что и сервер, на котором находится страница, запрашивающая ответ. В качестве альтернативы применяется подход JSONP, включающий в себя использование закодированного вызова функции, передающегося между клиентом и сервером, чтобы клиент мог загружать закодированные в JSON данные со сторонних доменов, и уведомлять о завершении вызывающую сторону, хотя это приводит к некоторым рискам для безопасности и дополнительным требованиям к серверу.

Как вариант, в коде страницы можно использовать элементы <iframe> для асинхронного запроса JSON-данных, или просто <form action="url_to_cgi_script">. Эти подходы были распространены до появления широкой поддержки XMLHttpRequest.

Также можно использовать для передачи JSON-данных динамические теги <script>. С помощью этого метода можно обойти правило ограничения домена (same origin policy), но он приводит к появлению уязвимого кода. В качестве более безопасной альтернативы было предложено использовать .

Хотя JSON предназначен для передачи данных в сериализованном виде, его синтаксис соответствует синтаксису JavaScript и это создаёт ряд проблем безопасности. Зачастую для обработки данных, полученных от внешнего источника в формате JSON, к ним применяется функция eval() без какой-либо предварительной проверки.

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

Техника использования eval() делает систему уязвимой, если источник используемых JSON-данных не является доверенным (англ.). В качестве таких данных может выступать вредоносный JavaScript код для атак класса Внедрение кода (англ.). С помощью данной уязвимости возможно осуществлять кражу данных, подделку аутентификации. Тем не менее, уязвимость можно устранить за счёт использования дополнительных средств проверки данных на корректность. Например, до выполнения eval() полученные от внешнего источника данные могут проверяться с помощью регулярных выражений. В RFC, определяющей JSON[12], предлагается использовать следующий код для проверки его соответствия формату JSON

Как более безопасная альтернатива eval() была предложена новая функция JSON.parse(), способная обрабатывать только JSON-данные. Она была представлена в четвёртой версии стандарта ECMAScript и описана в статье «JSON: Обезжиренная альтернатива XML»[13]. В настоящее время она доступна как библиотека JavaScript[14] и была включена в пятую редакцию ECMAScript.

Последние версии веб-браузеров имеют встроенную поддержку JSON и способны его обрабатывать без вызова функции eval(), приводящей к вышеописанной проблеме с безопасностью. Обработка JSON в таком случае обычно осуществляется быстрее. Так в июне 2009 года следующие браузеры имели встроенную поддержку JSON:

По крайней мере пять популярных библиотек JavaScript используют встроенный JSON в случае его доступности:

Непродуманное использование JSON делает сайты уязвимыми для подделки межсайтовых запросов (CSRF или XSRF)[25]. Поскольку тег <script> допускает использование источника, не принадлежащего к тому же домену, что и использующий ресурс, это позволяет выполнять код под видом данных, представленных в формате JSON, в контексте произвольной страницы, что делает возможным компрометацию паролей или другой конфиденциальной информации пользователей, прошедших авторизацию на другом сайте.

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

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

В основу технологии положен тот факт, что политика безопасности браузера не запрещает использовать тег <script type="text/javascript" src="…"></script> для обращения к серверам, отличным от сервера, с которого произошла загрузка страницы.

Без использования технологии JSONP (то есть используя просто JSON кодирование данных) сервер может вернуть только данные. Например, так:

Используя технику JSONP, стороннему серверу передаётся в строке вызова (GET) имя callback функции:

<script type="text/javascript" src="http://example.com/getjson?jsonp=parseResponse"></script>

Первоначально идея была предложена в блоге MacPython в 2005 году[26] и в настоящее время используется многими Web 2.0 приложениями, такими, как Dojo Toolkit Applications, Google Toolkit Applications [ и zanox Web Services. Дальнейшие расширения этого протокола были предложены с учётом ввода дополнительных аргументов, как, например, в случае JSONPP[27] при поддержке S3DB веб-сервисов.

Поскольку JSONP использует скрипт теги, вызовы по сути открыты миру. По этой причине JSONP может быть неуместными для хранения конфиденциальных данных[28].

Включение скриптовых тегов от удалённых сайтов позволяет им передать любой контент на сайте. Если удалённый сайт имеет уязвимости, которые позволяют выполнить Javascript инъекции, то исходный сайт также может быть затронут ими.

JSONPP (англ. parameterized JSON with padding — «параметризованный JSON с подкладкой») — развитие идеи JSONP.

JSONPP включает в себя URL источника, имя функции, которая будет обрабатывать JSON данные, строка для eval после получения данных и строка для eval после окончания обработки данных:

Вообще, для самой идеи JSONPP не принципиально количество параметров. Достаточно SRC, JSONP, JSONPP (и их обработка на стороне сервера, а затем клиента) для того, чтобы это был JSONPP.

В примере функция s3db_jsonpp_call() создаёт в DOM в части head элемент script, src которого соответствует вызову JSONPP.

После получения ответа от сервера будет вызвана s3db_jsonpp() — она передана в параметрах вызова, как это должно быть по правилам JSONP.

Внутри s3db_jsonpp() сработает eval(jsonpp), и произойдёт возврат значения ans.

Вызов eval(onload) приводит к выполнению remove_element_by_id() с id созданного скрипта в head и в итоге к его удалению, ведь он уже всё равно не будет использоваться, поскольку id в примере было сгенерировано случайным образом в самом начале функции s3db_jsonpp_call(). Этот вызов в ответе сервера.

Бинарное расширение JSON, внедрённое в СУБД PostgreSQL в версии 9.4.18. Фактически, JSONB является бинарным представлением JSON[29], с тем различием, что в хранимых строках пробелы удаляются, сортировка объектов не сохраняется и сохраняется только последнее значение для ключей-дубликатов[30].