Convertor YAML în JSON

Lipiți un YAML valid — un manifest Kubernetes, fișier Compose, playbook Ansible, specificație OpenAPI sau orice document YAML 1.2 — iar convertorul generează echivalentul JSON în timp real.

Conversia rulează în întregime în browserul dvs. utilizând un parser YAML 1.2, apoi parcurge arborele analizat generând JSON prin JSON.stringify (conform ECMA-404 / RFC 8259).

Alegeți stilul de ieșire:

• 2 spații (implicit, ușor de citit de către oameni)
• 4 spații (pentru unele baze de cod enterprise)
• minificat (API-uri, payload-uri de rețea)

Rezultatul este gata de lipit într-un fișier `.json` sau de transmis prin conductă către `kubectl apply -f -` (care acceptă JSON prin intrarea standard). Panoul din dreapta afișează în timp real numărul de octeți și de linii, astfel încât să puteți verifica dimensiunea înainte de a o salva.

Conversia YAML în JSON presupune trei pași:

• Pasul 1: Lipiți codul YAML în editor. Parserul validează pe măsură ce tastați — YAML-ul invalid afișează eroarea exactă de parsare cu linia și coloana.
• Pasul 2: Ieșirea JSON apare în timp real în panoul din dreapta. Nu este nevoie să faceți clic pe niciun buton; fiecare tastare reanalizează datele.
• Pasul 3: Faceți clic pe Copiere (în clipboard) sau Descărcare (fișier `.json`).

Pentru fluxuri de lucru programatice, aceeași logică este disponibilă prin intermediul punctului final `/api/calculate` — trimiteți YAML prin POST și primiți JSON-ul în corpul răspunsului.

Siguranța conversiei bidirecționale: convertiți JSON înapoi în YAML cu convertorul soră de la JSON la YAML; modelul de date este păstrat exact (comentariile și ancorele sunt specifice YAML și nu supraviețuiesc conversiei complete).

YAML și JSON reprezintă același model de date — hărți (obiecte), secvențe (tablouri) și scalari (șir/număr/bool/null) — dar cu o sintaxă vizuală foarte diferită.

YAML se bazează pe indentare: imbricarea este indicată de o indentare de 2 spații, secvențele folosesc prefixul `- `, iar majoritatea șirurilor nu au nevoie de ghilimele. JSON folosește multe acolade și ghilimele: fiecare cheie are `"`, fiecare hartă are `{}`, fiecare tablou are `[]`, iar fiecare separator este explicit (`:` și `,`).

YAML acceptă comentarii (`#`), ancore și alianțe pentru reutilizare (`&name` / `*name`), fluxuri cu documente multiple (`---`) și etichete de tip explicite (`!!str`, `!!int`) — puncte forte care îl fac alegerea potrivită pentru configurațiile controlate prin surse. JSON se analizează de 5–10 ori mai repede, nu are nicio ambiguitate și este alegerea corectă pentru API-uri și stocare.

Faceți conversia la limită: YAML pentru oameni, JSON pentru mașini.

Imbricarea profundă este domeniul în care conversia din YAML în JSON excelează — urmărirea manuală a indentării la 5+ niveluri este predispusă la erori. Convertorul parcurge arborele YAML analizat în mod recursiv.

• Pentru fiecare hartă bloc, cheile sunt emise în ordinea sursei cu sintaxa JSON `"cheie": valoare`; valorile imbricate primesc acolade `{...}`.
• Pentru fiecare secvență bloc, elementele sunt emise ca tablouri JSON `[...]`; obiectele imbricate sub un `-` devin elemente de tablou `{...}`.

Structurile mixte — secvențe de hărți, hărți care conțin secvențe de hărți, în mod recursiv — se convertesc toate corect. Adâncimea maximă este limitată doar de stiva de apeluri a browserului dvs. (aproximativ 10.000+ cadre în browserele moderne, mult peste orice configurație realistă).

Testați cu propriile fișiere de test: parsați ieșirea JSON înapoi în YAML și verificați egalitatea structurală cu intrarea.

Inferarea relaxată a tipurilor din YAML este sursa multor erori în configurațiile din lumea reală. YAML 1.2 (standardul modern, ținta acestui convertor) a restrâns regulile pentru a fi mai sigur.

