Инструменты разработчика · JSON форматировщик и валидатор
Почему завершающая запятая нарушает JSON и куда указывает валидатор
· Как это работает
JSON рабочий процесс разработчика проверка
Завершающая запятая — это самая распространенная ошибка JSON, и ошибка никогда не попадает в саму запятую. Узнайте, что грамматика ожидает после запятой и как читать сообщаемую позицию.
Односимвольная ошибка, на поиск которой уходит десять минут
Односимвольная ошибка, поиск которой занимает десять минут — конфиг, отредактированный вручную, запятая, оставленная после последнего свойства, и сборка, которая не удалась. Строгий синтаксический анализатор следует последовательности токенов, фактически присутствующей в документе. Рассмотрим объект, заканчивающийся на `'enabled': true,`, и массив, заканчивающийся на `'blue',`: оба разделителя обещают другой элемент, даже если следующий токен закрывает контейнер.
ToolAcre не получает местоположение из сообщения движка браузера. JSON.parse сначала определяет достоверность; только после сбоя сканер репозитория просматривает текст и сообщает о первом недопустимом символе. Для завершающей запятой этим символом является закрывающая скобка или квадратная скобка, а в причине явно указано «Конечная запятая». В объекте отсутствует другое имя члена в кавычках; в массиве отсутствует еще одно полное значение.
Что говорит грамматика JSON после запятой
Что говорит грамматика JSON после запятой — RFC 8259 использует запятые для разделения значений в массивах и членов объектов. Поэтому разделителю необходим действительный элемент с каждой стороны. После запятой объекта анализатор ожидает имя в двойных кавычках, двоеточие и значение. После запятой массива ожидается любое допустимое значение JSON. Закрывающий разделитель не удовлетворяет ни одной продукции.
Разделитель располагается между двумя членами или элементами, а не после последнего. Удаление последней запятой не меняет значения или порядка; он восстанавливает грамматику, которая закрывает контейнер сразу после его конечного значения. Именно поэтому запятая может без проблем появляться после каждого предыдущего элемента: за каждой из этих запятых следует следующий элемент, который она обещает.
Почему ошибка возникает в закрывающей скобке
Почему ошибка попадает в закрывающую скобку — запятая в середине контейнера допустима, поэтому синтаксический анализатор не может отклонить ее просто так. Он использует разделитель и меняет состояние, ожидая другого имени или значения. Противоречие становится очевидным только тогда, когда вместо него поступает `}` или `]`. В этом разделителе обещанный элемент отсутствует, хотя предыдущая запятая вызвала переход состояния.
Таким образом, сообщаемый разделитель является свидетельством состояния анализатора, а не предложением удалить фигурную скобку или квадратную скобку. Прочитайте один жетон слева. Если этот токен представляет собой запятую и разделитель закрывает тот же контейнер, удалите запятую и сохраните закрытие. Сканер ToolAcre называет условие с запятой и предоставляет исходную позицию после того, как JSON.parse отклоняет документ.
JavaScript, Python и современные линтеры это позволяют, JSON нет
JavaScript, Python и современные линтеры позволяют это, JSON нет — литералы исходного языка часто допускают запятую после последнего элемента, поскольку это упрощает просмотр переупорядоченных строк и будущих дополнений. Форматировщики могут даже вставить или сохранить этот стиль. Эти удобства присущи каждой языковой грамматике. Литерал объекта `.js` или словарь Python могут быть допустимым источником, в то время как тот же видимый знак пунктуации остается недействительным в документе RFC 8259 JSON.
Следовательно, редактор, настроенный для JavaScript, может не показывать предупреждение, когда вставленный фрагмент заканчивается запятой. Анализатор назначения по-прежнему контролирует принятие. Используйте языковой режим JSON для текста `.json` и проверьте точную полезную нагрузку, отправленную в API или поле конфигурации. Снисходительность в исходном файле, линтере или парсере JSON5 не является передаваемым свидетельством строгого потребителя JSON.
Рабочий пример: три запятые в конце в одном файле
Рабочий пример: три конечные запятые в одном файле — предположим, `features` заканчивается на `"beta",`, содержащий его объект заканчивается на `"enabled": true,`, а второй корневой элемент имеет ту же ошибку. Первая проверка останавливается на закрывающей скобке после `beta`. Удаление этой запятой позволяет продолжить анализ до тех пор, пока не появится закрывающая скобка после `true`, а восстановление второго местоположения не выявит оставшуюся ошибку объекта корневого уровня.
Такая последовательность ожидаема, поскольку анализаторы обычно сообщают о первой точке, где продолжение невозможно, а не о каждом последующем дефекте. Сопоставьте каждую строку и столбец с закрывающим разделителем, проверьте разделитель непосредственно перед ним, внесите одно намеренное изменение и снова запустите проверку. Не удаляйте сразу все запятые: разделители между фактическими соседями необходимы. Повторная проверка позволяет отличить три недопустимые конечные запятые от допустимых запятых в одном и том же документе.
Варианты, которые вызывают ту же ошибку
Варианты, которые приводят к связанным ошибкам разделителя — запятая в начале, две запятые подряд и запятая после корневого значения, — все они неправильно используют один и тот же символ, но нарушают разные состояния синтаксического анализа. Слева от ведущей запятой нет завершенного элемента. Последовательные запятые не оставляют элементов между разделителями. Запятая после полного корневого значения появляется после того, как текст JSON уже достиг допустимого конца.
Эти случаи не должны автоматически обозначаться запятыми. Точная причина зависит от позиции и состояния контейнера. Внутри `{"a":1,,"b":2}` неожиданная вторая запятая, где должно начинаться имя члена в кавычках. В `[ ,1]` первая запятая появляется там, где требуется значение. Проверяйте диагностические и окружающие токены, а не применяйте универсальное правило «удалить предыдущую запятую» вне шаблона закрывающего разделителя.
Что это не распространяется
Чего это не касается — JSON5 и некоторые рабочие процессы JSON с комментариями намеренно допускают конечные запятые. Файл, написанный для одной из этих грамматик, должен использовать заявленный синтаксический анализатор, расширение и инструменты. Обработка его как строгого JSON приведет к ошибкам, отражающим несоответствие формата, а не обязательно авторскую ошибку. И наоборот, принятие его с помощью разрешающего анализатора не делает источник безопасным для отправки в строгую конечную точку JSON.
Изменение парсеров просто для того, чтобы заглушить эту диагностику, меняет принятый язык и может скрыть несовместимость с конечным потребителем. Комментарии, имена без кавычек и строки в одинарных кавычках могут сопровождать конечные запятые в расширенных форматах, создавая дополнительные сбои, когда текст пересекает границу. Сначала подтвердите договор назначения. Если там написано JSON, удалите синтаксис расширения; если там написано JSON5 или JSONC, проверьте с помощью инструмента, который реализует именно этот формат.
Вывод: посмотрите на один жетон слева от сообщаемой позиции.
Вывод: посмотрите на один токен слева от сообщаемой позиции — когда курсор находится под `}` или `]`, предыдущая запятая могла означать член или элемент, который так и не прибыл. Сохраните структурно необходимый закрывающий разделитель и удалите только этот терминальный разделитель. Затем еще раз проверьте весь документ, поскольку первое исправленное место может обнаружить еще одну конечную запятую в более позднем контейнере.
ToolAcre ограничивает круг обязанностей: JSON.parse решает, что документ недействителен, а локальный сканер предоставляет стабильную структурную причину, а также строку и столбец после сбоя. Используйте эту координату для проверки контекста синтаксического анализатора, а не обвиняйте выделенный символ изолированно. Завершающая запятая представляет собой редактирование одного символа, но понимание того, почему ошибка появляется в следующем разделителе, делает один и тот же диагноз надежным для объектов, массивов и глубоко вложенных конфигураций.