YAML-Grundlagen
YAML ist ein Datenformat, dessen Struktur durch Einrückung entsteht, standardisiert als YAML 1.2 und gemacht für Konfigurationsdateien, die Menschen schreiben und Programme lesen. Verschachtelung entsteht über Leerzeichen statt geschweifter Klammern, Skalare ohne Anführungszeichen bekommen ihren Typ per Inferenz, und Kommentare beginnen mit #. Genau diese drei Annehmlichkeiten verursachen fast jeden YAML-Fehler in der Praxis, deshalb lehrt dieser Leitfaden Regeln und Stolperfallen gemeinsam.
YAML-Grundlagen erklärt
YAML ist das Format, in dem Konfiguration ankommt. Kubernetes-Manifeste, GitHub-Actions-Workflows, docker-compose-Dateien und Ansible-Playbooks sind allesamt YAML: verschachtelte Maps, geschrieben mit Leerzeichen, Listen mit Strichen, kaum eine Klammer weit und breit. Der Name hieß ursprünglich Yet Another Markup Language; die Autoren deuteten ihn später um zu YAML Ain't Markup Language – die zutreffendere Lesart, denn YAML beschreibt Daten, keine Dokumente.
Der aktuelle Standard ist YAML 1.2 (2009), und seine wichtigste Änderung ist unauffällig: 1.1 typisierte die nackten Wörter yes, no, on und off als boolesche Werte, 1.2 tut das nicht. Die meiste Software lädt die 1.1-Regeln weiterhin standardmäßig, sodass dieselbe Textzeile in verschiedenen Tools Verschiedenes bedeuten kann. YAML 1.2 machte außerdem fast alle JSON-Dokumente zu gültigem YAML – die sauberste Ein-Satz-Zusammenfassung der Grammatik.
Dieser Leitfaden behandelt alles, was Einsteiger brauchen – Einrückungsregeln, Skalar-Typisierung, Anführungszeichen, Blockskalare, Anker und Kommentare – und endet mit einer exakten Liste dessen, was die Konverter dieser Website akzeptieren und was sie ablehnen. Alles läuft in Ihrem Browser, nichts wird hochgeladen, also können Sie die Beispiele gefahrlos einfügen und ausprobieren.
Weil YAML 1.2 die meisten JSON-Dokumente als gültiges YAML behandelt, bekommt jede Konfiguration, die sich auf geschweifte Klammern reduzieren lässt, sofort Werkzeugunterstützung: Fügen Sie sie in den JSON-Formatierer ein, und er formatiert sie, prüft sie und meldet zu jedem Syntaxfehler die exakte Zeile und Spalte.
Wenn eine ganz neue Datei ehrlicherweise in beiden Formaten entstehen könnte, bringt der JSON-vs-YAML-Vergleich die Abwägungen in eine Entscheidungstabelle und sagt Ihnen, welches Format sich für welche Art von Dokument eignet.
Einrückung ist die Syntax
In YAML ist Leerraum keine Dekoration – er ist die gesamte Struktur. Ein Mapping besteht aus einem Schlüssel, einem Doppelpunkt, einem Leerzeichen und dann dem Wert; ein verschachtelter Wert steht in der nächsten Zeile, weiter eingerückt, und zwei Zeilen mit derselben Einrückung sind Geschwister. Tabs sind kategorisch verboten: Der Standard kann sich nicht festlegen, wie breit ein Tab ist, also lehnen Parser sie ab, statt zu raten. Editoren fügen beim Kopieren und Einfügen gern Tabs ein – deshalb sehen so viele Dateien perfekt aus und wollen trotzdem nicht parsen.
Die Konvention sind zwei Leerzeichen pro Ebene. Vier oder sechs sind genauso gültig – der Standard verbietet nur Tabs –, aber zwei verwenden Kubernetes und Compose, zwei erwartet jeder Linter, und zwei hält tiefe Manifeste davon ab, seitlich wegzuscrollen. Mischen Sie Breiten innerhalb einer Datei, entstehen Einrückungsfehler; entscheiden Sie sich für zwei und lassen Sie den Editor das durchsetzen.
- Eine Ebene = eine feste Leerzeichenanzahl; zwei ist die Konvention.
- Tabs in der Einrückung werden von Parsern abgelehnt, nicht umgewandelt.
- Ein Sequenzeintrag darf auf der Einrückung seines übergeordneten Schlüssels liegen – der Strich ist das Markierungszeichen.
- Werte lassen sich auch inline im Flow-Stil schreiben: ports: [8080].
Ein verschachteltes Mapping mit einer Sequenz
services:
web:
image: nginx:1.27
ports:
- "8080:80"
cache:
image: redis:7Der Baum, den ein Parser aufbaut
services ├─ web │ ├─ image: "nginx:1.27" │ └─ ports: ["8080:80"] └─ cache └─ image: "redis:7"
Skalare und das Norwegen-Problem
Werte in Anführungszeichen sind immer Zeichenketten. Werte ohne Anführungszeichen werden per Inferenz typisiert, und genau diese Inferenz hat YAMLs Ruf begründet: Ein nacktes 8080 wird zur Zahl 8080, ein leerer Wert wird zu null – praktisch, bis die Inferenz etwas typisiert, das Sie als Text gemeint haben, etwa einen Ländercode oder eine Versionszeichenkette.
Der klassische Ausfall ist eine Liste von ISO-Ländercodes, in der NO – Norwegen – als boolesch false geparst wird: das Norwegen-Problem, lustig, bis es still und leise ein Deployment-Flag deaktiviert. Version 1.1 ging deutlich weiter, wie die Tabelle zeigt. Das 1.2-Core-Schema löst nur true und false als boolesche Werte auf und liest alles Übrige in der Tabelle unten als schlichte Zeichenketten oder Dezimalzahlen – doch weil so viel eingesetzte Software weiterhin nach 1.1-Regeln arbeitet, lautet die defensive Gewohnheit: alles quoten, was eine Zeichenkette bleiben muss.
| Sie schrieben | YAML 1.1 parst es als | Das YAML-1.2-Core-Schema parst es als |
|---|---|---|
| no | boolesch false | die Zeichenkette "no" |
| on / off | boolesch true / false | die Zeichenketten "on" / "off" |
| 12:30 | Ganzzahl 750 (sexagesimal) | die Zeichenkette "12:30" |
| 0640 | Ganzzahl 416 (oktal) | Ganzzahl 640 (dezimal) |
| 2026-09-19 | ein Datumsobjekt | die Zeichenkette "2026-09-19" |
| ~ | null | null |
Anführungszeichen und Blockskalare
YAML bietet drei Wege, eine Zeichenkette zu schreiben. Ohne Anführungszeichen ist der Standard und für die meisten Werte in Ordnung. Einfache Anführungszeichen sind literal – das einzige Escape ist das Verdoppeln eines Apostrophs ('it''s fine'). Doppelte Anführungszeichen unterstützen Backslash-Escapes wie \n und \t, den Stil, den JSON verwendet. Die defensive Regel gilt hier genauso: Enthält ein Wert etwas, das man für Struktur halten könnte – Doppelpunkte, Rauten, reservierte Wörter –, setzen Sie ihn gezielt in Anführungszeichen.
Mehrzeiligen Text bringen Blockskalare unter. Ein literaler Block, geschrieben als |, behält jeden Zeilenumbruch exakt so, wie er getippt wurde – die richtige Form für Shell-Skripte und Zertifikate. Ein gefalteter Block, geschrieben als >, fügt die Zeilen zu einem durchlaufenden Absatz zusammen – die richtige Form für eine lange Beschreibung. Beide akzeptieren eine Chomping-Angabe: |- entfernt den letzten Zeilenumbruch, |+ behält alle abschließenden, und ein schlichtes | behält genau einen.
Zwei Blockskalar-Stile
script: | set -e make build make deploy summary: > Deploys finish in under a minute.
Was die Skalare am Ende ergeben
script: "set -e\nmake build\nmake deploy\n" summary: "Deploys finish in under a minute.\n"
Anker, Aliasse und Wiederverwendung
YAML erlaubt einem Knoten, einen Namen zu tragen, auf den andere Knoten verweisen. Schreiben Sie &name hinter einen Schlüssel, um dessen Wert zu ankern; schreiben Sie *name an einer beliebigen anderen Stelle, um ihn zu aliasieren, und der Parser setzt eine Kopie des verankerten Knotens ein. Jobs, die sich eine Retry-Policy teilen, verweisen dann auf eine einzige Definition, und die Änderung landet genau einmal.
Zwei Erweiterungen setzen auf diesem Mechanismus auf. Merge-Keys, geschrieben als <<: *name, fügen alle Schlüssel eines verankerten Mappings in das aktuelle ein – verbreitet in Compose- und Ansible-Dateien, und eine Konvention aus der 1.1-Ära, die nie Eingang in die 1.2-Core-Grammatik fand. Anker lassen sich auch missbrauchen: Aliasse, die in Aliassen verschachtelt sind, lassen zehn Definitionen zu einer Million Knoten anwachsen – der Billion-Laughs-Angriff –, deshalb budgetieren Parser, denen Sie vertrauen, die Expansion und melden die Obergrenze, statt sich aufzuhängen.
Ein Anker und zwei Aliasse
defaults: &base retries: 3 timeout: 30s staging: retries: 3 timeout: 30s log: *base
Was ein Verbraucher erhält
defaults: { retries: 3, timeout: "30s" }
log alias: { retries: 3, timeout: "30s" } (staging.log)Kommentare und mehrere Dokumente
Kommentare beginnen mit # und reichen bis zum Zeilenende; eine Raute innerhalb einer quotierten Zeichenkette zählt nicht. Das ist YAMLs größter ergonomischer Vorsprung gegenüber JSON, das Kommentare mit Absicht gestrichen hat, und der Grund, warum von Hand gepflegte Konfiguration hierher driftet: Die Datei erklärt sich inline selbst, und in Reviews stehen eine Zeile und ihr Kommentar gemeinsam in einem Diff-Hunk.
Eine Datei darf auch mehrere Dokumente enthalten, getrennt durch Zeilen mit drei Strichen; ein führendes --- ist die optionale Startmarkierung, und ... beendet ein Dokument. So trägt ein einziges Artefakt eine Staging-Konfiguration und eine Produktivkonfiguration nebeneinander her. Die Konverter dieser Website parsen jedes Dokument und arbeiten auf dem letzten – wie gängige CLIs es auch tun.
Zwei Dokumente, eine Datei
env: staging region: eu-1 --- env: production region: us-2
Womit die Konverter arbeiten
env: production region: us-2 (the last document)
Was die Konverter dieser Website akzeptieren
Jeder YAML-Parser ist ein Parser einer Teilmenge – die vollständige 1.2-Grammatik ist notorisch groß –, und ein Konverter gewinnt Vertrauen, indem er seine Teilmenge benennt, statt Sie beim Scheitern darüber aufklären zu lassen. Die YAML-Bibliothek dieser Website implementiert das 1.2-Core-Schema über die Block- und Flow-Konstrukte, die in echten Konfigurationsdateien vorkommen, mit bewussten Grenzen dort, wo der Standard unbegrenzte Arbeit erlaubt. Die Tabelle ist der Vertrag.
| Funktion | Status hier | Verhalten |
|---|---|---|
| Block-Mappings und -Sequenzen | Akzeptiert | Beliebig tief verschachtelt, zwei Leerzeichen oder jede konsistente Einrückung |
| Flow-Stil [1, 2] und {a: 1} | Akzeptiert | Auch ganze JSON-Dokumente, unverändert eingefügt |
| Kommentare und Skalare in Anführungszeichen | Akzeptiert | Beide Anführungszeichen-Stile, alle Blockskalar-Stile |
| Tabs in der Einrückung | Abgelehnt | Zurückgewiesen mit Angabe der betroffenen Zeilennummer |
| Explizite Schlüssel (? key) | Abgelehnt | Kein JSON-Äquivalent – JSON-Schlüssel müssen Zeichenketten sein |
| Merge-Keys (<<) | Abgelehnt | Lösen Sie den Merge von Hand auf oder aliasieren Sie Werte direkt |
| Direktive %YAML 1.1 | Mit Warnung | Das 1.2-Core-Schema wird angewendet; yes und no bleiben Zeichenketten |
| Mehrere Dokumente | Geparst | Die Konverter arbeiten auf dem letzten Dokument |
| Alias-Expansion | Budgetiert | Tiefe Alias-Ketten werden begrenzt und gemeldet, nie vollständig entrollt |
Häufig gestellte Fragen
Werden meine YAML-Daten hochgeladen, wenn ich diese Konverter benutze?
Nein. Jeder Konverter auf dieser Website läuft als JavaScript in Ihrem Browser-Tab; es gibt keinen Upload-Schritt und kein Backend, das einen empfangen könnte. Prüfen Sie es in den DevTools: Öffnen Sie das Netzwerk-Panel, konvertieren Sie eine Datei und beobachten Sie, wie die Anfrageliste leer bleibt. Die Content-Security-Policy der Website blockiert außerdem ausgehende Verbindungen von Seitenskripten.
Warum lässt sich meine Datei nicht parsen, obwohl sie richtig aussieht?
Drei Übeltäter decken die meisten Fälle ab: ein Tab, der sich in der Einrückung versteckt (Parser lehnen Tabs kategorisch ab), ein YAML-1.1-Überbleibsel wie ein nacktes no oder ein Merge-Key, den ein 1.2-Parser nicht zu erraten versucht, oder ein Skalar ohne Anführungszeichen, den die Inferenz in etwas typisiert hat, das Sie nicht gemeint haben. Ein guter Konverter nennt die Zeile; das tut der auf dieser Website.
Ist YAML eine Obermenge von JSON?
In YAML 1.2: meistens ja. Ein JSON-Dokument mit intakten geschweiften und eckigen Klammern lässt sich unverändert als YAML parsen. Umgekehrt gilt das nie. Kommentare, Anker, nackte Schlüssel, mehrzeilige Blockskalare und mehrere Dokumente in einer Datei haben keine JSON-Repräsentation, daher ist die Umwandlung von YAML nach JSON für jede Datei, die sie benutzt, eine Einbahnstraße.
Wie vermeide ich das Norwegen-Problem?
Setzen Sie jeden Skalar in Anführungszeichen, dessen Typ Ihnen wichtig ist. Ein nacktes NO wird nach YAML-1.1-Regeln als boolesch false geparst, und on, off, yes und no folgen ihm; das 1.2-Core-Schema hält sie als Zeichenketten, aber viel eingesetzte Software lädt weiterhin 1.1. Ländercodes, Feature-Flags und Versionszeichenketten zu quoten kostet nichts – machen Sie es zur Gewohnheit.
Sollte ich Anker verwenden oder die Werte einfach wiederholen?
Wiederholen Sie Werte, wenn die Kopien auseinanderdriften können; ankern und aliasieren Sie sie, wenn sie wirklich ein einziges, einmal definiertes Faktum sind. Anker halten die Konfiguration DRY, kosten aber lokale Lesbarkeit – ein Leser muss zur Definition springen. Merge-Keys sind der am wenigsten portable Teil: Viele Parser, darunter die Konverter dieser Website, lehnen sie ab, statt die Einfügereihenfolge zu raten.
Zwei Leerzeichen oder vier Leerzeichen für die YAML-Einrückung?
Beides ist gültig – der Standard verbietet Tabs, nicht irgendeine Leerzeichenanzahl –, also ist es Konvention, nicht Korrektheit. Zwei Leerzeichen haben gewonnen: Kubernetes und Compose verwenden sie, jeder Linter stellt sie standardmäßig ein, und tiefe Verschachtelung bleibt lesbar. Entscheidend ist, die Breiten nie innerhalb einer Datei zu mischen.
Wo kann ich die hier zitierten Standards nachlesen?
Welche verwandten Tools sollten Sie als Nächstes nutzen?
- Was ist JSONLeitfaden in verständlicher SpracheÖffnen
- JSON vs. YAMLDirekter VergleichÖffnen
- JSON formatierenEinrückung und Sortierung einstellen, Kommentare entfernenÖffnen
- Syntax von Cron-AusdrückenLeitfaden in verständlicher SpracheÖffnen
- Cron-Ausdruck prüfenEinen Zeitplan lesen und sehen, wann er tatsächlich läuftÖffnen
- Text-ToolsText und Code vergleichen, umwandeln und umformen.Öffnen