• Booleene: DOAR `true` și `false` (indiferent de majuscule/minuscule). YAML 1.1 trata, de asemenea, `yes`/`no`/`on`/`off` ca booleene, ceea ce a stricat în mod celebru configurațiile care conțineau codul de țară al Norvegiei `NO` (convertit în tăcere în `false`) — așa-numita „problemă a Norvegiei”. Majoritatea parserelor moderne (js-yaml, PyYAML 6+, Snakeyaml) folosesc implicit comportamentul 1.2.
• Null: `null`, `~` sau o valoare goală devin toate null în JSON.
• Numere: modelele de cifre care se potrivesc cu sintaxa de numere întregi/zecimale din JSON devin numere în JSON; tot restul rămâne șir de caractere.
• Șiruri: valorile puse între ghilimele rămân întotdeauna șiruri; șirurile numerice, cum ar fi codurile poștale (`"01234"`) și datele din calendar, trebuie puse între ghilimele în YAML pentru a supraviețui conversiei — atunci când o configurație conține o dată pe care ați calculat-o mai întâi cu un calculator de date, încadrați-o între ghilimele pentru ca parserul să o păstreze exact așa cum este, în loc să o convertească automat.

Convertorul respectă cu strictețe aceste reguli.

Kubernetes acceptă atât YAML, cât și JSON prin intermediul serverului său API, kubectl și al bibliotecilor client. Majoritatea echipelor păstrează YAML în sistemul de control al versiunilor (PR-urile sunt mai ușor de revizuit), dar furnizează JSON către instrumentele programatice — controllere custom, conducte GitOps, post-procesoare Helm sau webhooks.

Lipește-ți manifestul (Pod, Deployment, Service, ConfigMap etc.) și copiază rezultatul JSON. Convertorul păstrează ierarhiile apiVersion, kind, metadata și spec în ordinea câmpurilor — Kubernetes se așteaptă la chei în format camelCase, așa că, dacă imporți câmpuri dintr-o sursă cu snake_case, un convertor de majuscule/minuscule ajustează denumirile înainte să le lipești.

Validează cu `kubectl apply --dry-run=client -f -` (care acceptă JSON pe stdin) înainte de a da commit. Pentru manifeste cu mai multe resurse separate prin `---`, separă-le mai întâi în documente individuale — formatul JSON nu are o sintaxă pentru documente multiple.

Trei cazuri de utilizare frecvente în afara Kubernetes:

• Docker Compose: lipește un fișier `docker-compose.yaml` și copiază JSON pentru instrumente precum Kompose (care migrează Compose spre K8s), orchestratori personalizați sau transformări de configurație programatice.
• Ansible: convertește playbook-urile în JSON pentru documentație, integrări CI personalizate sau API-uri REST/GraphQL care stochează definiții de playbook.
• Conducte CI/CD: GitHub Actions (`.github/workflows/*.yml`), GitLab CI (`.gitlab-ci.yml`), CircleCI, Travis — convertește oricare dintre acestea în JSON pentru analiză, editări programatice sau arhivarea jurnalelor de audit. Declanșatoarele lor `cron` programate sunt fixate în UTC, așa că un convertor de fus orar te ajută să nu greșești momentul în care o conductă rulează efectiv în ora ta locală.

Notă: Expresiile Jinja2 (`{{ var }}`), sintaxa de șablon Helm (`{{ .Values.x }}`) și șabloanele similare rămân ca text simplu (string-uri) în JSON — ele nu sunt evaluate de convertor.

Specificațiile OpenAPI 3.x sunt create de obicei în YAML (mai ușor de citit pentru arborii de căi/parametri), dar sunt consumate ca JSON de instrumente mai vechi — versiuni legacy Swagger UI, anumite gateway-uri API enterprise și unii generatori de cod.

Lipește fișierul `openapi.yaml` (sau `swagger.yaml`) și descarcă `openapi.json`. Convertorul păstrează exact pointerii `$ref` (fără rezolvare), definițiile schemelor, exemplele de răspuns și schemele de securitate.

După conversie, validează cu validatorul oficial OpenAPI (Spectral CLI, openapi-cli, swagger-cli) pentru a confirma conformitatea schemei. Multe echipe păstrează YAML în sistemul de control al versiunilor și generează JSON la momentul compilării — atât `swagger.yaml`, cât și `swagger.json` sunt pe deplin echivalente pentru consumatorii de API.

Șase erori reprezintă 95% din eșecurile de parsare YAML:

