Convertor JSON în YAML

Lipiți un cod JSON valid — un obiect, un tablou, un scalar, un răspuns API sau un manifest Kubernetes complet — iar convertorul va genera echivalentul YAML în timp real.

Conversia rulează în întregime în browserul dumneavoastră, utilizând funcția nativă JSON.parse pentru validarea datelor de intrare (conform ECMA-404 / RFC 8259), apoi parcurge arborele parsat generând sintaxa YAML 1.2.2.

Indentarea cu 2 spații este setarea implicită — standardul de facto pentru Kubernetes, Ansible, GitHub Actions și Docker Compose. Comutați la o indentare de 4 spații dacă proiectul dumneavoastră o cere.

Rezultatul este gata de a fi lipit într-un fișier `.yaml` sau trimis direct către `kubectl apply -f -`. Panoul din dreapta afișează în timp real numărul de octeți și de linii, permițându-vă să verificați dimensiunea înainte de salvare.

Conversia se face în trei pași simpli:

• Pasul 1: Lipiți codul JSON în editor. Convertorul îl validează pe măsură ce tastați — un JSON invalid va afișa eroarea exactă de parsare, cu linie și coloană.
• Pasul 2: Rezultatul YAML apare live în panoul din dreapta. Nu este nevoie să apăsați pe niciun buton; fiecare caracter tastat declanșează o nouă randare. La fel de rapid ca atunci când folosiți un calculator ore munca sau vreți să aflați un numar de zile intre doua date, totul se calculează instantaneu.
• Pasul 3: Faceți clic pe Copiere (în clipboard) sau Descărcare (fișier `.yaml`).

Pentru fluxuri de lucru programatice, aceeași logică este disponibilă prin endpoint-ul `/api/calculate` — trimiteți o cerere POST cu JSON și veți primi codul YAML în corpul răspunsului.

Siguranță la conversia dus-întors: puteți converti YAML înapoi în JSON folosind convertorul nostru geamăn YAML în JSON; modelul de date este păstrat cu exactitate (comentariile și ancorele sunt specifice YAML și nu vor supraviețui conversiei înapoi în JSON).

Fie că dezvoltați un calculator putere electrica sau un calculator ritm alergare, alegerea formatului de date potrivit contează. JSON și YAML reprezintă același model de date — map-uri (obiecte), secvențe (tablouri) și scalari (șir de caractere/număr/bool/null) — dar cu o sintaxă vizuală foarte diferită.

JSON folosește intens acolade și ghilimele: fiecare cheie primește `"`, fiecare map primește `{}`, fiecare tablou primește `[]`, iar fiecare separator este explicit (`:` și `,`). YAML se bazează pe indentare: structurarea imbricată este sugerată de indentarea cu 2 spații, secvențele folosesc prefixul `- `, iar majoritatea șirurilor de caractere nu au nevoie de ghilimele.

JSON se parsează de 5–10 ori mai rapid în toate mediile de rulare majore, are ambiguitate zero și este alegerea corectă pentru API-uri, cozi de mesaje, fluxuri de loguri și formate de stocare.

YAML acceptă comentarii (`#`), ancore și aliasuri pentru reutilizare (`&name` / `*name`), fluxuri multi-document (`---`) și etichete explicite de tip (`!!str`, `!!int`) — avantaje care îl fac alegerea ideală pentru fișiere de configurare versionate, fluxuri CI/CD, infrastructură ca cod (IaC) și manifeste Kubernetes.

Alegeți JSON pentru mașini, YAML pentru oameni și convertiți între ele la granița dintre sisteme.

Imbricarea profundă este locul în care conversia JSON în YAML își dovedește cu adevărat utilitatea — urmărirea manuală a acoladelor și a indentării la peste 5 niveluri este extrem de predispusă la erori. La fel de precis ca un algoritm pentru calcul zodie sau unul care îți spune exact cati ani am, convertorul parcurge arborele JSON în mod recursiv:

• Pentru fiecare map (obiect), cheile sunt generate în ordinea din sursă, folosind sintaxa `cheie: valoare`; valorile imbricate sunt indentate cu încă 2 spații.
• Pentru fiecare secvență (tablou), elementele folosesc prefixul `- `; obiectele imbricate sub un `-` încep pe aceeași linie cu cratima și moștenesc următorul nivel de indentare.

Structurile mixte — tablouri de obiecte, obiecte care conțin tablouri de obiecte în mod recursiv — se randează corect. Adâncimea maximă este limitată doar de stiva de apeluri a browserului dumneavoastră (~10.000+ cadre în browserele moderne, mult peste orice fișier de configurare real).

Testați cu propriile date: parsați rezultatul YAML înapoi în JSON și verificați egalitatea structurală cu datele de intrare.

