Конвертувати між JSON та YAML
- Панель керування
- Документація
- API
Для чого цей конвертер 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% коротша за символами, допускає коментар на початку і читається як список властивостей без синтаксичного шуму.
Як користуватися конвертером
Кроки для конвертації даних:
- Вставте вихідний документ (JSON або YAML) у поле введення.
- Виберіть потрібний напрямок конвертації (JSON у YAML або YAML у JSON).
- Натисніть кнопку конвертації: відформатований результат з'явиться у полі виводу.
- Перевірте результат, а потім скористайтеся кнопкою копіювання, щоб отримати результат у буфер обміну.
Конвертація виконується локально у браузері або через виділений серверний маршрут залежно від інструменту: жодні конфіденційні дані не зберігаються.
Часті запитання
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