ToolDeck

YAML

2 nástrojů

Formáty serializace dat

Serializace dat je proces převodu strukturovaných dat do formátu, který lze uložit nebo přenést a později znovu sestavit. Různé formáty dělají různé kompromisy mezi čitelností pro člověka, strojovou zpracovatelností, výrazností a velikostí souboru. Volba správného formátu závisí na tom, zda soubor primárně čte člověk nebo stroj, a na ekosystému nástrojů, které s daty pracují.

JSON, YAML, TOML a XML jsou čtyři dominantní textové formáty serializace ve vývoji softwaru. Každý má silné stránky, které z něj dělají nejlepší volbu pro konkrétní kontext — pochopení těchto kompromisů vám umožní vybrat správný formát pro každý úkol. Znalost všech čtyř formátů je pro moderního vývojáře prakticky nezbytností, protože se s nimi setkáte napříč různými platformami a nástroji.

JSON a YAML vedle sebe

JSON a YAML reprezentují stejný datový model. YAML je striktní nadmnožinou JSON — jakýkoli platný JSON dokument je zároveň platným YAML. Níže je stejná konfigurace vyjádřená v obou formátech:

JSON
{
  "server": {
    "host": "localhost",
    "port": 8080,
    "debug": true
  },
  "database": {
    "url": "postgres://localhost/mydb",
    "pool": 10
  }
}
YAML
server:
  host: localhost
  port: 8080
  debug: true
database:
  url: postgres://localhost/mydb
  pool: 10

YAML používá odsazení místo složených závorek a hranatých závorek a vynechává uvozovky u většiny řetězcových hodnot. Díky tomu je kompaktnější a čitelnější pro soubory editované člověkem, ale zavádí citlivost na odsazení. Při automatizovaném generování YAML souborů je proto vždy bezpečnější použít knihovnu pro serializaci než skládat výstup ručně pomocí řetězcové konkatenace.

Porovnání formátů