Manifestele Kubernetes reprezintă cel mai frecvent caz de utilizare pentru acest convertor. Multe instrumente (kubectl, Lens, k9s, Helm) generează JSON prin parametrii `-o json`; totuși, formatul canonic salvat în Git este YAML. La fel cum un calculator volum apa sau un calculator fractii oferă rezultate exacte bazate pe formule stricte, acest convertor respectă cu precizie structura Kubernetes.

Lipiți rezultatul JSON al comenzii `kubectl get deployment -o json`, iar convertorul va genera un manifest curat, gata de a fi salvat. Ierarhiile apiVersion, kind, metadata și spec își păstrează ordinea exactă a câmpurilor.

Pentru valorile chart-urilor Helm, lipiți valorile JSON și introduceți codul YAML rezultat în `values.yaml` — șabloanele Helm îl vor prelua neschimbat. Pentru overlay-uri Kustomize, convertiți obiectul de patch și adăugați-l în lista `patchesStrategicMerge`.

Validați rezultatul cu `kubectl apply --dry-run=client -f fisier.yaml` înainte de a-l salva în Git — această comandă va depista problemele la nivel de schemă pe care o simplă validare sintactică YAML le-ar putea omite.

Fișierele Docker Compose sunt în format YAML pur, conform specificației Compose (compose-spec.io). Atunci când aveți un output JSON generat programatic — de la un generator de configurări, un export anterior din Compose v2 sau un script de șabloane — convertiți-l aici și lipiți-l în `docker-compose.yaml`.

Cheile de nivel superior (`services`, `networks`, `volumes`, `configs`, `secrets`) și specificațiile lor imbricate (image, ports, environment, depends_on, healthcheck) se convertesc corect.

Atenție la porturi: șirurile scurte precum `"8080:80"` trebuie să rămână între ghilimele în YAML pentru a preveni interpretarea lor ca număr sexagesimal — convertorul se ocupă de acest lucru în mod automat.

Validați cu `docker compose config` înainte de `docker compose up`; acesta analizează sintaxa, îmbină mai multe fișiere și afișează configurația finală exact așa cum o va rula motorul Docker.

Regulile de indentare în YAML sunt stricte: 2 spații pe nivel (4 sunt de asemenea permise, dar rare), tab-urile sunt interzise, iar cheile de pe același nivel trebuie să fie aliniate perfect. Secvențele (`- item`) și hărțile (`key: value`) pot fi imbricate liber.

Șirurile multilinie sunt de două tipuri: blocuri literale (`|`) care păstrează fiecare linie nouă; blocuri pliate (`>`) care unesc liniile cu spații (în stil paragraf).

Ancorele (`&name`) și aliasurile (`*name`) vă permit să definiți un nod YAML o singură dată și să îl reutilizați în altă parte — o practică obișnuită în fișierele Compose pentru șabloane de servicii partajate.

Etichetele explicite de tip (`!!str`, `!!int`, `!!bool`, `!!null`) suprascriu detectarea automată a tipului din YAML atunci când aveți nevoie ca un șir de caractere să fie tratat ca text, deși arată ca un număr, sau invers.

Convertorul pune automat între ghilimele șirurile ambigue: `"yes"`, `"no"`, `"null"`, `"~"`, valorile care par numerice precum `"01234"` și orice șir care conține caractere speciale YAML (`:`, `#`, `-`, `&`, `*`, `!`, `|`, `>`, `'`, `"`, `%`, `@`).

Șase erori sunt responsabile pentru 95% din problemele de sintaxă YAML întâlnite în practică.

• (1) Caractere Tab folosite oriunde — chiar și un singur caracter tab blochează parsarea. Configurați-vă editorul să introducă spații în loc de tab-uri.
• (2) Indentare inconsistentă — o cheie de pe același nivel decalată cu o singură coloană generează o eroare de parsare.
• (3) Lipsa spațiului după `:` — `key:value` este nevalid; `key: value` este corect.
• (4) Șiruri fără ghilimele care seamănă cu valori booleene (`yes`, `no`, `on`, `off`) — sunt convertite forțat în true/false în YAML 1.1 (parsoare mai vechi). YAML 1.2 a restrâns valorile booleene doar la `true`/`false`, dar punerea lor preventivă între ghilimele este în continuare recomandată.
• (5) Șiruri numerice fără ghilimele — `01234` devine numărul întreg 1234, pierzând zeroul inițial.
• (6) Lipsa spațiului după `-` — `-item` este un șir de caractere care începe cu o cratimă; `- item` este un element dintr-o secvență.

Validați sintaxa cu `yamllint`, extensia YAML din VS Code sau validatoare specifice domeniului (`kubectl --dry-run`, `docker compose config`, `ansible-playbook --syntax-check`).

Fluxurile de lucru API beneficiază de conversia JSON în YAML în două situații principale.

