JSON и YAML: когда конвертировать и что может пойти не так
Где выигрывает JSON, а где YAML, как «проблема Норвегии» портит данные в конфигах и что проверить, прежде чем файл пройдёт путь туда и обратно.
JSON и YAML описывают одно и то же: объекты, массивы, строки, числа, булевы значения, null. У любого корректного JSON-документа есть YAML-эквивалент, и почти любой YAML разворачивается обратно в JSON. Зачем тогда вообще конвертировать? Затем, что машины предпочитают один формат, а люди — другой. Конвертер JSON в YAML работает ровно на этой границе.
Где какой формат выигрывает
JSON — язык API. Он строгий, быстро парсится, и строку в нём можно записать ровно одним способом. Из-за той же строгости его никто не любит править руками: каждая скобка должна закрыться, каждый ключ — стоять в кавычках, а одна лишняя запятая ломает весь файл.
YAML убрал скобки и лишние кавычки, а ещё разрешил комментарии. Последнее важнее, чем кажется. Продакшен-конфиг без единого комментария вида # не опускать ниже 3 — это конфиг, который кто-нибудь сломает через полгода. Манифесты Kubernetes, файлы Docker Compose, workflow GitHub Actions, плейбуки Ansible — всё это YAML, и всё это рассчитано на чтение человеком во время код-ревью.
Типичный сценарий: API отдал JSON, а вам нужно вставить его в values-файл Helm. Или наоборот — есть docker-compose.yml, а скрипт понимает только JSON. Вставили, конвертировали, готово.
Проблема Норвегии
За удобство YAML приходится платить: значения без кавычек интерпретируются. Классический пример — список кодов стран:
countries:
- DE
- FR
- NOПо правилам YAML 1.1 NO разбирается как булево false. Норвегия исчезает из данных, и никто вас не предупредит. В ту же ловушку попадают yes, on, off и номера версий: version: 1.20 молча превращается в число 1.2. Пользователи Kubernetes натыкались на это так часто, что в документации появился отдельный раздел. А почтовые индексы с ведущим нулём старые парсеры читают как восьмеричные числа.
YAML 1.2 почти всё это исправил (булевыми остались только true и false), но многие парсеры до сих пор по умолчанию ведут себя как 1.1. Надёжная привычка: брать в кавычки всё, что лишь похоже на строку. Наш конвертер делает это сам — при переводе JSON в YAML значения вроде "NO", "42" или "1.20" выходят в кавычках и переживают обратное чтение.
Что не переживает путь туда и обратно
Конвертация YAML в JSON теряет часть файла — так устроен формат:
- Комментарии пропадают. В JSON для них просто нет синтаксиса.
- Якоря и ссылки разворачиваются или отклоняются: JSON не умеет выражать «это значение — ссылка на то».
- Порядок ключей и стиль записи (кавычки, блочный или потоковый вид) нормализуются.
Сами данные в безопасности. Но если ваш YAML держится на комментариях, храните оригинал, а не считайте JSON-версию новым источником истины.
Ещё одна вещь, о которую спотыкаются: табуляция. YAML запрещает её в отступах, без исключений. Если редактор вставлял табы, парсер остановится на первом же — конвертер покажет точную строку, что заметно приятнее, чем вглядываться в одинаковые на вид пробелы.
Валидация — незаметная, но главная функция
Половина пользы конвертера в том, что он отказывается принимать битые данные. Вставили манифест Kubernetes и получили ошибку в строке 14? Вы нашли проблему раньше, чем её нашёл kubectl. Конвертер JSON в YAML проверяет оба направления по мере ввода, и всё происходит в браузере. В конфигах часто лежат внутренние хосты и секреты — им незачем ехать на чужой сервер ради переформатирования.
Вставьте свой JSON или YAML в конвертер — и получите второй формат мгновенно: бесплатно, без регистрации, без загрузки на сервер.