Конвертувати між JSON та YAML

конвертує JSON у YAML (і навпаки) зі збереженням структури, з настроюваними відступами. Зручно для міграції конфігурації між файлами .json та .yaml

Для чого цей конвертер JSON / YAML?

Цей інструмент перетворює документ YAML у JSON і навпаки, зберігаючи структуру даних (об'єкти, масиви, скалярні типи). Конвертація JSON у YAML або YAML у JSON є поширеною операцією в розробці: генеруємо файл OpenAPI YAML з JSON-специфікації, конвертуємо вивід REST API у YAML для комміту в репозиторій конфігурацій, перекладаємо маніфест Kubernetes YAML у JSON для передачі в kubectl --dry-run=client -o json або узгоджуємо workflow GitHub Actions зі схемою JSON. Загалом, це міст між світом обміну даними (JSON) і світом конфігурацій, що редагуються вручну (YAML).

YAML проти JSON: пряме порівняння

JSON і YAML вирішують схожі завдання, але для різних випадків використання. Наступна таблиця узагальнює основні технічні відмінності, корисні для вибору між ними залежно від контексту.

Критерій JSON YAML
Читабельність для людини Середня (фігурні дужки, лапки скрізь) Висока (відступи, мало пунктуації)
Багатослівність Більш багатослівний Більш лаконічний
Коментарі Не підтримуються Підтримуються (# коментар)
Кілька документів в одному файлі Ні Так, через роздільник ---
Anchors і aliases (повторне використання) Ні Так (&anchor і *anchor)
Система типів Строга (string, number, bool, null, array, object) Неявне приведення (yes, no, null, дати, інтерпретовані скаляри)
Продуктивність парсингу Дуже швидка, нативні парсери скрізь Повільніша, значно ширша граматика
Використання для REST API Фактичний стандарт Рідко
Використання для конфігурацій Рідко (крім package.json, tsconfig.json) Фактичний стандарт (Kubernetes, CI/CD, Ansible)

Коли використовувати JSON?

JSON є незамінним, коли одна програма спілкується з іншою. Типові випадки використання:

  • REST і GraphQL API: payload запиту та відповіді.
  • Обмін даними між мікросервісами та чергами повідомлень.
  • Нативний JavaScript: JSON.parse і JSON.stringify без залежностей.
  • Зберігання в браузері: localStorage, sessionStorage, IndexedDB.
  • AJAX-запити та fetch.
  • Бінарні або потокові варіанти: BSON (MongoDB), JSON Lines (логи, ML-датасети), MessagePack.
  • Конфігурація JS/TS інструментів: package.json, tsconfig.json, composer.json.

Коли використовувати YAML?

YAML є незамінним, коли людина регулярно редагує файл. Типові випадки використання:

  • Docker Compose (docker-compose.yml) і профілі стека.
  • Маніфести Kubernetes (Deployment, Service, Ingress, Helm charts).
  • Playbook Ansible та інвентарі.
  • CI/CD пайплайни: GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines.
  • Специфікації OpenAPI/Swagger та AsyncAPI.
  • Анотована конфігурація застосунків (Symfony, Spring Boot, Rails), де коментарі корисні.
  • Файли, що часто редагуються вручну, де лаконічність і читабельність важливіші за швидкість парсингу.

Поширені пастки у YAML

YAML є більш дозвільним, ніж JSON, що робить його потужним, але підступним форматом. Найпоширеніші пастки:

  • Відступи: табуляція заборонена специфікацією, допустимі лише пробіли. Змішування або зміна кількості пробілів в одному блоці зламує парсинг.
  • Автоматичне приведення скалярів: yes, no, on, off, true, false, null, None, ~ парсяться як булеві або null. Пастка: поштовий індекс 01234 без лапок стає цілим 1234, а назва країни NO (Норвегія) стає false. Завжди беріть у лапки неоднозначні рядки.
  • Багаторядкові рядки: | (block literal) зберігає переноси рядків як є, тоді як > (folded) замінює переноси пробілами. Індикатори chomping - і + налаштовують поведінку кінцевого переносу.
  • YAML 1.1 проти 1.2: версія 1.1 (ще дуже поширена, наприклад PyYAML за замовчуванням) трактує yes/no/on/off як булеві, що було прибрано у версії 1.2. Поведінка також відрізняється для чисел у базі 8.
  • Неявні дати: 2024-01-15 без лапок інтерпретується деякими парсерами як об'єкт дати, а не рядок.

Приклади поруч

Той самий документ, виражений спочатку у JSON, потім у YAML. Проста конфігурація застосунку з залежностями та середовищем:

Версія JSON

{
"name": "cdrn-app",
"version": "1.14.2",
"environment": "production",
"dependencies": {
    "php": "^8.3",
    "symfony/framework-bundle": "^7.0",
    "doctrine/orm": "^3.0"
},
"features": ["cache", "mailer", "queue"],
"debug": false
}

Еквівалентна версія YAML

# Конфігурація застосунку
name: cdrn-app
version: 1.14.2
environment: production
dependencies:
    php: '^8.3'
    symfony/framework-bundle: '^7.0'
    doctrine/orm: '^3.0'
features:
    - cache
    - mailer
    - queue
debug: false

Версія YAML приблизно на 25% коротша за символами, допускає коментар на початку і читається як список властивостей без синтаксичного шуму.

Як користуватися конвертером

Кроки для конвертації даних:

  1. Вставте вихідний документ (JSON або YAML) у поле введення.
  2. Виберіть потрібний напрямок конвертації (JSON у YAML або YAML у JSON).
  3. Натисніть кнопку конвертації: відформатований результат з'явиться у полі виводу.
  4. Перевірте результат, а потім скористайтеся кнопкою копіювання, щоб отримати результат у буфер обміну.

Конвертація виконується локально у браузері або через виділений серверний маршрут залежно від інструменту: жодні конфіденційні дані не зберігаються.

Часті запитання

JSON чи YAML для моїх файлів конфігурації?

Якщо екосистема нав'язує формат (Kubernetes у YAML, package.json у JSON), дотримуйтеся конвенції. Інакше надавайте перевагу YAML для довгих анотованих конфігурацій, які редагуються вручну, і JSON для конфігурацій, що генеруються програмою або споживаються кодом. Наявність корисних коментарів часто є вирішальним аргументом на користь YAML.

Як зберегти коментарі при round-trip YAML -> JSON -> YAML?

Ніяк. JSON не підтримує коментарі: щойно конвертуємо YAML у JSON, коментарі втрачаються безповоротно. Щоб зберегти коментарі при програмних редагуваннях, використовуйте парсер, що зберігає форматування, як ruamel.yaml у Python у режимі round-trip, або повністю уникайте проходження через JSON.

Чому мій файл YAML парситься правильно локально, але падає в prod?

Часті причини: різні версії парсера (YAML 1.1 проти 1.2), табуляція, внесена редактором, значення без лапок, що нагадують булеві (NO, off) або числа (01234), кодування файлу (UTF-8 BOM, що погано оброблюється). Систематично беріть у лапки неоднозначні рядки та фіксуйте версію парсера у проекті.

Чи є JSON підмножиною YAML?

Починаючи з YAML 1.2, так на практиці: кожний валідний документ JSON є валідним документом YAML 1.2. Зворотне невірне: документ YAML, що використовує коментарі, anchors, неявні дати або кілька документів у файлі, не може бути безпосередньо виражений у JSON без втрати інформації.

Які альтернативи JSON і YAML варто знати?

TOML: популярний для конфігурацій (Cargo, pyproject.toml), хороший компроміс між читабельністю і явним типізуванням. INI: дуже простий, але без стандартної вкладеної структури. XML: багатослівний, але залишається актуальним для SOAP і деяких legacy Java-конфігурацій. HCL: використовується Terraform. JSON5 і JSONC: розширення JSON, що дозволяють коментарі та кінцеві коми.

Яка вага YAML проти JSON?

При еквівалентній структурі YAML зазвичай на 15-30% коротший у байтах завдяки відсутності лапок навколо ключів та більшості рядків, а також відсутності фігурних дужок. У мережі (HTTP-транспорт) мінімізований JSON залишається порівнянним, але YAML більш компактний у читабельній версії. Для чистої продуктивності парсингу JSON у кілька разів швидший, що виправдовує його використання для API з великим трафіком.

Приклад запиту

curl -X POST https://cdrn.fr/api/v1/tools/json-yaml-converter/execute \
  -H "Content-Type: application/json" \
  -d '{"json":"...","space_tabulation":1}'

Схема вхідних даних

Поле Тип Обов'язкове За замовчуванням
json text
space_tabulation integer

Точки доступу

  • GET https://cdrn.fr/api/v1/tools - перелічує всі доступні інструменти
  • GET https://cdrn.fr/api/v1/tools/json-yaml-converter - отримує схему цього інструменту
  • POST https://cdrn.fr/api/v1/tools/json-yaml-converter/execute - виконує цей інструмент з JSON-payload