În primul rând, specificațiile OpenAPI 3.x sunt de obicei scrise în YAML (mai ușor de citit pentru structurile de căi și parametri), dar exportate ca JSON pentru diverse instrumente — convertiți în ambele sensuri, în funcție de necesitățile fluxului de lucru. Convertorul păstrează câmpurile obligatorii, definițiile de scheme, pointerii $ref și corpurile de exemplu.

În al doilea rând, când documentați un API, puteți lipi un exemplu de răspuns JSON și prezenta versiunea YAML în documentație — este mult mai ușor pentru cititori să parcurgă corpuri de răspuns cu structuri adânc imbricate.

Pentru integrarea cu Swagger UI, sunt acceptate atât `swagger.yaml`, cât și `swagger.json`; multe echipe păstrează fișierele YAML în sistemul de control al versiunilor și generează JSON la build. Siguranța conversiei dus-întors (round-trip) este garantată pentru specificațiile OpenAPI, deoarece acestea nu folosesc comentarii sau ancore în forma lor canonică.

Aproape toate platformele moderne de CI/CD folosesc YAML pentru definirea pipeline-urilor:

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

Atunci când aveți o configurație JSON — de la un generator, un export anterior din controlul versiunilor sau un utilitar de build programatic — lipiți-o aici pentru a genera YAML.

Playbook-urile Ansible se bazează în mod special pe structura YAML de tip listă de sarcini (list-of-tasks) cu ancore pentru blocurile reutilizate; convertorul generează secvențe curate, astfel încât să le puteți lipi direct sub `tasks:` fără alte modificări.

Pentru GitHub Actions, partea cea mai delicată o reprezintă condițiile `if:` și strategiile de matrice — păstrați codul YAML convertit, apoi adăugați comentarii care să explice scopul (o funcționalitate exclusivă YAML, pe care o veți pierde dacă reveniți la JSON).

Cinci cazuri speciale pot pune probleme convertoarelor simple.

• (1) Comentariile: JSON nu le acceptă, în timp ce YAML folosește `#`. Conversia dus-întors JSON → YAML → JSON nu pierde date, dar YAML → JSON → YAML elimină toate comentariile. Păstrați YAML ca sursă unică de adevăr atunci când comentariile sunt importante.
• (2) Conversia booleană: parsoarele vechi de YAML 1.1 tratează `yes`/`no`/`on`/`off` ca valori booleene. Parsoarele moderne (1.2.2) acceptă doar `true`/`false` în acest sens, însă punerea preventivă între ghilimele previne comportamentele neașteptate.
• (3) Null: Valoarea `null` din JSON corespunde în YAML cu `null`, `~` sau o valoare goală. Convertorul generează `null` pentru claritate; unele instrumente preferă valoarea goală (`key:`), dar aceasta poate crea ambiguități cu șirurile de caractere goale.
• (4) Șiruri numerice: `"01234"` (cum ar fi un cod poștal) își pierde zeroul inițial dacă nu este pus între ghilimele în YAML — convertorul îl pune automat între ghilimele.
• (5) Numere zecimale cu zerouri finale: `1.50` devine `1.5` în urma conversiei dus-întors, deoarece atât JSON, cât și YAML folosesc reprezentarea numerică canonică. Dacă zerourile de la sfârșit sunt importante (valute, versiuni de software), serializați-le ca șiruri de caractere.

Maparea tipurilor pe scurt:

• Obiect JSON → Hartă YAML (stil bloc)
• Tablou JSON → Secvență YAML (elemente precedate de `-`)
• Șir JSON → Șir YAML (pus automat între ghilimele dacă este ambiguu)
• Număr JSON → Scalar YAML cu aceeași valoare numerică
• true/false din JSON → true/false în YAML
• null din JSON → null în YAML

Opțiuni de stil:

• preferați stilul bloc (multilinie, indentat) pentru o mai bună lizibilitate în detrimentul stilului flux (`{key: value, ...}`, compact, similar cu JSON)
• folosiți întotdeauna o indentare de 2 spații
• generați cheile în ordinea din sursă (corespunde comportamentului JSON)

Sfaturi pentru conversia dus-întors:

• (1) Conversia JSON → YAML → JSON se face fără pierderi de date.
• (2) Conversia YAML → JSON elimină comentariile, ancorele (care sunt expandate), etichetele explicite și fluxurile multi-document.
• (3) Puneți întotdeauna între ghilimele șirurile de caractere care seamănă cu valori booleene, null sau numere.
• (4) Testați rezultatul cu instrumentul real care îl va utiliza (kubectl, docker compose, ansible-playbook) — acestea au reguli de validare mai stricte decât parsoarele YAML generice.
• (5) Păstrați ambele versiuni în sistemul de control al versiunilor dacă echipa folosește ambele formate; stabiliți una ca fiind canonică (de regulă YAML pentru configurări, JSON pentru API-uri) și regenerați-o pe cealaltă la build.