N/RFCNET
← Карточка документаEnglish original ↗

RFC 8259 · Декабрь 2017 · Заменяет RFC 7159

Формат обмена данными JavaScript Object Notation (JSON)

Internet Engineering Task Force (IETF)
Т. Брэй (T. Bray), редактор · Textuality
Категория: процесс стандартизации · ISSN: 2070-1721

Аннотация

JavaScript Object Notation (JSON) — компактный текстовый, независимый от языка программирования формат обмена данными. Он произошёл от стандарта языка программирования ECMAScript. JSON определяет небольшой набор правил оформления для переносимого представления структурированных данных.

Этот документ устраняет несогласованности с другими спецификациями JSON, исправляет ошибки спецификации и предлагает основанные на опыте рекомендации по совместимости.

Статус документа

Это документ процесса стандартизации Интернета.

Документ подготовлен Инженерным советом Интернета (IETF). Он отражает консенсус сообщества IETF, прошёл публичное обсуждение и одобрен к публикации Руководящей группой инженерных работ Интернета (IESG). Дополнительные сведения о стандартах Интернета приведены в разделе 2 RFC 7841.

Информация о текущем статусе документа, исправлениях и порядке отправки отзывов доступна по адресу rfc-editor.org/info/rfc8259.

Уведомление об авторских правах

Copyright (c) 2017 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На документ распространяются BCP 78 и Правовые положения IETF Trust, относящиеся к документам IETF (trustee.ietf.org/license-info), действовавшие на дату его публикации. Внимательно ознакомьтесь с ними: они определяют ваши права и ограничения в отношении этого документа. Компоненты кода, извлечённые из документа, должны включать текст Упрощённой лицензии BSD, как указано в разделе 4.e Правовых положений Trust, и предоставляются без гарантий согласно Упрощённой лицензии BSD.

Документ может содержать материалы из документов или вкладов IETF, опубликованных либо предоставленных для публичного доступа до 10 ноября 2008 года. Лица, обладающие авторскими правами на некоторые из этих материалов, могли не предоставить IETF Trust право разрешать изменения таких материалов вне процесса стандартизации IETF. Без получения надлежащего разрешения от обладателей авторских прав на такие материалы документ нельзя изменять вне процесса стандартизации IETF или создавать на его основе производные произведения вне этого процесса, кроме форматирования для публикации в качестве RFC или перевода на другие языки.

Содержание

1. Введение

JavaScript Object Notation (JSON) — текстовый формат сериализации структурированных данных. Он происходит от объектных литералов JavaScript, определённых в третьем издании стандарта языка программирования ECMAScript [ECMA-262].

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

Строка — последовательность из нуля или более символов Unicode [UNICODE]. Эта ссылка указывает на последнюю версию Unicode, а не на конкретный выпуск. Не ожидается, что будущие изменения спецификации Unicode повлияют на синтаксис JSON.

Объект — неупорядоченная коллекция из нуля или более пар «имя/значение», где имя является строкой, а значение — строкой, числом, логическим значением, null, объектом или массивом.

Массив — упорядоченная последовательность из нуля или более значений.

Термины «объект» и «массив» происходят из соглашений JavaScript.

Целями проектирования JSON были минимальность, переносимость, текстовое представление и принадлежность к подмножеству JavaScript.

1.1. Соглашения, используемые в документе

Ключевые слова «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «NOT RECOMMENDED», «MAY» и «OPTIONAL» следует толковать согласно BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они написаны целиком прописными буквами, как показано здесь.

Грамматические правила настоящего документа следует толковать согласно [RFC5234].

1.2. Спецификации JSON

Настоящий документ заменяет [RFC7159]. [RFC7159] заменил [RFC4627], в котором JSON был описан первоначально и зарегистрирован медиатип «application/json».

JSON также описан в [ECMA-404].

Ссылка на ECMA-404 в предыдущем предложении нормативная. Это не означает обычного требования обратиться к ней для понимания документа; цель ссылки — подчеркнуть отсутствие несогласованностей в определении термина «текст JSON» во всех его спецификациях. Однако ECMA-404 допускает ряд практик, которых настоящая спецификация рекомендует избегать ради максимальной совместимости.

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

Если в одном документе обнаружена ошибка, другой следует проверить на наличие аналогичной ошибки; при её наличии её следует по возможности исправить.

При изменении любого из документов в будущем ECMA и IETF будут совместно обеспечивать сохранение их согласованности.

1.3. Введение к этой редакции

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

