Инструменты разработчика · JSON форматировщик и валидатор
Дублирование ключей в JSON: что позволяет RFC 8259 и что делают парсеры
· Фон
JSON стандарты проверка
Грамматика JSON допускает использование одного и того же ключа дважды, спецификация говорит только, что имена «должны» быть уникальными, а анализаторы расходятся во мнениях относительно того, какое значение выигрывает. В этом посте объясняется, почему это важно для корректности и безопасности.
Какую «роль» прочитал сервер?
Рассмотрим `{"role":"viewer","role":"editor"}`. Оба члена грамматически полны, поэтому ToolAcre сообщает о допустимом JSON. Когда текст достигает `JSON.parse`, результирующий объект имеет одно свойство `role`, значение которого равно `"editor"`. Более ранний член не сохраняется как скрытая история. Таким образом, успешная проверка синтаксиса ничего не дает о том, появлялись ли имена объектов более одного раза.
Форматирование делает потерю видимой только после того, как она произошла: выходные данные содержат `{"role":"editor"}` в выбранном макете. Он не может воспроизвести отброшенный член `viewer`, поскольку сериализация получает анализируемый объект, а не исходную последовательность членов. Если повторяющиеся имена имеют значение для проверки, сохраните и проверьте исходный текст, прежде чем нажимать «Формат», а не полагайтесь на нормализованный результат.
Грамматика это позволяет, спецификация не поощряет.
RFC 8259 говорит, что имена внутри объекта должны быть уникальными. Это «должно» способствует интероперабельности результатов, не делая уникальность частью базовой грамматики объекта. Повторяющееся имя по-прежнему состоит из допустимой строки, двоеточия и значения в правильной позиции, разделенной запятыми. Следовательно, средство проверки грамматики может принять документ, в то время как политика приложения отклоняет его.
Это различие легко упустить из виду, поскольку многие ошибки являются обязательными синтаксическими ошибками: отсутствующее двоеточие или завершающая запятая вообще не могут образовывать объект JSON. Дубликаты разные. Они создают вопрос совместимости после того, как анализатор распознает каждый токен. ToolAcre намеренно останавливается на синтаксисе и не добавляет правило повторяющегося имени, поэтому его действительный результат не следует рассматривать как гарантию уникальности.
Что делают JSON.parse и ToolAcre
`JSON.parse` использует более позднее вхождение, когда имена объектов повторяются. ToolAcre наследует это поведение, поскольку анализирует перед форматированием. Для `{"limit":10,"limit":25,"unit":"items"}` проверка прошла успешно, предел анализа составляет 25, а форматированный вывод содержит один `limit`. Дополнительная сортировка ключей может изменить положение сохранившегося свойства, но не может выявить перезаписанное вхождение.
Не обобщайте этот результат на каждый парсер или конфигурацию. Некоторые системы могут отклонять дубликаты, а другие стеки обработки могут применять другую политику или проверять токены перед созданием объекта. Правило безопасного межсистемного взаимодействия является узким: повторяющиеся имена не обеспечивают надежного взаимодействия. Если различие имеет значение, проверяйте фактические режимы синтаксического анализатора, используемые на каждой границе, а не полагайтесь на утверждение, распространяющееся на весь язык.
Когда разногласия парсера становятся риском
Дубликаты становятся проблемой безопасности только в конкретном многоэтапном пути, где компоненты интерпретируют один и тот же текст по-разному. Например, фильтр запросов может проверять одно вхождение, пока приложение использует другое. Может ли это произойти, зависит от конкретных парсеров, опций, поведения пересылки и использования полей. Дублирующийся синтаксис сам по себе не может служить обходным путем.
Защитный контроль — установить одну политику на границе доверия и протестировать реальный стек. Отклоняйте повторяющиеся имена перед созданием объекта с потерями, когда двусмысленность недопустима, или обеспечьте, чтобы каждый компонент получал одно и то же уже проанализированное представление. ToolAcre может демонстрировать свое собственное поведение при форматировании, но не может проверять шлюзы, платформы или службы, которые не являются частью инструмента браузера.
Рабочий пример: документ с повторяющимся ключом
Вставьте `{"theme":"light","prefs":{"density":"roomy","density":"compact"},"theme":"dark"}`. ToolAcre принимает текст, поскольку каждый член синтаксически допустим. В результате анализа корневая тема остается как `dark`, а плотность вложенности — как `compact`. При форматировании создается одна копия каждого имени, поэтому оба предыдущих значения исчезают из отображаемого документа.
Этот пример также показывает, почему поиск отформатированного результата происходит слишком поздно. Обнаружение дубликатов должно отслеживать имена членов при чтении исходного потока токенов на каждой глубине объекта. Массивы не нуждаются в правиле повторяющихся имен, хотя отдельные правила приложения могут учитывать повторяющиеся значения элементов. Сохраните исходный код без изменений, запустите для него парсер или линтер, поддерживающий дублирование, и решите, является ли политика предупреждением или отклонением.
Целенаправленное обнаружение дубликатов
Используйте инструменты, которые явно обещают обнаружение повторяющихся имен в источнике JSON. Подходящие подходы включают режим синтаксического анализатора, который дает сбой при повторах, потоковый обработчик токенов, отслеживающий имена для каждого открытого объекта, или линтер с документированным правилом дублирования ключей. Проверьте вложенные объекты и экранированные имена: `"name"` и `"name"` декодируются в одно и то же имя элемента, даже если их исходное написание различается.
JSON Схема не является заменой, если при обычном синтаксическом анализе предыдущие вхождения отброшены. Валидатор схемы обычно получает созданное значение и видит одно свойство, а не дублирующуюся историю токенов. Запустите проверку уникальности до или во время синтаксического анализа, а затем примените проверки схемы к однозначному значению. ToolAcre не выполняет ни обнаружение дубликатов, ни проверку схемы, поэтому оба требуют отдельного, специально созданного шага.
Что это не распространяется
Повторяющиеся имена объектов — это не то же самое, что повторяющиеся значения в записях. `[ {"id":7}, {"id":7} ]` содержит два отдельных объекта, каждый из которых имеет один `id`; при обнаружении повторяющегося идентификатора существует правило набора данных. Аналогично, два элемента массива с одной и той же строкой остаются двумя намеренными позициями, если только в контракте приложения не указано, что массив представляет собой набор.
Эта статья не претендует на универсальную политику «первый победитель», «последний победитель» или «отказ» для широких языковых экосистем. Он записывает наблюдаемое поведение ToolAcre `JSON.parse` и объясняет, почему необходимо напрямую проверить другой компонент. Он также не определяет возможность использования только по дубликату. Влияние на безопасность требует доказательств того, что различные интерпретации пересекают соответствующие границы авторизации, маршрутизации или проверки.
Вывод: действительный JSON не всегда однозначен JSON
Допустимый результат ToolAcre означает, что последовательность токенов является строгой JSON; это не означает, что каждое имя объекта уникально. `JSON.parse` сохраняет последнее значение для повторяющегося имени, а форматирование сериализует только это оставшееся имя. Поскольку более раннее появление удаляется, форматированный вывод не является подходящим свидетельством для определения того, содержал ли исходный источник дубликаты.
Когда уникальность имеет значение, проверьте исходный текст с помощью инструментов для обнаружения дубликатов перед обычным анализом или форматированием. После этого примените проверку схемы и домена к полученному однозначному значению. Для проверки безопасности отслеживайте фактический путь запроса и настройки синтаксического анализатора, а не допускайте несогласия. Практическое правило простое: принятие синтаксиса, политика дублирования имен и дальнейшее значение — это отдельные проверки с отдельными доказательствами.