FormátČitelnostKomentářePoleNejlepší pro
JSON★★★☆☆Bez komentářůNativníAPI, výměna dat
YAML★★★★★Ano (#)NativníKonfigurační soubory, IaC
TOML★★★★☆Ano (#)NativníKonfigurace aplikace (Rust, Python)
XML★★☆☆☆Ano (<!-- -->)Opakující se elementyDokumenty, SOAP, SVG

Záludnosti YAML

YAML je výkonný, ale má dobře známé okrajové případy, které vývojáře překvapují. Toto jsou ty nejčastější. Dobrá znalost těchto pastí vám ušetří hodiny ladění, zejména při práci s automaticky generovanými konfiguracemi nebo při migraci souborů mezi různými parsery.

Problém Norska

Holá hodnota 'NO' je v YAML 1.1 interpretována jako booleovská hodnota false. Kódy zemí jako NO (Norsko), OFF, FALSE, N jsou všechny parsovány jako false. V YAML 1.2 je to opraveno, ale mnoho parserů stále používá pravidla 1.1. Vždy uvozujte nejednoznačné řetězce. Stejný problém se týká hodnot jako 'yes', 'on', 'true' — ty jsou naopak parsovány jako true, což může způsobit neočekávané chování v konfiguraci.

Citlivost na odsazení

YAML používá odsazení k definování struktury. Jediná nadbytečná mezera nebo znak tabulátoru může zcela změnit význam dokumentu. Tabulátory jsou v YAML jako odsazení zakázány — používejte pouze mezery. Nastavte si editor tak, aby zobrazoval neviditelné znaky a automaticky odstraňoval přebytečné mezery na konci řádků, protože i ty mohou způsobit problémy při parsování.

Implicitní přetypování

Holé hodnoty, které vypadají jako čísla, booleany nebo null, jsou automaticky přetypovány. '1.0' se stane číslem s plovoucí desetinnou čárkou, '2024-01-01' se v některých parserech stane objektem Date. Uvozujte hodnoty, které chcete zachovat jako řetězce. Obzvláště pozor si dejte na hodnoty jako čísla verzí (např. '1.10') — bez uvozovek může parser '1.10' interpretovat jako číslo 1.1.

Tabulátory jsou zakázány

Specifikace YAML explicitně zakazuje znaky tabulátoru pro odsazení. Editory, které automaticky převádějí mezery na tabulátory, tiše poškodí váš YAML soubor. Nakonfigurujte editor tak, aby v YAML souborech používal mezery. Pokud pracujete v týmu, je vhodné toto pravidlo vynutit pomocí souboru .editorconfig, který zajistí konzistentní chování napříč různými editory.

Režimy víceřádkových řetězců

YAML má dva indikátory víceřádkových řetězců: | (literální blok, zachovává konce řádků) a > (přeložený blok, převádí konce řádků na mezery). Záměna za sebou tiše produkuje nesprávný výstup. Oba indikátory dále podporují modifikátory pro oříznutí závěrečných nových řádků: |- a >- odstraní závěrečný nový řádek, zatímco |+ a >+ zachovají všechny závěrečné nové řádky.

Smyčky kotev a aliasů

Kotvy (&) a aliasy (*) v YAML umožňují opakované použití uzlů, což je výkonné, ale může vytvořit kruhové reference způsobující nekonečné smyčky nebo vyčerpání paměti v naivních parserech. Ověřujte YAML s kotvami z nedůvěryhodných zdrojů.

Funkce jedinečné pro YAML

Komentáře

YAML podporuje komentáře pomocí znaku #. To je jedna z největších praktických výhod oproti JSON pro konfigurační soubory — můžete dokumentovat nastavení přímo v souboru. Komentáře mohou být na vlastním řádku nebo za hodnotou. Tato možnost je zvláště cenná v prostředích, kde konfiguraci upravují i méně zkušení členové týmu, protože komentář přímo u nastavení výrazně snižuje počet chyb způsobených nepochopením účelu dané hodnoty.

Kotvy a aliasy

YAML umožňuje definovat uzel jednou pomocí &název-kotvy a znovu ho použít kdekoliv pomocí *název-kotvy. Tím se eliminuje opakování v složitých konfiguracích. Kubernetes a Docker Compose hojně využívají kotvy pro sdílené definice služeb. Aliasy lze kombinovat s operátorem sloučení (<<) pro přepsání nebo rozšíření definice, což umožňuje vytvořit základní šablonu a z ní odvodit specializované varianty se zachováním společných vlastností.

Víceřádkové řetězce

YAML podporuje blokové skaláry ve dvou režimech: literální blok (|) zachovává konce řádků přesně tak, jak jsou zapsány — vhodné pro skripty a šablony. Přeložený blok (>) zalamuje dlouhé řetězce do jednoho řádku — vhodné pro delší textové popisy. Správné použití těchto režimů je klíčové při vkládání shell skriptů nebo SQL dotazů přímo do konfiguračního souboru, protože špatně zvolený režim může změnit funkčnost vloženého kódu.

Kdy potřebujete konverzi

Konfigurace CI/CD pipeline

GitHub Actions, GitLab CI a CircleCI nativně používají YAML. Při programovém generování konfigurací pipeline je často snazší sestavit JSON objekt a převést ho na YAML pro finální výstup. Tento přístup také zjednodušuje testování konfigurací, protože s JSON objekty lze v kódu snáze pracovat a ověřovat jejich správnost před konverzí.

Kubernetes manifesty

Kubernetes zdroje jsou definovány v YAML, ale Helm šablonování a některé nástroje produkují JSON. Konverze mezi formáty umožňuje prohlížet API odpovědi a používat standardní JSON nástroje. Nástroje jako kubectl podporují oba formáty na vstupu, takže konverze do JSON je praktická při ladění nebo při automatizaci pomocí skriptů, které pracují s JSON výstupem jiných příkazů.

Zpracování API odpovědí

REST API vrací JSON. Při předávání dat do konfiguračních systémů založených na YAML (Ansible, Salt, Kubernetes) konvertor přemostí mezeru bez ruční reformatace. Automatická konverze v build pipeline eliminuje lidské chyby a zajišťuje konzistentní formátování, zejména u komplexních struktur s hlubokým vnořením nebo u datových souborů s mnoha záznamy.

Migrace konfigurace

Migrace z jednoho nástroje na jiný často znamená konverzi formátu konfigurace. Konverze mezi JSON a YAML umožňuje rychlý přechod mezi ekosystémy (Node.js → Python, Docker → Kubernetes).

Pracovní postup validace schématu

Nástroje pro JSON Schema jsou vyspělejší než pro YAML Schema. Běžný vzor je psát konfiguraci v YAML pro čitelnost, převést do JSON pro validaci oproti schématu a pak převést zpět pro nasazení.

Výměna dat s API

Interní nástroje mohou konzumovat YAML konfigurace, zatímco externí API vyžadují JSON. Konvertor v build pipeline udržuje obě reprezentace synchronizované bez nutnosti udržovat duplicitní soubory.

Nejčastěji kladené otázky

Je YAML nadmnožinou JSON?

Ano. YAML 1.2 je striktní nadmnožinou JSON — jakýkoli platný JSON dokument je zároveň platným YAML. YAML 1.1 (stále používaný mnoha parsery) má však několik okrajových případů, kde platný JSON není platným YAML 1.1. Praktickým důsledkem je, že pokud váš parser používá YAML 1.1, doporučuje se ověřit kompatibilitu, zejména u dokumentů obsahujících booleovské hodnoty nebo speciální řetězce jako 'null' a 'true'.

Proč zvolit YAML místo JSON pro konfigurační soubory?

YAML podporuje komentáře, JSON ne. YAML je také kompaktnější pro hluboce vnořené struktury. Tyto dvě vlastnosti z něj dělají preferovanou volbu pro konfigurační soubory editované člověkem (Docker, Kubernetes, GitHub Actions). Navíc absence povinných uvozovek u klíčů a jednoduchých řetězcových hodnot výrazně snižuje množství vizuálního šumu v souboru, což usnadňuje orientaci v rozsáhlých konfiguracích.

Co je TOML a kdy ho použít?

TOML (Tom's Obvious Minimal Language) je navržen pro konfigurační soubory. Má jasnou syntaxi podobnou INI s explicitními typy a bez nejednoznačností. Je standardem pro projekty Rust (Cargo.toml) a Python (pyproject.toml). Na rozdíl od YAML TOML nemá problém s implicitním přetypováním — každá hodnota musí mít explicitní syntaxi odpovídající jejímu typu, což eliminuje záludnosti jako problém Norska.

Dochází při konverzi JSON na YAML ke ztrátě informací?

Zřídka, ale potenciálně ano. JSON zachovává pořadí klíčů ve většině parserů (ačkoli specifikace říká, že je neuspořádané). YAML podporuje kotvy a značky, které nemají ekvivalent v JSON. Pro věrnost při zpětné konverzi se držte společné podmnožiny. Při konverzi z YAML do JSON se také ztratí všechny komentáře, protože JSON komentáře nepodporuje — pokud jsou komentáře důležité, uchovávejte originální YAML soubor jako referenci.

Co způsobuje výskyt 'undefined' ve výstupu JSON?

JSON.stringify převádí hodnoty undefined na null v polích a vynechává je z objektů. Pokud vidíte neočekávané hodnoty null nebo chybějící klíče ve výstupu JSON, zdrojový JavaScript objekt pravděpodobně obsahoval nedefinované vlastnosti. Řešením je buď explicitně nastavit tyto hodnoty na null před serializací, nebo použít náhradu (replacer) funkci v JSON.stringify pro vlastní zpracování nedefinovaných hodnot.

Lze v YAML souboru použít JSON?

Ano. Protože YAML je nadmnožinou JSON, můžete vložit JSON syntaxi přímo do YAML dokumentu. To se někdy dělá pro složité vnořené struktury, kde by odsazení YAML bylo matoucí. Smíchání syntaxí ale snižuje čitelnost — doporučuje se zůstat konzistentní a používat jeden styl v celém dokumentu, pokud neexistuje konkrétní důvod pro hybridní přístup.