Кроме того, сообщалось о небольшом количестве исправлений к RFC 4627 — RFC Errata ID 607 [Err607] и 3607 [Err3607] — и к RFC 7159: RFC Errata ID 3915 [Err3915], 4264 [Err4264], 4336 [Err4336] и 4388 [Err4388].

Цель документа — применить исправления, устранить несогласованности с другими спецификациями JSON и отметить практики, способные приводить к проблемам совместимости.

2. Грамматика JSON

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

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

JSON-text = ws value ws

   Шесть структурных символов:

      begin-array     = ws %x5B ws  ; [ left square bracket

      begin-object    = ws %x7B ws  ; { left curly bracket

      end-array       = ws %x5D ws  ; ] right square bracket

      end-object      = ws %x7D ws  ; } right curly bracket

      name-separator  = ws %x3A ws  ; : colon

      value-separator = ws %x2C ws  ; , comma

Незначащие пробельные символы допускаются до и после любого из шести структурных символов.

ws = *(
              %x20 /              ; Space
              %x09 /              ; Horizontal tab
              %x0A /              ; Line feed or New line
              %x0D )              ; Carriage return

3. Значения

Значение JSON ОБЯЗАНО (MUST) быть объектом, массивом, числом, строкой либо одним из следующих трёх литеральных имён:

false
null
true

Литеральные имена ОБЯЗАТЕЛЬНО (MUST) пишутся строчными буквами. Другие литеральные имена не допускаются.

value = false / null / true / object / array / number / string

      false = %x66.61.6c.73.65   ; false

      null  = %x6e.75.6c.6c      ; null

      true  = %x74.72.75.65      ; true

4. Объекты

Объект представляется парой фигурных скобок, внутри которых находится ноль или более пар «имя/значение», также называемых членами объекта. Имя является строкой. После каждого имени следует одно двоеточие, отделяющее имя от значения. Одна запятая отделяет значение от следующего имени. Именам внутри объекта СЛЕДУЕТ (SHOULD) быть уникальными.

object = begin-object [ member *( value-separator member ) ]
               end-object

      member = string name-separator value

Объект с уникальными именами совместим в том смысле, что все принимающие его программные реализации одинаково определят соответствия имён и значений. Если имена не уникальны, поведение принимающего программного обеспечения непредсказуемо. Многие реализации возвращают только последнюю пару «имя/значение». Другие сообщают об ошибке либо не могут разобрать объект, а некоторые возвращают все пары, включая дубликаты.

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

5. Массивы

Массив представляется квадратными скобками, окружающими ноль или более значений, также называемых элементами. Элементы разделяются запятыми.

array = begin-array [ value *( value-separator value ) ] end-array

Требования, чтобы значения в массиве были одного типа, нет.

6. Числа

Представление чисел аналогично используемому в большинстве языков программирования. Число представляется десятичными цифрами по основанию 10. Оно содержит целую часть, перед которой может стоять необязательный знак минус и за которой могут следовать дробная часть и/или экспонента. Ведущие нули не допускаются.

Дробная часть — десятичная точка, за которой следует одна или более цифр.

Экспонента начинается с буквы E в верхнем или нижнем регистре, за которой может следовать знак плюс или минус. После E и необязательного знака следует одна или более цифр.

Числовые значения, которые невозможно представить приведённой ниже грамматикой, например Infinity и NaN, не допускаются.

number = [ minus ] int [ frac ] [ exp ]

      decimal-point = %x2E       ; .

      digit1-9 = %x31-39         ; 1-9

      e = %x65 / %x45            ; e E

      exp = e [ minus / plus ] 1*DIGIT

      frac = decimal-point 1*DIGIT





      int = zero / ( digit1-9 *DIGIT )

      minus = %x2D               ; -

      plus = %x2B                ; +

      zero = %x30                ; 0

Спецификация разрешает реализациям ограничивать диапазон и точность принимаемых чисел. Поскольку программное обеспечение, реализующее числа IEEE 754 binary64 двойной точности [IEEE754], общедоступно и широко используется, хорошая совместимость достигается реализациями, не ожидающими большей точности или диапазона: они приближают числа JSON в пределах ожидаемой точности. Число JSON вида 1E400 или 3.141592653589793238462643383279 может указывать на возможные проблемы совместимости, поскольку предполагает, что создавшее его программное обеспечение ожидает от получателя большей величины и точности чисел, чем обычно доступно.

При использовании такого программного обеспечения целые числа в диапазоне [−(2**53)+1, (2**53)−1] совместимы в том смысле, что реализации точно совпадут в определении их числовых значений.

