JSON vs. YAML: Das richtige Konfigurationsformat wählen

JSON und YAML sehen aus wie dieselbe Sache in unterschiedlichen Kostümen, bis Sie versuchen, eine tausendzeilige Konfigurationsdatei in einem von beiden zu pflegen. Die Unterschiede zählen, und die meisten davon betreffen nicht die Syntax — sie betreffen, was jedes Format tut, wenn Sie ein bisschen daneben liegen.

Dasselbe Beispiel in beiden

Der kürzeste Weg, den Unterschied zu spüren, ist identische Daten nebeneinander zu lesen.

JSON

{
  "name": "convertitive",
  "version": "1.4.0",
  "ports": [80, 443],
  "features": {
    "darkMode": true,
    "telemetry": false
  },
  "owners": ["[email protected]", "[email protected]"]
}

YAML

name: convertitive
version: 1.4.0
ports:
  - 80
  - 443
features:
  darkMode: true
  telemetry: false
owners:
  - [email protected]
  - [email protected]

Das YAML ist etwa 30 % kürzer und für einen Menschen, der beides noch nie gesehen hat, wohl besser lesbar. Das JSON ist für eine Maschine eindeutig, parserfreundlich und übersteht Kopieren-Einfügen durch jeden Texteditor auf jedem Betriebssystem ohne Schaden durch unsichtbare Zeichen.

Diese Zusammenfassung ist der größte Teil der Wahl, aber die Details darunter sind, wo Projekte in Schwierigkeiten geraten.

Worin YAML gewinnt

Kommentare

YAML unterstützt # line commentsüberall. JSON nicht — RFC 8259 schließt sie bewusst aus. Für eine Konfigurationsdatei, die Menschen lesen und bearbeiten, sind Kommentare kein nettes Extra; sie sind die Art, wie man dokumentiert, warum ein Flag aus ist oder welchen Wertebereich eine Einstellung tatsächlich akzeptiert.

# pin to a specific patch release; do not auto-update
version: 1.4.0

ports:
  - 80
  # 443 is here so the LB health check works; do not remove
  - 443

JSON5 und JSONC fügen Kommentarunterstützung hinzu, sind aber nicht JSON — ein strikter Parser wird sie ablehnen. Wenn Ihre Konfiguration von Code konsumiert wird, den Sie nicht kontrollieren, ist das ein K.-o.-Kriterium.

Mehrzeilige Strings

YAML hat zwei Block-Skalar-Stile für mehrzeilige Strings. | bewahrt Zeilenumbrüche, > faltet sie zu Leerzeichen. Beide lassen Sie absatzlange Werte ohne Escape-Suppe schreiben:

description: |
  Convertitive is a tools site.
  It loads fast and has no popups.

summary: >
  A single sentence written across
  multiple lines for editor comfort.

Das JSON-Äquivalent ist eine lange Zeile mit \n-Escapes, was für ein Feld in Ordnung und für fünfzig elend ist.

Anker und Aliasse

YAML lässt Sie einen Knoten mit & beschriften und ihn anderswo mit * referenzieren. Merge-Keys (<<) erweitern ein Mapping mit einem anderen. Das Ergebnis ist echtes DRY in einer Konfigurationsdatei:

defaults: &defaults
  retries: 3
  timeout_ms: 5000

production:
  <<: *defaults
  endpoint: api.example.com

staging:
  <<: *defaults
  endpoint: staging.api.example.com
  timeout_ms: 30000  # overrides the default

JSON hat nichts Äquivalentes. Der Workaround ist entweder Templating (Jinja, Helm) oder Nachbearbeitung beim Laden, beide fügen Maschinerie hinzu, die JSON-native Konfigurationen vermeiden.

Visuelle Überschaubarkeit

Einrückung-als-Struktur ist der wichtigste Grund, warum Teams YAML wählen. Ein tief verschachteltes Dokument liest sich von oben nach unten; man verliert nicht den Faden beim Zählen von Klammern. Deshalb ist jedes Kubernetes-Manifest YAML und jedes Ansible-Playbook YAML.