• Tab-uri oriunde în indentare — YAML interzice complet tab-urile, chiar și un singur caracter de tab întrerupe parsarea.
• Indentare inconsistentă — cheile de pe același nivel trebuie să se alinieze exact pe aceeași coloană.
• Spațiu lipsă după `:` în mapări — `key:valoare` este invalid; `key: valoare` este corect.
• Spațiu lipsă după `-` în secvențe — `-item` este un șir care începe cu cratimă; `- item` este un element de secvență.
• Caractere speciale neîncadrate între ghilimele la începutul unei valori — `@`, `` ` ``, `%`, `*`, `&` necesită ghilimele.
• Funcționalități neacceptate în convertor: ancore (`&name`), aliasuri (`*name`) și fluxuri cu documente multiple (`---`) — pentru acestea, folosește o bibliotecă YAML completă precum js-yaml, PyYAML sau `yq`.

Mesajul de eroare afișează linia și coloana unde a eșuat parsarea.

Trei funcționalități YAML nu au echivalent direct în JSON și necesită un tratament special:

• Ancorele (`&name`) și aliasurile (`*name`) permit YAML să facă referire la un nod și să-l reutilizeze în altă parte — comun în fișierele Compose pentru șabloane de servicii partajate și în CloudFormation pentru parametri partajați. JSON nu are nicio sintaxă de referință, așa că convertorul extinde aliasurile inline (fiecare alias devine o copie completă). Datele sunt păstrate, dar fișierul JSON este mai mare, iar structura de referință partajată se pierde.
• Fluxurile cu documente multiple (separatorul `---`) reprezintă mai multe valori de nivel superior într-un singur fișier — comun pentru gruparea resurselor Kubernetes. JSON are doar valori rădăcină unice per document. Mai întâi, împarte YAML-ul în fișiere separate sau învelește documentele într-un tablou JSON `[doc1, doc2, doc3]`.
• Comentariile (`#`) sunt specifice YAML — sunt eliminate complet în timpul conversiei. Păstrează YAML ca sursă de adevăr dacă comentariile contează.

Cinci aspecte legate de conversia dus-întors pe care orice dezvoltator ar trebui să le cunoască:

• Modelul de date: YAML → JSON → YAML păstrează exact cheile, valorile, tipurile și ierarhia. Datele sunt identice la intrare și la ieșire.
• Comentariile: pierdute pentru totdeauna — JSON nu are nicio sintaxă pentru comentarii. Păstrează YAML ca sursă de adevăr dacă ai documentație în interiorul codului.
• Ancorele/aliasurile: extinse pe drumul spre JSON, nerecreate niciodată la întoarcere. Fișierul YAML rezultat are conținut duplicat acolo unde sursa avea referințe partajate.
• Ordinea cheilor: YAML păstrează ordinea din sursă; convertorul o păstrează până în JSON; conversia înapoi în YAML păstrează aceeași ordine.
• Etichetele de tip (`!!str`, `!!int`) — emise doar atunci când este necesar pentru clarificare. Un șir `"01234"` supraviețuiește conversiei dus-întors deoarece JSON-ul îl păstrează între ghilimele; un YAML neîncadrat între ghilimele `01234` este parsat ca număr întreg și se întoarce ca numărul 1234, pierzând zeroul din față.

Folosește ghilimele pentru valorile ambigue ca măsură de precauție.

Maparea tipurilor dintr-o privire:

• Mapare YAML → Obiect JSON
• Secvență YAML → Tablou JSON
• Scalar YAML (conform inferenței de tip) → Șir / număr / boolean / null JSON
• Etichetă YAML !!str → Șir JSON (forțat)
• YAML null/~/gol → JSON null
• YAML true/false → JSON boolean
• Model de număr întreg YAML → Număr întreg JSON
• Model de număr cu virgulă mobilă YAML → Număr JSON

Compararea instrumentelor:

• acest convertor (browser, instantaneu, fără instalare, 95% din YAML-ul real)
• `yq -o json` (linie de comandă, fișiere mari, interogări JSONPath)
• `js-yaml`/`PyYAML` (bibliotecă completă, ancore și documente multiple acceptate, utilizare programatică)

Bune practici:

• Încadrează întotdeauna valorile ambigue (yes/no/on/off/null/ID-uri numerice) între ghilimele în sursa YAML.
• Folosește indentare de 2 spații (standardul de facto).
• Validează rezultatul JSON în raport cu schema consumatorului tău aval (JSON Schema, OpenAPI, K8s OpenAPI) — erorile de tip apar aici.
• Păstrează YAML ca sursă canonică și regenerează JSON la momentul compilării ori de câte ori este posibil.