7. Строки

Представление строк аналогично соглашениям семейства языков C. Строка начинается и заканчивается кавычками. Между ними могут находиться любые символы Unicode, кроме символов, которые ОБЯЗАТЕЛЬНО (MUST) экранировать: кавычки, обратная косая черта и управляющие символы от U+0000 до U+001F.

Любой символ может быть экранирован. Если он находится в основной многоязычной плоскости (от U+0000 до U+FFFF), его можно представить шестисимвольной последовательностью: обратная косая черта, строчная буква u и четыре шестнадцатеричные цифры, кодирующие кодовую точку символа. Буквы A–F в шестнадцатеричной записи могут быть прописными или строчными. Например, строку из единственной обратной косой черты можно представить как "\u005C".

Для некоторых часто используемых символов также существуют двухсимвольные экранированные представления. Так, строку из единственной обратной косой черты можно записать короче: "\\".

Символ вне основной многоязычной плоскости экранируется последовательностью из 12 символов, кодирующей суррогатную пару UTF-16. Например, строку из единственного скрипичного ключа (U+1D11E) можно представить как "\uD834\uDD1E".

string = quotation-mark *char quotation-mark

      char = unescaped /
          escape (
              %x22 /          ; "    quotation mark  U+0022
              %x5C /          ; \    reverse solidus U+005C
              %x2F /          ; /    solidus         U+002F
              %x62 /          ; b    backspace       U+0008
              %x66 /          ; f    form feed       U+000C
              %x6E /          ; n    line feed       U+000A
              %x72 /          ; r    carriage return U+000D
              %x74 /          ; t    tab             U+0009
              %x75 4HEXDIG )  ; uXXXX                U+XXXX

      escape = %x5C              ; \

      quotation-mark = %x22      ; "

      unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

8. Вопросы строк и символов

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

Текст JSON, передаваемый между системами, не входящими в замкнутую экосистему, ОБЯЗАТЕЛЬНО (MUST) должен кодироваться в UTF-8 [RFC3629].

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

Реализациям ЗАПРЕЩЕНО (MUST NOT) добавлять метку порядка байтов U+FEFF в начало передаваемого по сети текста JSON. Ради совместимости реализациям разбора JSON ДОПУСКАЕТСЯ (MAY) игнорировать присутствие такой метки вместо того, чтобы считать её ошибкой.

8.2. Символы Unicode

Если все строки текста JSON полностью состоят из символов Unicode [UNICODE], независимо от экранирования, текст JSON совместим: все разбирающие его программные реализации одинаково определят содержимое имён и строковых значений в объектах и массивах.

Однако ABNF этой спецификации допускает в именах членов и строковых значениях битовые последовательности, которые не кодируют символы Unicode, например "\uDEAD" — одиночный непарный суррогат UTF-16. Такое наблюдалось, например, когда библиотека обрезала строку UTF-16, не проверяя, не разделяется ли суррогатная пара. Поведение программного обеспечения, получающего тексты JSON с такими значениями, непредсказуемо: реализации, например, могут возвращать разную длину строкового значения или даже сталкиваться с фатальными исключениями во время выполнения.

8.3. Сравнение строк

Программным реализациям обычно требуется проверять имена членов объектов на равенство. Реализации, преобразующие текстовое представление в последовательности кодовых единиц Unicode и сравнивающие их численно, единицу за единицей, совместимы: во всех случаях они одинаково определяют равенство или неравенство двух строк. Например, при сравнении строк без преобразования экранированных символов реализации могут ошибочно считать "a\\b" и "a\u005Cb" неравными.

9. Анализаторы

Анализатор JSON преобразует текст JSON в другое представление. Анализатор JSON ОБЯЗАН (MUST) принимать все тексты, соответствующие грамматике JSON. Ему ДОПУСКАЕТСЯ (MAY) принимать формы и расширения, не являющиеся JSON.

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

10. Генераторы

Генератор JSON создаёт текст JSON. Результирующий текст ОБЯЗАН (MUST) строго соответствовать грамматике JSON.

11. Вопросы IANA

Медиатип текста JSON — application/json.

Имя типа
application
Имя подтипа
json
Обязательные параметры
Не применимо
Необязательные параметры
Не применимо
Кодирование
Двоичное (binary)
Безопасность
См. RFC 8259, раздел 12
Совместимость
Описана в RFC 8259
Опубликованная спецификация
RFC 8259

