Konwerter JSON do YAML

Konwertuj JSON na YAML i YAML na JSON.

O tym narzędziu

Wklej JSON lub YAML i otrzymaj drugi format. Kierunek jest wykrywany automatycznie, a błędy parsowania wskazują linię, w której wystąpił problem. Przydatne przy manifestach Kubernetes, plikach Docker Compose i konfiguracjach CI.

Jak z tego korzystać

  1. Wklej JSON lub YAML w pole Dane wejściowe.
  2. Zostaw kierunek na Wykryj albo wymuś JSON do YAML lub YAML do JSON.
  3. Wybierz wcięcie: 2 lub 4 spacje.
  4. Skopiuj wynik albo kliknij Użyj wyniku jako wejścia, aby przekonwertować go z powrotem.

Pytania

Czy YAML jest nadzbiorem JSON?
W praktyce tak: od YAML 1.2 niemal każdy prawidłowy dokument JSON jest też prawidłowym YAML-em. W drugą stronę to nie działa, bo YAML ma komentarze, kotwice i wielolinijkowe ciągi, których JSON nie potrafi wyrazić.
Co dzieje się z komentarzami YAML przy konwersji do JSON?
Są pomijane, bo JSON nie obsługuje komentarzy. Jeśli komentarze są ważne, traktuj plik YAML jako źródło prawdy.
Czy mogę przekonwertować plik z kilkoma dokumentami YAML oddzielonymi ---?
Tak. Każdy dokument staje się jednym elementem tablicy JSON, a linia statusu podaje, ile dokumentów znaleziono.
Dlaczego „no” zamienia się w false?
Starsze parsery YAML 1.1 traktują słowa takie jak yes, no, on i off jako wartości logiczne. To narzędzie stosuje reguły YAML 1.2, w których wartościami logicznymi są tylko true i false, ale jeśli plik będą czytać inne narzędzia, ujmij takie wartości w cudzysłów.
Czy daty z YAML są konwertowane na daty w JSON?
JSON nie ma typu daty, więc wartości takie jak 2026-01-12 czy 2026-01-12T10:00:00Z pozostają zwykłymi ciągami znaków, czego oczekuje większość programów. Niektóre parsery YAML 1.1, np. PyYAML, zamieniają te same wartości na obiekty daty, więc wynik wczytania pliku może się różnić między narzędziami.
Dlaczego tryb pliku 0755 zmienia się w 755?
Według reguł YAML 1.2 zero na początku nie oznacza zapisu ósemkowego, więc 0755 to liczba dziesiętna 755. Zapis ósemkowy wymaga prefiksu 0o: 0o755 daje 493. Starsze narzędzia YAML 1.1 odczytują 0755 jako liczbę ósemkową, więc ujmuj tryby plików w cudzysłowy, jak w mode: "0755", zawsze gdy ma znaczenie, które narzędzie odczyta plik.
Dlaczego niektóre ciągi w wyniku YAML są w cudzysłowach?
Ciągi, które zostałyby odczytane jako inny typ, dostają cudzysłowy, dzięki czemu wartość przetrwa konwersję w obie strony. Ciąg JSON "true" staje się w YAML "true", a nie wartością logiczną true, i to samo dotyczy "123", "null", "1.10" oraz tekstu zawierającego dwukropek ze spacją. Zwykłe ciągi pozostają bez cudzysłowów.

JSON czy YAML: kiedy używać którego?

JSON i YAML opisują te same dane: obiekty, tablice, ciągi znaków, liczby, wartości logiczne i null. JSON jest ścisły i szybki w parsowaniu, dlatego jest domyślnym wyborem dla API, package.json i danych przekazywanych między programami. YAML powstał z myślą o ludziach edytujących pliki ręcznie: mało nawiasów i cudzysłowów, komentarze z # i ciągi wieloliniowe. Dlatego manifesty Kubernetes, pliki Docker Compose, workflowy GitHub Actions i playbooki Ansible pisze się w YAML.

Praktyczna zasada: gdy plik zapisuje jeden program, a czyta go inny, użyj JSON. Gdy plik utrzymuje człowiek, YAML łatwiej czytać i przeglądać. Wiele narzędzi przyjmuje oba formaty, a kubectl apply akceptuje każdy z nich. Konwerter JSON do YAML przydaje się, gdy CLI albo API zwraca JSON, na przykład kubectl get deployment web -o json, a Ty chcesz trzymać w Gicie czytelną kopię w YAML.

Jak naprawić wcięcia i błędy parsowania YAML?

YAML używa wcięć do oznaczania struktury, więc większość błędów parsowania to problemy z białymi znakami. Tabulatory w ogóle nie są dozwolone jako wcięcia, a parser zgłasza wtedy „Tabs are not allowed as indentation”. Elementy jednej listy i klucze jednej mapy muszą zaczynać się w tej samej kolumnie, a zagnieżdżona wartość musi mieć głębsze wcięcie niż jej klucz. Błąd podaje linię i kolumnę, w której parsowanie się zatrzymało – zwykle jest to miejsce prawdziwej pomyłki albo tuż za nią.

Dwukropek ze spacją wewnątrz wartości bez cudzysłowów to kolejny klasyczny błąd YAML. url: http://example.com jest w porządku, ale title: Note: read this się nie sparsuje, bo drugi dwukropek rozpoczyna zagnieżdżone mapowanie. Ujmij takie wartości w cudzysłowy, jak w title: "Note: read this". Cudzysłowów wymagają też wartości zaczynające się od @ lub backticka, a także ciągi wyglądające jak liczby, np. version: "1.10", które inaczej stałyby się liczbą 1.1.

Co się dzieje z kotwicami YAML przy konwersji do JSON?

YAML pozwala zdefiniować blok raz z kotwicą, np. &defaults, i używać go w innych miejscach przez alias *defaults. JSON nie ma odpowiednika, więc przy konwersji YAML do JSON każdy alias jest zastępowany pełną kopią zakotwiczonej wartości. JSON jest poprawny, ale dłuższy, a powiązanie między kopiami ginie. Klucze scalania zapisane jako <<: *defaults nie należą do YAML 1.2 i zostają w JSON jako klucz o nazwie <<.

Zanim zacommitujesz przekonwertowany plik, sprawdź konwersję w obie strony. Kliknij Użyj wyniku jako wejścia, aby przekonwertować wynik z powrotem, a potem porównaj go z oryginałem w narzędziu Porównywarka tekstów. Wartości powinny przetrwać bez zmian, choć prezentacja może się różnić: komentarze znikają, kotwice są rozwijane, a cudzysłowy mogą się zmienić. Kubernetes i większość przewodników stylu YAML używa wcięć z 2 spacji, co jest tu ustawieniem domyślnym, a 4 spacje są dostępne dla zespołów, które je wolą.

Coś nie działa albo wynik wygląda na błędny? Zgłoś problem z tym narzędziem