Конвертер JSON у YAML

Вставте дійсний JSON — об'єкт, масив, скаляр, відповідь API або повний маніфест Kubernetes — і конвертер виведе еквівалент YAML у реальному часі.

Конвертація виконується повністю у вашому браузері з використанням нативного JSON.parse для перевірки вхідних даних (згідно з ECMA-404 / RFC 8259), після чого обходить розібране дерево, генеруючи синтаксис YAML 1.2.2.

Відступ у 2 пробіли є за замовчуванням — це стандарт де-факто для Kubernetes, Ansible, GitHub Actions та Docker Compose. Перемкніться на відступ у 4 пробіли, якщо цього вимагає ваша кодова база.

Вивід готовий для вставки у файл `.yaml` або передачі через конвеєр до `kubectl apply -f -`. Права панель показує лічильники байтів і рядків у реальному часі, щоб ви могли перевірити розмір перед фіксацією.

Конвертуйте у три кроки:

• Крок 1: Вставте свій JSON в редактор. Конвертер перевіряє дані під час введення — недійсний JSON показує точну помилку парсера з рядком і стовпчиком.
• Kрок 2: Вивід YAML з'являється в реальному часі на правій панелі. Натискати кнопку не потрібно; кожне натискання клавіші оновлює результат.
• Крок 3: Натисніть «Копіювати» (у буфер обміну) або «Завантажити» (файл `.yaml`).

Для програмних робочих процесів та сама логіка доступна через ендпоінт `/api/calculate` — надішліть туди JSON методом POST і отримайте YAML у тілі відповіді.

Безпека зворотного перетворення: конвертуйте YAML назад у JSON за допомогою спорідненого конвертера YAML у JSON; модель даних зберігається точно (коментарі та анкери існують лише в YAML і не переживають зворотне перетворення).