Приложения, использующие этот медиатип: JSON применялся для обмена данными между приложениями, написанными на всех следующих языках программирования: ActionScript, C, C#, Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript, Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala и Scheme.

Магические числа
Не применимо
Расширения файлов
.json
Коды типов файлов Macintosh
TEXT
Контакт для дополнительной информации
IESG, <iesg@ietf.org>
Предполагаемое использование
COMMON — общее
Ограничения использования
Отсутствуют
Автор
Douglas Crockford, <douglas@crockford.com>
Орган управления изменениями
IESG, <iesg@ietf.org>

Примечание: параметр «charset» для этой регистрации не определён. Его добавление не влияет на соответствующих спецификации получателей.

12. Вопросы безопасности

Скриптовым языкам в целом присущи вопросы безопасности. JSON — подмножество JavaScript, исключающее присваивание и вызов.

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

13. Примеры

Это объект JSON:

{
        "Image": {
            "Width":  800,
            "Height": 600,
            "Title":  "View from 15th Floor",
            "Thumbnail": {
                "Url":    "http://www.example.com/image/481989943",
                "Height": 125,
                "Width":  100
            },
            "Animated" : false,
            "IDs": [116, 943, 234, 38793]
          }
      }

Его член Image — объект, у которого Thumbnail также является объектом, а IDs — массивом чисел.

Это массив JSON из двух объектов:

[
        {
           "precision": "zip",
           "Latitude":  37.7668,
           "Longitude": -122.3959,
           "Address":   "",
           "City":      "SAN FRANCISCO",
           "State":     "CA",
           "Zip":       "94107",
           "Country":   "US"
        },
        {
           "precision": "zip",
           "Latitude":  37.371991,
           "Longitude": -122.026020,
           "Address":   "",
           "City":      "SUNNYVALE",
           "State":     "CA",
           "Zip":       "94085",
           "Country":   "US"
        }
      ]

Ниже три небольших текста JSON, содержащих только значения:

"Hello world!"
42
true

14. Ссылки

14.1. Нормативные ссылки

   [ECMA-404] Ecma International, "The JSON Data Interchange Format",
              Standard ECMA-404,
              <http://www.ecma-international.org/publications/
              standards/Ecma-404.htm>.

   [IEEE754]  IEEE, "IEEE Standard for Floating-Point Arithmetic",
              IEEE 754.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [UNICODE]  The Unicode Consortium, "The Unicode Standard",
              <http://www.unicode.org/versions/latest/>.

14.2. Информационные ссылки

   [ECMA-262] Ecma International, "ECMAScript Language Specification",
              Standard ECMA-262, Third Edition, December 1999,
              <http://www.ecma-international.org/publications/files/
              ECMA-ST-ARCH/
              ECMA-262,%203rd%20edition,%20December%201999.pdf>.

   [Err3607]  RFC Errata, Erratum ID 3607, RFC 4627,
              <https://www.rfc-editor.org/errata/eid3607>.

   [Err3915]  RFC Errata, Erratum ID 3915, RFC 7159,
              <https://www.rfc-editor.org/errata/eid3915>.







   [Err4264]  RFC Errata, Erratum ID 4264, RFC 7159,
              <https://www.rfc-editor.org/errata/eid4264>.

   [Err4336]  RFC Errata, Erratum ID 4336, RFC 7159,
              <https://www.rfc-editor.org/errata/eid4336>.

   [Err4388]  RFC Errata, Erratum ID 4388, RFC 7159,
              <https://www.rfc-editor.org/errata/eid4388>.

   [Err607]   RFC Errata, Erratum ID 607, RFC 4627,
              <https://www.rfc-editor.org/errata/eid607>.

   [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627,
              DOI 10.17487/RFC4627, July 2006,
              <https://www.rfc-editor.org/info/rfc4627>.

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <https://www.rfc-editor.org/info/rfc7159>.

Приложение A. Изменения относительно RFC 7159

В разделе перечислены изменения между настоящим документом и текстом RFC 7159.

Участники

RFC 4627 написал Douglas Crockford. Настоящий документ создан внесением относительно небольшого числа изменений в тот документ; поэтому подавляющее большинство текста принадлежит ему.

Адрес автора

Tim Bray (редактор)
Textuality
Email: tbray@textuality.com

Перевод: RFCNET · rfcnet.ru

Original copyright notice
Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

























Bray                         Standards Track                    [Page 2]

RFC 8259                          JSON                     December 2017

Неофициальный перевод. При расхождениях см. оригинал.