Worin JSON gewinnt

Eindeutiges Parsen

JSON hat eine fünfseitige Grammatik. Zwei korrekte Parser stimmen bei jedem Dokument überein. YAML hat eine neunzigseitige Grammatik mit mehreren gültigen Interpretationen desselben Dokuments, je nach Parser-Version. JSONs Striktheit ist das Feature.

Tooling-Allgegenwart

Jede Sprache liefert einen JSON-Parser in ihrer Standardbibliothek mit. YAML erfordert in den meisten Umgebungen eine Drittanbieter-Abhängigkeit — PyYAML, js-yaml, snakeyaml, go-yaml. Für eine Konfigurationsdatei, die in ein Tool eingebettet ist, das überall laufen muss, zählt JSONs Zero-Dependency-Geschichte.

Übersteht jeden Textkanal

JSON hat keinen signifikanten Whitespace. Sie können es in einen Chat-Client, eine E-Mail, eine Shell-Eingabe einfügen; Sie können es minifizieren; Sie können es ohne nachzudenken über einen HTTP-Body schicken. YAML hat signifikanten Whitespace, und ein einzelner Tab-vs.-Leerzeichen-Fehler bricht das Dokument.

Das Norwegen-Problem — wörtlich

Der berühmteste YAML-Fallstrick: In YAML 1.1 parst der String NO als der Boolean false. Länderlisten, die Norwegens ISO-Code (NO) enthalten, werden zu [false, ...], es sei denn, sie sind in Anführungszeichen gesetzt. Dasselbe passiert mit YES, ON, OFF und diversen Schreibweisen. YAML 1.2 behebt das, indem es nur kleingeschriebenes true und falseals Booleans behandelt, aber erstaunlich viel Tooling steht 2026 noch standardmäßig auf 1.1 — der Standard-Loader des Python-yaml-Moduls ist zum Beispiel YAML 1.1.

JSON hat keine vergleichbare Überraschung.“NO“ ist ein String.true ist ein Boolean. Es gibt keine Versions-Mehrdeutigkeit zu erben.

Sicherheits-Standards

YAMLs Spezifikation enthält Typ-Tags, die ein Dokument den Parser anweisen lassen, beliebige Klassen zu instanziieren. Mehrere Sprach-Bindings respektierten das jahrelang standardmäßig, was bedeutet, dass das Laden eines vom Angreifer kontrollierten YAML-Dokuments beliebigen Code ausführen konnte — dieselbe Fehlerklasse wie Java-Deserialisierung. Die Lösung ist, einen “safe”-Loader zu verwenden (yaml.safe_load in Python, YAML.safe_load in Ruby), der nur primitive Typen ausgibt.

JSON hat keinen solchen Mechanismus. Das Schlimmste, was ein bösartiges JSON-Dokument tun kann, ist, den Parser mit einer tief verschachtelten Struktur zum Absturz zu bringen oder den Speicher mit einem langen String zu erschöpfen. Beides ist leichter abzuwehren als RCE.

Gemeinsame Fallstricke

JSON-Zahlengenauigkeit

JSONs Spezifikation sagt, dass Zahlen von beliebiger Größenordnung und Genauigkeit sein können. JavaScriptsJSON.parse und die meisten Nicht-JS-Implementierungen deserialisieren sie tatsächlich in IEEE-754-Doubles, die Ganzzahlen nur bis 2^53 - 1 (etwa 9.007 * 10^15) exakt darstellen können. Eine Twitter-Snowflake-ID, eine Stripe-Charge-ID oder jede 19-stellige Ganzzahl wird still gerundet. Die Lösung ist, große Ganzzahlen als Strings zu kodieren (Twitter, Discord und Stripe tun das alle in ihren JSON-APIs) oder einen Parser mit BigInt-Unterstützung zu verwenden.

YAML erbt dasselbe Problem in jeder Sprache, die Ganzzahlen in einen Typ fester Breite deserialisiert. Die Abhilfe ist dieselbe: große Ganzzahlen in Anführungszeichen setzen, wenn Genauigkeit zählt.

