Konwerter JSON na YAML Online
Przekonwertuj JSON na czytelny YAML. Idealny do tworzenia konfiguracji Docker Compose, Kubernetes lub GitHub Actions.
name: John Doe age: 30 active: true tags: - developer - javascript address: city: Madrid zip: 28001
Zastosowania
Z JSON API do czytelnej konfiguracji YAML
Tworzenie konfiguracji DevOps
Przeksztalcaj odpowiedzi JSON z Kubernetes, Docker lub API narzedzi cloudowych na edytowalne pliki konfiguracyjne YAML.
Workflow DevOps
Konwertuj szablony JSON CloudFormation lub Azure ARM na rownowaznie YAML dla lepszej czytelnosci i latwosci utrzymania.
100% prywatne
Twoj JSON jest przetwarzany w Twojej przegladarce. Nigdy nie jest wysylany na zadne serwery. Brak rejestracji, brak limitow uzycia.
Przejrzysty YAML
Wciecie 2 spacji, poprawnie typowane wartosci, gotowe do wklejenia do docker-compose.yml lub manifestu Kubernetes.
Jak to działa
Trzy kroki, żadnych komplikacji
Wklej swoj JSON
Wklej dowolny prawidlowy JSON: odpowiedz API, konfiguracje, dane strukturalne. Akceptowany jest zarowno JSON sformatowany, jak i zminifikowany.
Konwersja na przejrzysty YAML
JSON jest konwertowany na YAML z wcijeciem 2 spacji, zgodnie z konwencjami najpopularniejszych projektow DevOps.
Skopiuj i uzyj YAML
Skopiuj wynikowy YAML, aby uzyc go jako podstawy pliku docker-compose.yml, manifestu Kubernetes lub dowolnej konfiguracji YAML.
FAQ
Masz pytania?
YAML przewyzsza JSON pod wzgledem czytelnosci w przypadku dlugich, hierarchicznych konfiguracji. Glowne zalety YAML to: obsluga komentarzy (niezbedna w udokumentowanych plikach konfiguracyjnych), bardziej zwiezla skladnia (brak nawiasow klamrowych i cudzyslowow w wiekszosci przypadkow), lepsza reprezentacja ciagów wieloliniowych (skrypty, polecenia, tekst) i bardziej naturalne czytanie list. JSON jest lepszy, gdy miejscem docelowym jest API lub program przetwarzajacy dane automatycznie: parsowanie jest szybsze, specyfikacja jest prostsza i bardziej rygorystyczna, a ryzyko niejednoznacznosci mniejsze. Praktyczna zasada w DevOps: YAML dla plikow edytowanych bezposrednio przez ludzi, JSON dla danych wymienianych miedzy systemami.
Konwerter generuje YAML strukturalnie rownowazny wejsciowemu JSON, bez komentarzy (JSON nie ma komentarzy, wiec nie ma informacji do przeniesienia). Wygenerowany YAML jest jednak doskonalym punktem wyjscia: otworz go w dowolnym edytorze i dodaj komentarze recznie za pomoca # przed lub po dowolnej linii. W narzeddziach takich jak docker-compose.yml i manifesty Kubernetes komentarze sa fundamentalne do dokumentowania celu kazdej wartosci konfiguracyjnej.
JSON jest znacznie szybszy do parsowania niz YAML. Parsowanie JSON jest O(n) z bardzo niskimi stalymi: parsery takie jak simdjson (uzywany w Node.js od wersji 17) przetwarzaja do 3 GB/s na nowoczesnym sprzecie. YAML wymaga bardziej zlozonego parsera (obsluga kotwic, aliasow, jawnych typow, roznych styli ciagów) i jest zazwyczaj 10-50 razy wolniejszy niz JSON dla tej samej objetosci danych. W przypadku malych plikow konfiguracyjnych (kilka KB docker-compose.yml) roznica jest niezauwaalna. Dla API wymieniajacych miliony wiadomosci na sekunde JSON jest wlasciwym wyborem. Uzywanie YAML w narzeddziach DevOps to decyzja ergonomiczna dla ludzi edytujacych te pliki.
Konwerter uzywa wciecia 2 spacji, co jest konwencja przyjeta przez praktycznie caly ekosystem DevOps: Kubernetes (kubectl generuje YAML z 2 spacjami), Helm, GitHub Actions, GitLab CI, Ansible i Docker Compose. Niektore projekty uzywaja 4 spacji (czeste w projektach Python, gdzie konwencja 4 spacji z PEP 8 wplywa na deweloperow), ale 2 spacje to de facto standard w spolecznosci DevOps.
Konwersja typow jest prosta: liczby JSON (calkowite i zmiennoprzecinkowe) sa reprezentowane jako skalary YAML bez cudzyslowow; wartosci logiczne JSON (true/false) staja sie true/false w YAML; null JSON staje sie null lub ~ w YAML; ciagi znakow sa reprezentowane bez cudzyslowow, gdy sa jednoznaczne, lub w pojedynczych albo podwojnych cudzyslowach, gdy wartosc mogla byc zinterpretowana jako inny typ (na przyklad ciag '42' wymaga cudzyslowow, aby nie stac sie liczba, a 'true' wymaga cudzyslowow, aby nie stac sie wartoscia logiczna).
Konwertuj JSON na YAML: z odpowiedzi API do czytelnych konfiguracji DevOps
Konwersja JSON na YAML to rutynowa operacja we wspolczesnych procesach DevOps. Kubernetes API (Kubernetes REST API domyslnie zwraca zasoby w JSON), AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager i wiekszosc narzedzi infrastructure-as-code posiada natywne interfejsy JSON, ale ich uzytkownicy wola pracowac z plikami konfiguracyjnymi YAML ze wzgledu na lepsza czytelnosc. kubectl, narzedzie wiersza polecen Kubernetes, automatycznie konwertuje miedzy YAML a JSON: gdy uruchomisz kubectl get deployment my-app -o yaml, Kubernetes zwraca obiekt JSON API, a kubectl konwertuje go na YAML do wyswietlenia. Odwrotna konwersja (JSON na YAML) jest przydatna podczas tworzenia manifestu YAML z odpowiedzi API, migracji konfiguracji miedzy narzeddziami lub dokumentowania istniejacych konfiguracji przez dodawanie komentarzy YAML.
YAML (specyfikacja 1.2, opublikowana na yaml.org w lipcu 2009 roku) jest nadzbiorem JSON, co gwarantuje, ze konwersja JSON na YAML jest zawsze mozliwa bez utraty informacji. Konwersja odwrotna (YAML na JSON) traci jedynie komentarze, ktorych JSON nie moze reprezentowac. Zalety YAML dla konfiguracji tworzonych przez ludzi sa dobrze udokumentowane: brak nawiasow klamrowych i kwadratowych redukuje szum wizualny o 30-40% dla typowych konfiguracji; komentarze pozwalaja dokumentowac cel kazdego parametru bezposrednio w pliku; ciagi wieloliniowe (szczegolnie z blokiem literalnym |) pozwalaja wlaczac skrypty powloki, zapytania SQL lub zawartosci plikow bezposrednio w konfiguracji bez escapowania znakow specjalnych.
W ekosystemie Kubernetes wybor miedzy YAML a JSON jest jasno ustalony: pliki tworzone i utrzymywane przez deweloperow w repozytoriach git sa w YAML; dane wyslane przez kubectl do serwera API sa w JSON (kubectl konwertuje YAML na JSON wewnetrznie przed wykonaniem wywolania HTTP); odpowiedzi serwera API sa w JSON; a narzedzia do automatyzacji (Helm, Kustomize, Argo CD, Flux) dzialaja z YAML jako wejsciem i JSON jako wewnetrznym protokolem. To rozdzielenie formatu ludzkiego (YAML) od formatu protokolu (JSON) jest wzorcem stosowanym rowniez przez GitHub Actions (workflowy sa w YAML, GitHub API jest w JSON), GitLab CI, Ansible (playbooki w YAML, dane dynamicznego inwentarza w JSON) i Terraform (HCL to alternatywa HashiCorp, ale akceptuje rowniez natywny JSON w plikach .tf.json).