YAML-Formatierer & Validierer

Fügen Sie YAML ein, um es zu formatieren und zu validieren. Sehen Sie Fehler sofort, korrigieren Sie die Einrückung und konvertieren Sie nach JSON.

Lokal verarbeitet · nichts wird an einen Server gesendet
YAML zum Validieren einfügen

Was ist YAML?

YAML (YAML Ain't Markup Language) ist ein menschenlesbares Datenserialisierungsformat, das für Konfigurationsdateien (Docker, Kubernetes, GitHub Actions, Ansible), Datenaustausch und mehr genutzt wird. Es verwendet Einrückung statt geschweifter Klammern und ist eine Obermenge von JSON.

Häufige Fragen

Welche Fehler erkennt der Validator?

Einrückungsfehler, fehlende Doppelpunkte, doppelte Schlüssel, ungültige Zeichen, nicht geschlossene Zeichenketten, falsche Verschachtelungen und andere YAML-Syntaxprobleme. Fehlermeldungen enthalten Zeilennummern.

Kann ich YAML in JSON konvertieren?

Ja! Klicken Sie auf den Button „→ JSON", um Ihr YAML in sauber formatiertes JSON umzuwandeln. Für die umgekehrte Richtung nutzen Sie unseren JSON-zu-YAML-Konverter.

Ein kurzer Rundgang durch YAML

YAML 1.0 wurde 2001 von Clark Evans, Ingy döt Net und Oren Ben-Kiki veröffentlicht; YAML 1.1 folgte 2005, und die aktuelle Version ist YAML 1.2.2, die mehrere historische Fallstricke behob (insbesondere das „Norwegen-Problem“, siehe unten) und als strikte Obermenge von JSON konzipiert wurde. Die offizielle Spezifikation finden Sie unter yaml.org/spec/1.2.2. Dieser Formatierer verwendet die quelloffene Bibliothek js-yaml, die standardmäßig gegen das YAML-1.2-Schema parst, sodass die meisten der alten 1.1-Eigenheiten für hier formatierten Text nicht gelten, wohl aber für die meisten serverseitigen YAML-Werkzeuge, an die Sie die Ausgabe senden.

Wo YAML tatsächlich vorkommt

YAML hat sich als Konfigurationsformat für cloud-native Infrastruktur durchgesetzt. Die Orte, an denen Sie ihm am häufigsten begegnen:

Die Leerraum-Falle (nur Leerzeichen)

YAML verwendet Einrückung, um Struktur auszudrücken, und die Spezifikation ist eindeutig, dass Tabs zur Einrückung nicht erlaubt sind. Nur Leerzeichen. Das ist die mit Abstand häufigste Fehlerquelle in handgeschriebenem YAML, besonders weil viele Editoren je nach Einstellung stillschweigend Tabs und Leerzeichen mischen. Die Fehlermeldung, die Sie von einem strengen Parser erhalten, lautet sinngemäß „found character '\t' that cannot start any token“, übersetzt: „Sie haben irgendwo einen Tab verwendet.“ Die Lösung ist universell: Aktivieren Sie „Leerraum anzeigen“ in Ihrem Editor und wandeln Sie jeden Tab in zwei oder vier Leerzeichen um.

Die Einrückungsgröße ist eher Konvention als Spezifikation. 2 Leerzeichen sind der De-facto-Standard für Kubernetes-Manifeste, GitHub Actions und das meiste YAML, das Sie im modernen Web lesen. 4 Leerzeichen sind in Ansible verbreiteter. Die Regel, auf die es ankommt: Seien Sie innerhalb einer einzelnen Datei konsistent. Das Mischen von 2 und 4 Leerzeichen zwischen Geschwisterschlüsseln bringt Parser zu Fall, nicht die Größe, die Sie wählen.

Das Norwegen-Problem (und warum Sie mehrdeutige Zeichenketten in Anführungszeichen setzen sollten)

YAML 1.1 (noch immer der Standard in PyYAML, snakeyaml und vielen anderen serverseitigen Parsern) interpretiert eine lange Liste von Boolean-Schreibweisen ohne Anführungszeichen als echte Booleans: true, True, TRUE, false, False, FALSE, yes, Yes, YES, no, No, NO, y, n, on, off. Die berühmte Falle: Der ISO-Ländercode für Norwegen ist NO. Eine YAML-Konfiguration, die Länder als Zeichenketten ohne Anführungszeichen auflistet, parst Norwegen stillschweigend als den Boolean false, und nachgelagerter Code, der countries[0] == 'NO' liest, schlägt auf verwirrende Weise fehl.

YAML 1.2 (und das Standardschema von js-yaml) beschränkte Booleans auf nur true / false, was das Norwegen-Problem auf Parser-Ebene behebt. Aber viele Werkzeuge in der Praxis verwenden aus Gründen der Abwärtskompatibilität weiterhin standardmäßig das YAML-1.1-Schema. Die defensive Angewohnheit: Setzen Sie jede Zeichenkette in Anführungszeichen, die wie ein Boolean, eine Zahl, ein Datum oder eine Version aussehen könnte. country: "NO", postal_code: "01234", version: "1.10", time: "10:30". Anführungszeichen sind der universelle Vereindeutiger.

Weitere Fallstricke bei der Typumwandlung

Block-Stil vs. Flow-Stil

YAML unterstützt zwei Notationen für dieselben Daten:

# Block style (the standard, indentation-based)
person:
  name: Alice
  tags:
    - admin
    - billing

# Flow style (JSON-like inline)
person: { name: Alice, tags: [admin, billing] }

Den Block-Stil sehen Sie in 99 % des handgeschriebenen YAML, er macht das Format lesbar. Der Flow-Stil ist eine nützliche Ausweichmöglichkeit für kurze einzeilige Werte oder zum programmatischen Erzeugen von YAML, wo Sie die Einrückung lieber nicht im Blick behalten möchten. Der Formatierer normalisiert die Ausgabe auf den Block-Stil (die besser lesbare Form), unabhängig davon, welchen Stil Ihre Eingabe verwendet hat.

Anker und Aliase (der DRY-Trick)

Die Wiederverwendbarkeitsfunktion von YAML: Definieren Sie einen Wert einmal mit dem Anker &name und verweisen Sie anderswo mit dem Alias *name darauf. Praktisch für lange Konfigurationsdateien, in denen derselbe Wertblock mehrmals vorkommt.

defaults: &defaults
  region: us-east-1
  log_level: info

production:
  <<: *defaults
  log_level: warn   # override

staging:
  <<: *defaults

Ein paar Vorbehalte: Nicht jeder YAML-Prozessor unterstützt Anker und Aliase (insbesondere einige ältere Kubernetes-Manifest-Werkzeuge und bestimmte Helm-Kontexte). Die oben gezeigte <<:-„Merge-Key“-Syntax ist eine YAML-1.1-Erweiterung und in 1.2 offiziell veraltet, js-yaml unterstützt sie, reine 1.2-Parser aber möglicherweise nicht.

Mehrdokument-Dateien

Eine einzelne YAML-Datei kann mehrere Dokumente enthalten, getrennt durch ---. Verbreitet in Kubernetes: eine Datei mit einem Deployment, einem Service und einer ConfigMap, getrennt durch ---, angewendet mit einem einzigen kubectl apply -f:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
---
apiVersion: v1
kind: Service
metadata:
  name: app-svc

YAML vs. JSON vs. TOML

Wenn Sie bei neuer Konfiguration die Wahl haben: TOML für flache Konfiguration, YAML, wenn Sie tiefe Verschachtelung brauchen und das Ökosystem sich darauf standardisiert hat (Kubernetes, Ansible), JSON, wenn eine Maschine es schreibt. YAML ist das richtige Format, wenn Menschen tief verschachtelte Konfiguration lesen und aussagekräftige Kommentare inline schreiben müssen.

Datenschutz

YAML-Konfigurationen enthalten häufig Geheimnisse, die nicht über den Server eines anderen laufen sollten: Base64-Blobs von Kubernetes-Secrets, Datenbankpasswörter in application.yml, API-Schlüssel in CI-Workflows, interne Hostnamen in Deployment-Konfigurationen. Der Formatierer läuft vollständig in Ihrem Browser über die quelloffene Bibliothek js-yaml, eingefügter Inhalt wird lokal geparst und neu ausgegeben, ohne Abruf / ohne Upload / ohne Protokollierung. Das Schließen des Tabs löscht alles.

Häufige Fehler

  1. Tabs und Leerzeichen in der Einrückung mischen. Der häufigste Fehler. Tabs sind durch die Spezifikation verboten; manche Editoren fügen sie stillschweigend ein. Lassen Sie sich in Ihrem Editor den Leerraum anzeigen.
  2. Uneinheitliche Einrückung zwischen Geschwistern. Geschwisterschlüssel müssen an derselben Spalte ausgerichtet sein. Gemischte 2/4-Leerzeichen-Einrückung bricht das Parsen.
  3. Werte ohne Anführungszeichen, die wie Booleans, Zahlen, Daten oder Uhrzeiten aussehen. NO, 012, 1.10, 10:30, yes: Setzen Sie sie in Anführungszeichen.
  4. Fehlendes Leerzeichen nach dem Doppelpunkt. key: value funktioniert; key:value ist ungültig (wird als einzelne Zeichenkette geparst).
  5. Nachgestellter Leerraum. Manche Parser behandeln nachgestellte Leerzeichen als bedeutsam, manche nicht. Die werkzeugübergreifend sichere Angewohnheit ist, nachgestellten Leerraum zu entfernen.
  6. Mehrzeilige Zeichenketten ohne den richtigen Block-Skalar. Lange Zeichenketten brauchen | (literal, bewahrt Zeilenumbrüche) oder > (gefaltet, fügt Zeilen zusammen). Schlichter mehrzeiliger Text ohne Anführungszeichen verhält sich selten so, wie Sie es erwarten.
  7. Anker / Aliase überall vorausgesetzt. Helm und einige Kubernetes-Kontexte unterstützen &/* nicht vollständig. Testen Sie in Ihrer echten Pipeline, bevor Sie sich darauf verlassen.
  8. Kodierungs-Unstimmigkeiten. YAML-Dateien sollten UTF-8 sein. Ein Windows-Editor, der als UTF-16 mit BOM speichert, erzeugt Dateien, die manche Parser nicht lesen können.

Weitere häufig gestellte Fragen

Bleiben meine Kommentare durch den Formatierer erhalten?

Nein. Die js-yaml-Bibliothek parst YAML in einen JavaScript-Wert und gibt es aus diesem Wert neu aus, was bedeutet, dass Kommentare (# like this) verworfen werden, sie leben im Quelltext, nicht in der geparsten Struktur. Wenn der Erhalt von Kommentaren wichtig ist (was bei handgepflegten Konfigurationsdateien meist der Fall ist), verwenden Sie eine kommentarerhaltende Alternative wie eemeli/yaml über deren CST-API oder nehmen Sie kleine Änderungen von Hand vor, statt sie durch diesen Formatierer hin- und herzuschicken.

Warum wird mein NO vom YAML-Parser meines Servers als Boolean behandelt?

Weil dieser Parser YAML 1.1 verwendet (der Standard für PyYAML, snakeyaml und viele andere), der NO als den Boolean false interpretiert. Dieser Formatierer verwendet standardmäßig YAML 1.2 (über js-yaml), löst den Fehler hier also nicht aus, aber in dem Moment, in dem Sie die Datei in eine YAML-1.1-Umgebung ausliefern, wird die Falle aktiv. Setzen Sie mehrdeutige Zeichenketten immer in Anführungszeichen: country: "NO".

Kann ich YAML in JSON umwandeln?

Ja, klicken Sie auf „→ JSON“. Die Umwandlung ist verlustfrei für alles, was sich in JSON darstellen lässt (Zeichenketten, Zahlen, Booleans, null, Arrays, Objekte). Was nicht erhalten bleibt: Kommentare (JSON hat keine Syntax dafür), Anker und Aliase (JSON hat kein Äquivalent) und die Datums-/Zeitstempel-Typen von YAML (die in JSON zu Zeichenketten werden). Für die umgekehrte Richtung verwenden Sie das eigene Werkzeug JSON zu YAML.

Werden Daten an einen Server gesendet?

Nein. Das gesamte Parsen, Formatieren und die JSON-Umwandlung laufen über js-yaml in Ihrem Browser. Das eingefügte YAML wird nie an einen Server übertragen. Das ist wichtig, weil YAML-Konfigurationen häufig Geheimnisse enthalten (Werte von Kubernetes-Secrets, Datenbankpasswörter, API-Schlüssel, interne Endpunkte), die nicht zu einem Drittanbieterdienst hochgeladen werden sollten.

Wie ist die Größenbegrenzung?

Keine harte Grenze, der Formatierer läuft im Speicher Ihres Browsers. Typische Kubernetes-Manifeste (ein paar KB) und Helm-Charts (Dutzende KB) werden sofort formatiert. Sehr große Mehrdokument-Dateien (mehrere MB) können langsam sein, funktionieren aber im Allgemeinen; wenn Sie ein 10 MB großes Helm-Chart haben, formatieren Sie es stattdessen lokal mit einem CLI-Werkzeug.

Warum ist YAML so fehleranfällig?

Drei Gründe, die sich verstärken: (1) Bedeutungstragender Leerraum führt dazu, dass Tippfehler stille semantische Änderungen verursachen; (2) die permissive Typumwandlung von YAML 1.1 macht aus mehrdeutigen Zeichenketten ungewollte Booleans / Zahlen; (3) das Format hat zu viele Arten, dasselbe zu schreiben (Block vs. Flow, einfache vs. doppelte Anführungszeichen, drei Varianten mehrzeiliger Zeichenketten). Die defensiven Angewohnheiten, immer in Anführungszeichen setzen, immer konsistent mit der Einrückung sein, vor dem Deployment validieren, beheben den größten Teil der Angriffsfläche.

Verwandte Tools

JSON-zu-YAML-Konverter

Zwischen JSON- und YAML-Formaten konvertieren.

JSON-Formatter

JSON-Daten formatieren, validieren und verschönern.

XML-Formatter

XML formatieren, verschönern oder minimieren.