Русский

Инструменты разработчика · Конвертеры синтаксиса

Приведение типа от YAML до JSON: как да, нет и 0777 меняют значение

· Как это работает

ямл JSON форматы данных

YAML скалярные токены, разветвляющиеся на строки, числа, логические значения и ноль
Оригинальная векторная иллюстрация ToolAcre

YAML преобразует скаляры без кавычек в типы, и правила различаются для YAML 1.1 и 1.2. В этом посте показано, как именно преобразователь определяет, является ли значение логическим, целым числом, числом с плавающей запятой или строкой, и как контролировать результат.

Значение, которое вернулось как true — простой скаляр YAML, означавший текст, преобразованный в JSON как логическое значение, и служба, которая затем работала неправильно.

Такое значение, как `NO`, может стать ложным в загрузчике YAML 1.1, но это не то, что поставляется в этом конвертере. Оба варианта ToolAcre используют схемы YAML 1.2, поэтому `NO`, `yes`, `no`, `on` и `off` остаются строками. Исправленное открытие имеет значение, потому что пример, утверждающий, что эта панель превращает `NO` в истинное или ложное, покажет противоположное ее протестированному поведению.

Типовые сюрпризы все еще существуют. В схеме JSON по умолчанию `null` имеет значение null, а `~` — пустое значение и `0o755` остаются строками. Выбор Core изменяет эти три формы на null, null и 493. Вывод полезен именно потому, что он предоставляет разрешенное значение JavaScript, а не делает вид, что каждый простой токен YAML имеет очевидный тип.

Значение, которое оставалось текстом под YAML 1.2.

Неявное разрешение происходит, пока js-yaml читает исходный код. Выбранная ограниченная схема решает, соответствует ли простой скаляр нулевой, логической или числовой форме, прежде чем преобразователь запишет JSON. Заключение в кавычки обходит это решение: `"0o755"` является текстом в любой схеме, а блочный скаляр остается строкой, включая разрывы строк, представленные индикатором прерывания.

Это синтаксический анализ и сериализация, а не замена регулярных выражений. Программа чтения создает строки, числа, логические значения, значения NULL, массивы и объекты; `JSON.stringify` затем выдает эти значения с выбранным отступом. Комментарии и написание токенов уже отсутствуют на этапе записи, поэтому никакой сериализатор не может восстановить, было ли число изначально десятичным или записано в другой принятой нотации YAML.

Правила YAML 1.1 — логические значения yes/no/on/off, 0777 как восьмеричные, 1:30 как шестидесятеричные, а строки версии, такие как 1.10, читаются как числа с плавающей запятой.

В схеме перечислены YAML 1.1 приведения, такие как шестидесятеричное время и устаревшее восьмеричное число. Они представляют собой серьезную угрозу совместимости, но здесь они недоступны. ToolAcre намеренно не предлагает схему 1.1. Его пользовательский интерфейс говорит, что ни одна из поставляемых опций не читает `NO` как ложь, и тесты закрепляют этот код страны и слова «да», «нет», «включено» и «выключено» в виде строк.

Эта граница меняет метод отладки. Если другое приложение преобразует эти слова в логические значения, сравните конфигурацию его анализатора с ToolAcre вместо того, чтобы ожидать идентичного результата. Преобразователь может показать, что производят две его схемы; он не может сертифицировать схему или версию, используемые средством запуска CI, платформой или системой развертывания, которые позже используют файл.

YAML 1.1 принуждения — это опасности, которых этот преобразователь избегает

Схема JSON по умолчанию принимает только скалярные варианты написания, совместимые с моделью JSON. В Core добавлены знакомые нулевые формы YAML, шестнадцатеричные и восьмеричные целые числа, Infinity и NaN. Ядро по-прежнему остается внутри ограниченного загрузчика: специфичные для языка теги объектов, даты, наборы, упорядоченные карты и двоичные теги скорее отклоняются, чем создаются.

Бесконечность и NaN открывают еще одну границу. JavaScript может хранить их, но JSON не может их записывать. Преобразователь идентифицирует каждый путь и предупреждает, что значение становится нулевым. Это допустимый шаг с потерями, а не преобразование без потерь. Заключенный в кавычки `.inf` позволяет избежать этого, поскольку значением тогда остается литеральная строка `.inf`.

Две поставляемые схемы YAML 1.2 отличаются только документированными скалярными формами.

Вставьте `tilde: ~`, `empty:`, `octal: 0o755`, `country: NO` и `answer: yes`. Если выбран строгий режим, значения JSON будут `"~"`, `""`, `"0o755"`, `"NO"` и `"yes"`. При выборе Core изменяются только первые три: тильда и пустое значение становятся нулевыми, а восьмеричное число становится 493. Страна и текст ответа остаются в обоих выходных данных.

Теперь укажите каждое значение и повторите. Обе схемы возвращают строки, поскольку в источнике указан предполагаемый тип. Такое сравнение является точным с точки зрения кода и более полезно, чем сопоставление YAML 1.1 с 1.2 внутри инструмента, который никогда не загружает 1.1. Он также предоставляет возможность проверки другого парсера без догадок только на основе его документации.

Рабочий пример: один файл в строгой и базовой схемах ToolAcre.

Явные стандартные теги принимаются только в том случае, если ограниченная схема их распознает: `!!str 123` становится строкой `123`, а `!!int "7"` становится числом 7. Такие теги, как `!!binary`, `!!timestamp`, `!!set`, `!!js/function` и конструкторы объектов Python, отклоняются. Это предотвращает превращение считывателя YAML в фабрику произвольных объектов.

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

Что здесь не распространяется — анализ результирующего JSON на уровне приложения, который может снова привести типы (например, строку «1» к номеру).

Код приложения может снова принудительно использовать полученный JSON. API может прочитать `"1"` и преобразовать его в число или отклонить его по схеме. Преобразователи синтаксиса останавливаются после создания текста JSON; он не запускает валидатор инфраструктуры, загрузчик переменных среды или бизнес-правила. Таким образом, чистое преобразование подтверждает синтаксис и сопоставление, а не принятие конечным сервисом.

Дублирование ключей YAML — это отдельная проблема. ToolAcre сохраняет последнее значение и сообщает повторяющийся ключ с позицией. Потоки нескольких документов становятся массивами. Этот выбор может изменить то, что видит приложение, даже если ожидается каждый скалярный тип, поэтому читайте предупреждения, а не судите только по отформатированному телу JSON.

Вывод: цитируйте все, что машина может неправильно прочитать, и как преобразование YAML в JSON в браузере показывает, что именно решает каждый скаляр.

Заключите в кавычки текст, похожий на машинный токен, затем проверьте типы JSON. Используйте strict, если вам нужен наименьший скалярный словарь в форме JSON; сознательно выбирайте Core, когда требуются YAML нулевые и числовые формы. Ни один из вариантов не является YAML 1.1, и ни один из них не заставляет нижестоящего потребителя следовать тем же правилам.

Панель делает выбор синтаксического анализатора видимым и возвращает предупреждения для значений, которые ни одна цель не может представить. Это честное обещание: оно показывает, как эта реализация разрешает каждый скаляр. Он не претендует на универсальное поведение YAML и не сохраняет комментарии, теги и правописание в течение всего пути.