Комментарии и лишние запятые: как перенести JSONC в строгий JSON

Конфигурация нормально открывается в редакторе, но API отвергает её как некорректный JSON. Часто причина в режиме редактора: он понимает JSON с комментариями, а принимающая система — только строгий формат. Расширение файла не решает этот вопрос; важен синтаксис, который принимает получатель.

VS Code имеет отдельный режим JSON with Comments для некоторых конфигураций. Он допускает комментарии и завершающие запятые, хотя последние сопровождаются предупреждением. Это поведение редактора, а не универсальное правило всех JSONC-парсеров. Документация VS Code.

Что именно нужно перенести

Учебная конфигурация с комментариями:

{
  // Адрес демонстрационного сервиса
  "url": "https://example.test/a//b",
  "label": "see /* note */",
  "retry": 2,
}

Строгий JSON после осознанного удаления оформления:

{
  "url": "https://example.test/a//b",
  "label": "see /* note */",
  "retry": 2
}

Комментарий перед ключом удалён, финальная запятая после 2 удалена. Последовательности // в URL и /* note */ внутри строки остаются значениями. Это основной риск наивной миграции: текстовые маркеры похожи на комментарии, но находятся внутри кавычек.

Валидатор JSON Neraviko проверяет второй вариант. Он не заявляет поддержку JSONC и не является сервисом удаления комментариев. Операции форматирования и минификации тоже сначала проверяют JSON; удаление пробелов не устраняет комментарий или конечную запятую.

Проверяем перенесённый пример

Этот локальный Python-код разбирает подготовленный строгий документ и проверяет, что содержимое строк сохранено:

import json

source = '''{
  "url": "https://example.test/a//b",
  "label": "see /* note */",
  "retry": 2
}'''
data = json.loads(source)
assert data["url"] == "https://example.test/a//b"
assert data["label"] == "see /* note */"
assert data["retry"] == 2
print("migration check passed")

Результат — migration check passed. Код проверяет итоговую конфигурацию; он не превращается в универсальный JSONC-конвертер. Для большого файла используйте парсер того диалекта, который реально создал источник, и штатную сериализацию строгого JSON. Не придумывайте ещё один диалект через регулярные выражения.

Порядок миграции

Сначала сохраните исходную конфигурацию и выясните, где она используется. Один файл может читаться редактором и отдельным сборщиком с разными настройками. Убедитесь, что переход не изменит работу этих потребителей.

Затем отделите значения от пояснений. При ручной работе удаляйте только комментарии вне строк и финальные запятые непосредственно перед закрывающими скобками. У многострочного комментария должны быть понятны начало и конец. Если закрывающего маркера нет, не принимайте удаление остатка файла за успешное исправление.

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

Если конфигурация генерируется сборкой, ручная правка выгруженного файла может исчезнуть при следующем запуске. Исправляйте штатный этап экспорта и сохраняйте тест с URL и текстовыми маркерами комментариев. Проверяйте, что новый экспорт повторяет требуемые значения, а пояснения остаются в исходной конфигурации. Такое разделение позволяет поддерживать удобный для человека оригинал и строгий документ для машинного потребителя без неявной потери смысла.

Куда деть пояснения

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

Добавление _comment — уже изменение данных. Если схема запрещает дополнительные поля, такой документ будет отклонён. Если приложение сохраняет неизвестные свойства, пояснение может попасть дальше, чем предполагалось. Поэтому перенесите знания в подходящий канал документации, а не вставляйте служебные ключи без согласования.

JSONC, JSON5 и JSON — разные ожидания

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

Обычный JSON не содержит комментарии и завершающие запятые в грамматике. RFC 8259. Не исправляйте данные выключением валидации или включением permissive режима у всех потребителей: это меняет контракт и может скрыть новые ошибки. Переход должен иметь один понятный результат и проверяемую цепочку потребления.

Neraviko обрабатывает ввод на сервере. Для чужой конфигурации сначала замените секретные адреса, токены и идентификаторы на синтетические значения; лимит JSON-операций — 262 144 байта запроса с общими ограничениями API. Успешный разбор безопасного примера позволяет проверить миграцию, сохраняя настоящий исходник в своей доверенной среде.