Инструменты разработчика · JSON форматировщик и валидатор
История стандартов JSON: от RFC от 4627 до RFC 8259 и ECMA-404
· Фон
JSON стандарты проверка
JSON был указан как минимум четыре раза двумя организациями по стандартизации. В этом посте прослеживается путь от json.org Дугласа Крокфорда к RFC 8259 и ECMA-404 и объясняется, что на самом деле изменилось для разработчиков на этом пути.
Какой спецификации соответствует мой парсер?
Какой спецификации следует синтаксический анализатор? Ответ обычно виден по краям, а не в обычных объектах и массивах. Проверьте строку верхнего уровня, например `"ready"`, ведущий знак порядка байтов, повторяющиеся имена элементов и необычно большие числа. В разных документах обсуждаются синтаксис и совместимость на разных уровнях, а реализации добавляют свои собственные типы данных и поведение при ошибках. Именование стандарта полезно только в том случае, если наблюдаемый контракт синтаксического анализатора отделен от предположений о каждой реализации JSON.
Свидетельства репозитория для ToolAcre конкретны и уже, чем общая история стандартов. Средство форматирования использует `JSON.parse` для создания значений и `JSON.stringify` для их вывода; после сбоя анализа локальный сканер предоставляет стабильную диагностическую позицию и причину.
json.org и раннее описание JSON
json.org представил JSON как компактную запись, полученную из синтаксиса объектных литералов JavaScript, и задокументировал его основные структуры с помощью небольшой грамматики. Это раннее описание помогло дать разработчикам общее имя и ссылку для объектов, массивов, строк, чисел, логических значений и значений NULL. Безопаснее назвать эту страницу ранним публичным объяснением, чем утверждать, не приводя здесь исторических свидетельств, что одна страница или человек в одиночку открыли формат или установили его принятие.
Текущие источники репозитория не включают архивную историю json.org, использования браузера или обсуждений в комитетах. Они показывают, как это приложение анализирует и диагностирует JSON сегодня. Соответственно, исторические утверждения в этой статье остаются близкими к устаревшим стандартным документам и избегают объяснения мотивов или рыночных эффектов, которые местные файлы не могут доказать.
RFC 4627 в 2006 — первое описание IETF, тип носителя application/json и правило, согласно которому текст должен быть объектом или массивом
RFC 4627, опубликованный в 2006, описал JSON для обмена через Интернет и зарегистрировал тип носителя `application/json`. Его определение текста JSON требовало объекта или массива на верхнем уровне, даже несмотря на то, что строки, числа и литералы существовали как значения внутри этих контейнеров. Это ограничение представляет собой полезное историческое отличие, поскольку документ, содержащий только `"ready"`, может быть допустимым значением в более поздней формулировке, хотя и выходит за пределы текстового определения JSON RFC 4627.
В документе также обсуждаются проблемы кодирования и безопасности в контексте реализаций, доступных на тот момент. Его не следует рассматривать как журнал изменений для этого репозитория: ToolAcre не содержит режима совместимости RFC 4627, а его путь синтаксического анализатора делегирует создание значений узлу JavaScript.
ECMA-404 в 2013 — минимальный стандарт Ecma, содержащий только синтаксис, и почему две организации в итоге описали один формат
ECMA-404, впервые опубликованный в 2013, определяет синтаксис JSON в намеренно компактной форме. Его основное внимание уделяется грамматике допустимого текста JSON, а не полному профилю обмена для каждого сетевого использования. Эта область применения помогает объяснить, почему документы ECMA-404 и IETF могут описывать одну и ту же базовую нотацию, но при этом различаются рекомендациями по совместимости, которые они подчеркивают. Существование двух органов по стандартизации не означает наличие двух несовместимых форматов при обычном использовании.
Утверждения о том, почему организации выбрали определенные пути публикации, требуют документальных источников, выходящих за рамки этой кодовой базы, поэтому в этой статье мотивы комитета не выводятся из дат стандартов. Соответствующий практический момент заключается в том, что RFC 8259 и ECMA-404 предназначены для согласования синтаксиса, тогда как RFC 8259 предоставляет рекомендации, которые важны для функционального обмена.
RFC 7159 и RFC 8259
RFC 7159 заменил RFC 4627 в 2014 и расширил определение текста JSON до любого сериализованного значения, удалив правило верхнего уровня только для объектов или массивов. RFC 8259 заменил RFC 7159 в 2017 и остается ссылкой IETF, обычно цитируемой для JSON. Он требует UTF-8 для обмена JSON между системами за пределами закрытой экосистемы и записывает предупреждения о совместимости в отношении чисел, повторяющихся имен, символов Юникода и порядка байтов, а не делает вид, что одна только грамматика гарантирует одинаковые результаты везде.
`true` верхнего уровня — это компактный способ соблюдения современного правила корневого значения в ToolAcre, поскольку `JSON.parse` его принимает. Этот результат демонстрирует поведение этой реализации; он не восстанавливает, когда каждый браузер, сервер или API принял более широкое определение.
Что изменилось для работающих разработчиков
Для работающих разработчиков наиболее очевидными изменениями в спецификации являются современное принятие любого значения JSON в корне и более строгие рекомендации по совместимому кодированию. Менее очевидный урок заключается в том, что правильный синтаксис по-прежнему оставляет выбор реализации. Повторяющиеся имена объектов могут быть свернуты, порядок членов не является семантическим контрактом, очень большие числа могут потерять точность, а необычные последовательности Юникода могут по-разному перемещаться по библиотекам. Поэтому документ, соответствующий стандартам, может заслуживать дополнительных ограничений со стороны схемы приложения.
В этом средстве форматирования повторяющиеся имена и числовые токены сначала проходят через `JSON.parse`, поэтому позднее форматирование отражает результирующее значение JavaScript, а не исходный лексический документ. Сканер обеспечивает диагностику после сбоя; он не сохраняет повторяющиеся элементы или числа произвольной точности. Это наблюдения, поддерживаемые репозиторием.
Что это не распространяется
Что это не охватывает, так это спецификации, наложенные поверх JSON. JSON Схема описывает ограничения на форму и значения документа; JSON Указатель указывает на места внутри документа; JSON Патч представляет собой изменения. Они решают различные проблемы базовой грамматики и не должны рассматриваться как более поздние версии самой JSON. JSONC, JSON5 и подобные авторские форматы также расширяют или изменяют принятый синтаксис и требуют собственных синтаксических анализаторов, а не подвергаются строгой проверке молча.
В этой статье также избегается подробная социальная история принятия JSON, поддержки браузеров или конкуренции с XML, поскольку перечисленные источники репозитория не могут подтвердить это повествование. Никакие внешние цитаты не были придуманы, чтобы заполнить этот пробел.
Вывод: RFC 8259 — это ссылка на цитирование.
RFC 8259 — это практичный справочник IETF, на который можно ссылаться для текущего руководства по синтаксису JSON и совместимости, а ECMA-404 обеспечивает согласованный синтаксический стандарт Ecma. RFC 4627 и RFC 7159 остаются полезными для понимания того, как изменилось опубликованное определение, особенно на верхнем уровне. Ссылайтесь на документ, подтверждающий точное утверждение, вместо использования «спецификации JSON» как расплывчатого обращения к авторитету и отличайте нормативные правила от поведения реализации, наблюдаемого в конкретном парсере.
Для ToolAcre оправданным утверждением является то, что репозиторий использует парсер и сериализатор JSON JavaScript и добавляет строгий локальный сканер для диагностики после сбоев. Этот маршрут описывают тесты значений верхнего уровня, неправильной пунктуации и обработки чисел; они не являются историческими источниками.