Konwerter YAML na JSON Online
Przekonwertuj YAML na JSON w swojej przegladarce. Idealny do walidacji konfiguracji Docker, Kubernetes lub GitHub Actions.
{
"name": "John Doe",
"age": 30,
"active": true,
"tags": [
"developer",
"javascript"
],
"address": {
"city": "Madrid",
"zip": "28001"
}
}Do czego sluzy
YAML na JSON: waliduj konfiguracje DevOps natychmiast
Docker i Kubernetes
Konwertuj pliki docker-compose.yml lub manifesty Kubernetes na JSON, aby walidowac struktury lub korzystac z narzedzi wymagajacych JSON.
Debugowanie CI/CD
Waliduj workflowy GitHub Actions, potoki GitLab CI lub playbooki Ansible, konwertujac na JSON, aby zobaczyc sparsowana strukture.
100% prywatne
Twoja konfiguracja YAML jest przetwarzana w Twojej przegladarce. Nigdy nie opuszcza Twojego urzadzenia. Idealne dla konfiguracji zawierajacych sekrety.
Wykrywanie bledow
Bledy skladniowe YAML (wciecia, tabulatory, nieprawidlowe typy) sa wyraznie pokazywane przed konwersja.
Jak to działa
Trzy kroki, żadnych komplikacji
Wklej swoj plik YAML
Wklej plik YAML: docker-compose.yml, manifest Kubernetes, workflow GitHub Actions lub dowolna konfiguracje YAML.
Konwersja i walidacja
Konwerter parsuje YAML zgodnie ze specyfikacja YAML 1.2 i natychmiast generuje prawidlowy JSON, pokazujac ewentualne bledy skladniowe.
Skopiuj wynikowy JSON
Skopiuj sformatowany JSON do uzycia w swoim API, narzedziu konfiguracyjnym lub do walidacji struktury pliku YAML.
FAQ
Masz pytania?
YAML (YAML Ain't Markup Language, rekurencyjny akronim) to jezyk serializacji danych czytelny dla czlowieka. Specyfikacja YAML 1.2 zostala opublikowana w lipcu 2009 roku na yaml.org i jest nadzbiorem JSON: kazdy prawidlowy JSON jest rowniez prawidlowym YAML. YAML jest szeroko stosowany w konfiguracjach narzedzi DevOps (Docker Compose, Kubernetes, Ansible, Terraform, GitHub Actions, GitLab CI), poniewaz skladnia oparta na wcijeciach jest bardziej czytelna niz JSON w przypadku dlugich, hierarchicznych konfiguracji. W odroznieniu od JSON, YAML obsluguje komentarze (linie zaczynajace sie od #), ciagi wieloliniowe, kotwice i aliasy do ponownego wykorzystania danych oraz dodatkowe typy danych, takie jak daty ISO 8601.
YAML oferuje dwa style ciagów wieloliniowych. Styl literalny (oznaczony symbolem |) zachowuje znaki konca linii dokladnie tak jak zostaly zapisane — przydatny dla skryptow powloki, zawartosci plikow lub sformatowanego tekstu. Styl zwijany (oznaczony symbolem >) konwertuje znaki konca linii na spacje i zachowuje tylko podzial na akapity (puste linie) — przydatny w przypadku dlugich opisow. W JSON oba style staja sie ciagami ze znakami \n dla literalnych konców wierszy lub bez przerw dla stylu zwijanego. Modyfikator przycinania (|- dla strip, |+ dla keep) kontroluje, czy koncowy znak nowej linii jest zachowany.
Tak. Kotwice YAML (&name) i aliasy (*name) to sposob na ponowne wykorzystanie wezlow w dokumencie. W docker-compose.yml czesto definiuje sie wspoldzielone zmienne srodowiskowe jako kotwice i odwoluje sie do nich w wielu serwisach za pomoca <<: *anchor (klucz scalania). Nasz konwerter rozwija wszystkie kotwice i aliasy przed wygenerowaniem JSON, tworzac kompletna strukture bez odwolan — co jest prawidlowym zachowaniem, poniewaz JSON nie ma odpowiednika kotwic YAML.
Nie. JSON (RFC 7159/RFC 8259) nie obsluguje komentarzy. Komentarze YAML (tekst od # do konca linii) sa odrzucane podczas parsowania. Jest to fundamentalne ograniczenie formatu JSON, a nie konwertera. Jezeli chcesz zachowac dokumentacje zwiazana z polami konfiguracyjnymi, rozwaz uzycie JSON Schema (ktory pozwala na pola 'description') lub traktowanie oryginalnego YAML jako jedynego zrodla prawdy i generowanie JSON na zadanie.
YAML uzywa spacji (nigdy tabulatorow) do wciecia, aby wskazac hierarchie. Specyfikacja YAML 1.2 nie ustala konkretnej liczby spacji, ale najczestszym zwyczajem jest uzycie 2 spacji. Spojnosc na tym samym poziomie hierarchii jest kluczowa. Mieszanie tabulatorow i spacji jest bledem skladniowym w YAML (w odroznieniu od Pythona, ktory akceptuje tabulatory). Najczestszym bledem jest przypadkowe mieszanie tabulatorow ze spacjami, szczegolnie podczas edytowania YAML w edytorach rozwijajacych tabulatory w rozny sposob.
Tak. Manifesty Kubernetes (Deployments, Services, ConfigMaps, Ingress) i pliki docker-compose.yml sa standardowym YAML i konwertuja sie prawidlowo na JSON. Jest to przydatne do walidacji struktury manifestu, przekazywania go do narzedzi akceptujacych tylko JSON (jak niektore klienty Kubernetes API), lub debugowania nieoczekiwanego zachowania spowodowanego subtelnymi bledami YAML. Kubernetes API akceptuje zarowno YAML, jak i JSON; wewnetrznie kubectl konwertuje YAML na JSON przed wyslaniem zadania do serwera API.
Konwertuj YAML na JSON: walidacja konfiguracji DevOps i Kubernetes w przegladarce
YAML (YAML Ain't Markup Language) stal sie dominujacym formatem konfiguracji we wspolczesnym ekosystemie DevOps. Docker Compose (wprowadzony w 2014 roku, od wersji Docker Engine 20.10 wbudowany), Kubernetes (ktorego API akceptuje manifesty w YAML lub JSON od czasu uruchomienia przez Google w 2014 roku), GitHub Actions (uruchomiony w listopadzie 2019), GitLab CI/CD, Ansible (Red Hat, 2012), Terraform (HashiCorp, 2014) i charty Helm — wszystkie uzywaja YAML jako podstawowego formatu konfiguracji. Specyfikacja YAML 1.2, opublikowana na yaml.org w lipcu 2009 roku, stwierdza, ze YAML jest scislym nadzbiorem JSON, co oznacza, ze kazdy dokument JSON jest takze prawidlowym dokumentem YAML. Ta zaleznosc sprawia, ze konwersja miedzy tymi dwoma formatami jest semantycznie doskonala: nie ma zadnej utraty informacji strukturalnej, tylko roznice w reprezentacji.
Konwersja YAML na JSON jest szczegolnie przydatna w kilku procesach DevOps: debugowaniu potoków CI/CD, w ktorych blad wciecia powoduje nieoczekiwane zachowanie (reprezentacja JSON sprawia, ze struktura staje sie jasna i jednoznaczna); uzywaniu narzedzi akceptujacych tylko JSON jako wejscie (niektorzy klienci Kubernetes REST API, narzedzia do walidacji JSON Schema lub procesory takie jak jq dzialajace natywnie z JSON); migrowaniu konfiguracji miedzy narzeddziami uzywajacymi roznych formatow; oraz walidowaniu, ze YAML parsuje sie zgodnie z oczekiwaniami, szczegolnie przy uzywaniu zaawansowanych funkcji, takich jak kotwice (&), aliasy (*), klucze scalania (<<:), jawne typy (!!str, !!int, !!bool) lub ciagi wieloliniowe w blokach literalnych (|) i zwijanych (>).
Parsowanie YAML ma kilka znanych pulapek, ktore prowadzily do tak zwanego 'Problemu Norwegii': w YAML 1.1 (uzywany przez PyYAML przed wersja 6.0 i przez libyaml przed 0.2.5) wartosc 'NO' byla interpretowana jako logiczny falsz, co powodowalo niepoprawne parsowanie kodu kraju Norwegii ('NO'). YAML 1.2 (specyfikacja z lipca 2009) rozwiazal ten problem: tylko 'true' i 'false' (bez rozrozniania wielkosci liter) sa wartosciami logicznymi, a wartosci takie jak 'yes', 'no', 'on', 'off', ktore YAML 1.1 traktowal jako wartosci logiczne, sa teraz ciagami znakow. Nasz konwerter uzywa biblioteki implementujacej YAML 1.2, gwarantujac prawidlowe, nowoczesne dzialanie. W projektach uzywajacych PyYAML wazna jest aktualizacja do wersji 6.0+ (wydana w marcu 2022), ktora dodala obsluge bezpiecznego loadera zgodnego z YAML 1.2 przez yaml.safe_load().