Cross-Format Schema Compatibility Checker
Проверить совместимость типов при миграции схемы между JSON, YAML и TOML — null, булевы, даты.
Как это работает
Три факта, которые обычно узнают на практике уже после того, как что-то сломалось: TOML не имеет типа null в принципе — единственный способ выразить отсутствие значения это не указывать ключ вообще, что делает merge-конфликты почти невозможными для nullable полей. YAML 1.1 (тот, что реально парсит большинство библиотек включая PyYAML по умолчанию) трактует Norway, No, off, yes, on как булевы значения без кавычек — знаменитая "норвежская проблема", когда код страны Норвегия ISO NO превращается в false. YAML 1.2, напротив, требует только true/false. Cross-Format Schema Compatibility Checker online проверяет вашу схему данных на такие межформатные ловушки до того, как миграция между JSON, YAML и TOML тихо отъест часть данных или сломает типизацию.
Спросить нейросеть "а будет ли проблема, если я перенесу это поле из JSON в TOML" звучит быстрее, чем разбираться самому, но здесь есть конкретная техническая причина, почему это плохая идея именно для данного класса задач: правильный ответ зависит от точной версии парсера YAML (1.1 или 1.2), точной версии спецификации TOML, и конкретного значения поля — это не вопрос общих знаний, а вопрос детерминированной проверки конкретных данных, которую языковая модель эмулирует статистически, а не вычисляет напрямую, из-за чего для погранично важных полей (например поле has_permission со значением no) ответ может оказаться уверенно неверным.
Инструмент принимает JSON-схему или образец данных и целевой формат, и последовательно проверяет каждое поле на: наличие null-значений при миграции в TOML (где это невозможно выразить нативно), совпадение строк с зарезервированными YAML 1.1 булевыми литералами (yes, no, on, off, y, n среди прочих), корректность сериализации дат между форматами, и потерю различия между целыми и дробными числами там, где формат назначения этого не различает.
Частые вопросы
Что именно значит норвежская проблема в YAML?
YAML 1.1 без явных кавычек распознаёт строки no, off, false как булево false, а yes, on, true как булево true, из-за чего код страны Норвегия ISO 3166 NO при чтении YAML 1.1 парсером превращается в булево false вместо строки, это реальный, задокументированный класс багов, получивший это имя от сообщества.
Как правильно записать поле null при миграции JSON в TOML?
Единственный корректный способ — вообще не включать этот ключ в TOML-документ, если поле логически может быть null, вместо null-значения; попытка присвоить null напрямую приведёт к синтаксической ошибке парсинга, потому что null не входит в спецификацию TOML.
Актуальна ли норвежская проблема ещё, или её уже починили во всех парсерах?
YAML 1.2 спецификация решает эту проблему, ограничивая булевы литералы только true и false, но множество широко используемых библиотек, включая версии PyYAML по умолчанию, всё ещё парсят по правилам YAML 1.1, так что риск остаётся актуальным в зависимости от конкретной библиотеки на принимающей стороне.
Проверяет ли инструмент даты при кросс-форматной миграции?
Да, TOML и YAML оба имеют нативный тип даты и времени, а JSON — нет, при миграции в JSON дата неизбежно становится строкой, а при миграции между TOML и YAML стоит проверить формат представления, потому что не все варианты записи дат совместимы между спецификациями один в один.
Что произойдёт с числом 5.0 при миграции в формат, не различающий int и float?
Зависит от конкретного парсера формата назначения, некоторые сериализаторы округлят видимое представление до 5 без десятичной точки, что при обратной десериализации может привести к тому, что число будет прочитано как целое, а не дробное, инструмент отмечает такие поля как потенциально рискованные для проверки вручную.