YAML-Versionsdrift

YAML 1.1 (2005) und YAML 1.2 (2009) sind die beiden Versionen in freier Wildbahn. 1.2 ist eine strikte Obermenge von JSON, behob das Norwegen-Problem und verschärfte die Spezifikation erheblich. Viele Parser stehen still noch standardmäßig auf 1.1. Das Erste, was bei einer neuen YAML-Codebasis zu tun ist: festzustellen, welche Version der Parser verwendet, und die Antwort in die README zu schreiben.

Doppelte Schlüssel

JSONs Spezifikation sagt nicht, was bei doppelten Schlüsseln zu tun ist; Parser sind uneins (die meisten nehmen den letzten Wert, manche werfen einen Fehler, manche geben beide zurück). YAMLs Spezifikation sagt, dass Duplikate ein Fehler sind, aber viele Parser tolerieren sie. In beiden gilt: schreiben Sie nie doppelte Schlüssel und validieren Sie mit einem Schema, wenn Ihre Eingabe nicht vertrauenswürdig ist.

Ein Entscheidungsbaum

Für neue Projekte, bei denen Sie den Konsumenten kontrollieren:

1. Maschine-zu-Maschine-Übertragungsformat? JSON verwenden. Jede Sprache parst es, Kommentare spielen keine Rolle, und die Striktheit beseitigt eine ganze Klasse von Integrationsfehlern.
2. Von Menschen bearbeitete Konfiguration unter 100 Zeilen? YAML verwenden, wenn der Konsument YAML erwartet, sonst TOML. Beide unterstützen Kommentare; TOML ist weniger überraschend.
3. Von Menschen bearbeitete Konfiguration über 100 Zeilen, tief verschachtelt? YAMLs Anker und Block-Skalare fangen bei dieser Größe an, sich zu lohnen. In der Dokumentation auf YAML 1.2 festlegen.
4. Nicht vertrauenswürdige Eingabe? JSON ist standardmäßig sicherer. Wenn Sie YAML akzeptieren müssen, verwenden Sie den Safe-Loader und ein Schema.
5. Konsument steht fest (Kubernetes, npm)? Dem Konsumenten entsprechen. Kämpfen Sie nicht gegen das Ökosystem.

Zwischen ihnen konvertieren

Die Konvertierung ist mechanisch, weil YAML 1.2 eine JSON-Obermenge ist. JSON rein, YAML raus ist immer verlustfrei. YAML rein, JSON raus ist nur dann verlustfrei, wenn das YAML primitive Typen und keine Anker/Aliasse verwendet, die eine Expansion erfordern würden.

Unser JSON ↔ YAML Konverter bewältigt beide Richtungen im Browser und zeigt Ihnen die Zeile, in der das Parsen scheitert, wenn die Eingabe ungültig ist. Für reine JSON-Arbeit — Hübsch-Ausgabe, Validieren, Minifizieren — ist der JSON- Formatierer das schärfere Werkzeug.

Die ehrliche Erkenntnis

JSON ist der richtige Standard für alles, worauf sich zwei Programme einigen müssen. YAML ist der richtige Standard für alles, was ein Mensch ausführlich bearbeitet. Die meisten Produktivsysteme enden mit beidem: YAML an der Mensch-Grenze (Helm-Charts, GitHub-Actions-Workflows, Anwendungskonfiguration), JSON über die Leitung und ruhend in Datenbanken.

Die falsche Antwort ist, das Format zu wählen, das man zuerst gesehen hat, und es für alles zu verwenden. JSON für eine tausendzeilige Konfiguration ohne Kommentare ist feindselig. YAML für einen HTTP-Antwort-Body lädt jeden Fallstrick aus diesem Artikel ein. Passen Sie das Format an den Konsumenten und den Editor an, und lesen Sie die Norwegen-Geschichte einmal pro Quartal noch einmal, damit Sie paranoid bleiben.