Konfigurationsformate wählen: JSON, YAML oder TOML

Worum es geht

JSON nach RFC 8259 kennt Objekte, Arrays, Zeichenketten, Zahlen, true, false und null – und keine Kommentare. Die RFC sagt, dass Namen innerhalb eines Objekts eindeutig sein sollten (SHOULD) und dass das Verhalten empfangender Software bei doppelten Namen unvorhersehbar ist: Manche melden nur das letzte Paar, andere einen Fehler. YAML 1.2 wurde laut seiner Spezifikation mit dem Hauptziel entworfen, eine strikte Obermenge von JSON zu sein, und hat viele der problematischen Empfehlungen zur impliziten Typisierung entfernt; im Kern-Schema (Core Schema) werden unzitierte Skalare weiterhin nach Muster aufgelöst, sodass true, True und TRUE Wahrheitswerte sind, während Lader nach dem älteren 1.1-Modell auch yes, no, on und off so behandeln. TOML 1.0 will nach eigener Zielsetzung ein minimales Konfigurationsformat sein, das wegen offensichtlicher Semantik leicht zu lesen ist und eindeutig auf eine Hash-Tabelle abbildet; es hat Kommentare, explizite Typen (Zeichenkette, Ganzzahl, Gleitkommazahl, Wahrheitswert, Datum und Zeit), Tabellen in eckigen Klammern, gepunktete Schlüssel und Inline-Tabellen, die auf einer Zeile stehen sollen.

Warum es wichtig ist

Eine Konfigurationsdatei wird von Menschen geschrieben und von Programmen gelesen; das Format bestimmt, an welchem Ende die Fehler passieren. Einrückungsfehler und stille Typumwandlungen sind die YAML-Fehlerklasse (version: 1.10 wird zur Zahl 1.1, ein Länderkürzel NO in einem 1.1-Lader zu false); fehlende Kommentare und doppelte Schlüssel sind die JSON-Fehlerklasse; TOML zwingt bei tiefer Verschachtelung zu langen Tabellenpfaden.

So wird es angewendet

• Maschine zu Maschine (APIs, Caches, Export): JSON, gegen ein JSON-Schema geprüft.
• Von Hand gepflegte Konfiguration mit flacher bis mittlerer Struktur: TOML – Python (pyproject.toml), Rust (Cargo) und viele Werkzeuge nutzen es.
• YAML dort, wo das Ökosystem es vorgibt (CI-Pipelines, Kubernetes, Compose): Zeichenketten zitieren, die wie Zahlen, Wahrheitswerte oder Zeiten aussehen; einen Lader nach dem 1.2-Kern-Schema wählen; keine benutzerdefinierten Tags laden.
• Unabhängig vom Format das geparste Ergebnis in ein typisiertes Modell überführen, unbekannte Schlüssel ablehnen und mit einer klaren Meldung abbrechen (Datei, Zeile, Schlüssel).
• Wer ein Format wechselt, konvertiert per Werkzeug und vergleicht das geparste Ergebnis beider Dateien, nicht den Text.

Stolpersteine

Ein JSON-Parser darf laut RFC Erweiterungen annehmen; Kommentare oder nachgestellte Kommas, die ein Werkzeug schluckt, lassen das nächste scheitern. YAML-Anker und Mehrfachdokumente sind für Menschen schwer zu prüfen. TOML-Inline-Tabellen dulden kein nachgestelltes Komma. 1e3 ist im Kern-Schema von YAML 1.2 eine Gleitkommazahl, in 1.1-Ladern eine Zeichenkette – ein Grund mehr, zu zitieren.