JSON і YAML представляють ту саму модель даних — мапи (об'єкти), послідовності (масиви) та скаляри (рядок/число/булеве значення/null), але з дуже різним поверхневим синтаксисом.

JSON перевантажений фігурними дужками та лапками: кожен ключ береться в `"`, кожна мапа — в `{}`, кожен масив — в `[]`, а кожен розділювач є явним (`:` та `,`). YAML базується на відступах: вкладеність імпліцитно визначається відступом у 2 пробіли, послідовності використовують префікс `- `, а більшість рядків не потребують лапок.

JSON розбирається в 5–10 разів швидше в усіх основних середовищах виконання мов, не має жодної двозначності та є правильним вибором для API, черг повідомлень, потоків логів і форматів зберігання.

YAML підтримує коментарі (`#`), анкери та псевдоніми для повторного використання (`&name` / `*name`), багатодокументні потоки (`---`) та явні теги типів (`!!str`, `!!int`) — переваги, які роблять його правильним вибором для конфігурацій з контролем версій, конвеєрів CI/CD, інфраструктури як коду та маніфестів Kubernetes.

Обирайте JSON для машин, YAML — для людей, і конвертуйте між ними на межі систем.

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

Конвертер рекурсивно обходить розібране дерево JSON:

• Для кожної мапи (об'єкта) ключі виводяться у порядку їх джерела з синтаксисом `key: value`; вкладені значення отримують додатковий відступ у 2 пробіли.
• Для кожної послідовності (масиву) елементи використовують префікс `- `; вкладені об'єкти під дефісом починаються на тому ж рядку, що й дефіс, і успадковують наступний рівень відступу.

Змішані структури — масиви об'єктів, об'єкти, що містять масиви об'єктів рекурсивно — відображаються коректно. Максимальна глибина обмежена лише стеком викликів вашого браузера (~10 000+ кадрів у сучасних браузерах, що набагато перевищує будь-яку реальну конфігурацію).

Протестуйте на власних даних: розберіть вихідний YAML назад у JSON та переконайтеся у структурній рівності з вхідними даними.

Маніфести Kubernetes є найпоширенішим варіантом використання цього конвертера. Багато інструментів (kubectl, Lens, k9s, Helm) виводять JSON за допомогою прапорців `-o json`; канонічним форматом джерела істини, який фіксується в Git, є YAML.

Вставте вихідний JSON від `kubectl get deployment -o json`, і конвертер створить чистий маніфест, готовий до коміту. Ієрархії apiVersion, kind, metadata та spec зберігають точний порядок полів.

Для значень чартів Helm вставте свої значення JSON і додайте YAML у файл `values.yaml` — шаблони Helm сприймуть їх без змін. Для оверлейних файлів Kustomize конвертуйте ваш об'єкт патча та додайте його до списку `patchesStrategicMerge`.

Перевірте вивід за допомогою `kubectl apply --dry-run=client -f file.yaml` перед комітом — це виявить проблеми на рівні схеми, які сама лише перевірка синтаксису YAML пропустить.

Docker Compose файли — це чистий YAML, який відповідає специфікації Compose (compose-spec.io). Коли у вас є програмний вивід JSON — із генератора конфігурації, попереднього експорту Compose v2 або скрипта шаблонізації — конвертуйте його тут і вставте в `docker-compose.yaml`.

Кореневі ключі (`services`, `networks`, `volumes`, `configs`, `secrets`) та їх вкладені специфікації (image, ports, environment, depends_on, healthcheck) конвертуються правильно.

Зверніть увагу на порти: короткі рядки на кшталт `"8080:80"` мають залишатися в лапках у YAML, щоб запобігти їх парсизму як шістдесяткового числа — конвертер обробляє це автоматично.

Здійснюйте перевірку за допомогою `docker compose config` перед `docker compose up`; ця команда парсить, об'єднує кілька файлів і виводить остаточну конфігурацію саме так, як її запустить рушій.

Правила відступів у YAML суворі: 2 пробіли на рівень (4 також допустимі, але рідко), табуляція заборонена, а сусідні ключі мають точно вирівнюватися. Послідовності (`- item`) та мапи (`key: value`) можуть вкладатись довільно.

Багаторядкові рядки бувають двох видів: буквальні блоки (`|`) зберігають кожен перенос рядка; згорнуті блоки (`>`) об'єднують рядки за допомогою пробілів (у стилі абзаців).

Анкери (`&name`) та псевдоніми (`*name`) дозволяють визначити вузол YAML один раз і повторно використати його в іншому місці — це часто застосовується у файлах Compose для спільних шаблонів сервісів.

Експліцитні теги типів (`!!str`, `!!int`, `!!bool`, `!!null`) перевизначають автотипування YAML, коли вам потрібен рядок, що виглядає як число, або навпаки.

Конвертер автоматично бере в лапки неоднозначні рядки: `"yes"`, `"no"`, `"null"`, `"~"`, значення, схожі на числа, як-от `"01234"`, та будь-який рядок, що містить спеціальні символи YAML (`:`, `#`, `-`, `&`, `*`, `!`, `|`, `>`, `'`, `"`, `%`, `@`).

Шість помилок становлять 95% зламаного YAML у реальних проєктах.

• (1) Табуляція будь-де — навіть один символ табуляції ламає парсинг. Налаштуйте свій редактор на вставку пробілів.
• (2) Невідповідні відступи — сусідній ключ, зміщений на один стовпець, викликає помилку парсингу.
• (3) Відсутність пробілу після `:` — `key:value` є недійсним; `key: value` є правильним.
• (4) Неозначені в лапках рядки, схожі на булеві значення (`yes`, `no`, `on`, `off`) — у YAML 1.1 (старіші парсери) вони перетворюються на true/false. YAML 1.2 звузив булеві значення лише до `true`/`false`, але захисні лапки все одно будуть доречними.
• (5) Числові рядки без лапок — `01234` стає цілим числом 1234, втрачаючи початковий нуль.
• (6) Відсутність пробілу після `-` — `-item` це рядок, що починається з дефіса; `- item` є елементом послідовності.

Здійснюйте перевірку за допомогою `yamllint`, розширення YAML у VS Code або спеціалізованих валідаторів (`kubectl --dry-run`, `docker compose config`, `ansible-playbook --syntax-check`).

Робочі процеси API виграють від конвертації з JSON у YAML у двох випадках.

По-перше, специфікації OpenAPI 3.x зазвичай створюються у форматі YAML (він більш зручний для читання для дерев шляхів/параметрів), але експортуються як JSON для інструментів — конвертуйте в будь-якому напрямку, як вимагає ваш процес редагування. Конвертер зберігає обов'язкові поля, визначення схем, покажчики $ref та приклади тіл.

По-друге, під час документування API вставте зразок відповіді JSON і покажіть версію YAML у вашій документації — читачам буде легше переглядати глибоко вкладені тіла відповідей.

Для інтеграції зі Swagger UI приймаються як `swagger.yaml`, так і `swagger.json`; багато команд зберігають YAML у системі контролю версій і генерують JSON під час збирання. Безпека двостороннього перетворення зберігається для специфікацій OpenAPI, оскільки вони не використовують коментарі чи анкери в канонічній формі.

Майже кожна сучасна платформа CI/CD використовує YAML для визначення конвеєрів:

• GitHub Actions (`.github/workflows/*.yaml`)
• GitLab CI (`.gitlab-ci.yml`)
• CircleCI (`.circleci/config.yml`)
• Travis (`.travis.yml`)
• Drone
• Concourse
• Argo Workflows
• Tekton

Коли у вас є конфігурація у форматі JSON — із генератора, попереднього експорту системи контролю версій чи програмного конструктора — вставте її сюди та згенеруйте YAML.

Плейбуки Ansible за своєю суттю спираються на структуру завдань у форматі YAML із використанням анкерів для повторно використовуваних блоків; конвертер виводить послідовності акуратно, тож ви можете вставити їх під `tasks:` без додаткових редагувань.

Для GitHub Actions найскладнішою частиною є умови `if:` та стратегії матриць — збережіть конвертований YAML, а потім додайте коментарі, що пояснюють призначення (функція, доступна лише в YAML, яку ви втратите, якщо повернетеся до JSON).

П'ять крайових випадків ламають примітивні конвертери.

• (1) Коментарі: у JSON їх немає, YAML підтримує `#`. Двостороннє перетворення JSON → YAML → JSON є без втрат, але YAML → JSON → YAML видаляє кожен коментар. Зберігайте YAML як джерело істини, коли коментарі мають значення.
• (2) Булеве приведення: застарілі парсери YAML 1.1 сприймають `yes`/`no`/`on`/`off` як булеві значення. Сучасні парсери (1.2.2) сприймають так лише `true`/`false`, але захисні лапки запобігають несподіванкам.
• (3) Null: JSON `null` мапиться на YAML `null`, `~` або порожнє значення. Конвертер виводить `null` для ясності; деякі інструменти віддають перевагу порожньому значенню (`key:`), але воно може бути неоднозначним у поєднанні з порожніми рядками.
• (4) Числові рядки: `"01234"` (поштовий індекс США) втрачає початковий нуль, якщо в YAML немає лапок — конвертер додає їх.
• (5) Числа з плавною комою з нулями в кінці: `1.50` після зворотного перетворення стає `1.5`, оскільки і JSON, і YAML використовують канонічне числове представлення. Якщо кінцеві нулі мають значення (валюта, рядки версій), серіалізуйте їх як рядки.

Мапінг типів з першого погляду:

• JSON об'єкт → YAML мапа (блочний стиль)
• JSON масив → YAML послідовність (елементи з `-`)
• JSON рядок → YAML рядок (автоматично в лапках, якщо є неоднозначність)
• JSON число → YAML скаляр із тим самим числовим значенням
• JSON true/false → YAML true/false
• JSON null → YAML null

Вибір стилю:

• віддавайте перевагу блочному стилю (багаторядковий, з відступами) заради читабельності, а не потоковому стилю (`{key: value, ...}`, компактному в стилі JSON)
• завжди використовуйте відступи у 2 пробіли
• виводьте ключі в порядку їх появи у джерелі (відповідає поведінці JSON)

Поради щодо зворотного перетворення:

• (1) JSON → YAML → JSON відбувається без втрат.
• (2) YAML → JSON видаляє коментарі, анкери (розгорнуті), експліцитні теги, багатодокументні потоки.
• (3) Завжди беріть у лапки рядки, які виглядають як булеві значення, null або числа.
• (4) Тестуйте свій вивід за допомогою фактичного інструменту, який його використовує (kubectl, docker compose, ansible-playbook) — вони мають суворішу перевірку, ніж загальні парсери YAML.
• (5) Зберігайте обидві версії в системі контролю версій, якщо ваша команда використовує обидва формати; вважайте один із них канонічним (зазвичай YAML для конфігурацій, JSON для API) і генеруйте інший під час збирання.