TOML vs JSON vs YAML: Welches Config-Format wählen?

Hier die Kurzfassung von TOML vs JSON vs YAML: JSON ist der Standard für den Maschinenaustausch, den jede Sprache parst, YAML ist das menschenfreundliche Format, das Kubernetes und CI-Pipelines antreibt, und TOML ist das explizite, typisierte Format, das für Tool- und Anwendungskonfiguration wie Cargo.toml und pyproject.toml gebaut wurde. Kein einzelnes Format gewinnt überall. Das richtige Config-Dateiformat hängt von drei Dingen ab: wer es bearbeitet, ob Sie Kommentare brauchen und wie strikt die Typen sein müssen.

Eine schnelle Faustregel: Wenn eine Maschine es schreibt und eine Maschine es liest, greifen Sie zu JSON. Bearbeitet eine Person täglich tief verschachtelte Infrastruktur von Hand, rechtfertigt YAML seine Komplexität. Und wollen Sie eine offensichtliche, typisierte Konfiguration, die schwer zu vermasseln ist, ist TOML die sicherste Wahl. Die drei sind keine echten Konkurrenten, sondern besetzen unterschiedliche Spuren: JSON für Maschinen, YAML für DevOps, TOML für Tooling-Konfiguration. Warum das so ist, zeigen die Beispiele weiter unten; die interessanten Fälle sind die Unterschiede, die tatsächlich Bugs verursachen, und die Entscheidungsmatrix am Ende.

Die 30-Sekunden-Antwort

Wenn Sie nur eine halbe Minute haben, fasst diese Tabelle den Config-Dateiformat-Vergleich zusammen.

	JSON	YAML	TOML
Kommentare	Nein	Ja (#)	Ja (#)
Datentypen	Explizit, minimal	Implizit (aus der Form abgeleitet)	Explizit, reichhaltig
Native Datumswerte	Nein	Versionsabhängig	Ja (vier Typen)
Verschachtelungsstil	Klammern {}	Einrückung	[section]-Header
Einrückungssensitiv	Nein	Ja (Tabs verboten)	Nein
Mehrzeilige Zeichenketten	Nein (nur \n)	Ja (| und >)	Ja (""")
Nachgestellte Kommas	Verboten	Entfällt	In Arrays erlaubt
Obermenge von JSON	—	Ja (1.2)	Nein
Am besten für	APIs, Datenaustausch	K8s, CI, Ansible	Rust/Python-Tooling-Konfiguration

Aus dieser Tabelle folgen drei einzeilige Urteile:

• Wählen Sie JSON, wenn die Datei von Programmen erzeugt und konsumiert wird: API-Payloads, package.json, tsconfig.json, alles, was eine Systemgrenze überschreitet.
• Wählen Sie YAML, wenn Menschen tiefe, verschachtelte Konfiguration von Hand bearbeiten und das Ökosystem es bereits erwartet: Kubernetes-Manifeste, GitHub Actions, Docker Compose, Ansible-Playbooks.
• Wählen Sie TOML, wenn Sie eine klare, typisierte Konfiguration für ein Tool oder eine Anwendung möchten, überwiegend flach mit ein paar Abschnitten, bearbeitet von Beitragenden mit unterschiedlichem Können: Cargo.toml, pyproject.toml, Hugo, Netlify.

Warum diese Urteile gelten, ist der interessante Teil, denn in den Gründen verstecken sich die echten Bugs.

Dieselbe Konfiguration, drei Wege

Nichts erklärt den Unterschied schneller als eine Konfiguration, dreimal geschrieben. Hier eine kleine Service-Konfiguration: ein Name und eine Version, ein paar Flags auf oberster Ebene, eine Liste von Features und ein verschachtelter Datenbank-Block.

JSON:

{
  "name": "acme-api",
  "version": "2.4.0",
  "debug": false,
  "released": "2026-07-02",
  "features": ["auth", "metrics", "tracing"],
  "database": {
    "host": "db.internal",
    "port": 5432,
    "max_connections": 100
  }
}

YAML:

name: acme-api
version: "2.4.0"
debug: false
released: "2026-07-02"
features:
  - auth
  - metrics
  - tracing
database:
  host: db.internal
  port: 5432
  max_connections: 100

TOML:

name = "acme-api"
version = "2.4.0"
debug = false
released = "2026-07-02"
features = ["auth", "metrics", "tracing"]

[database]
host = "db.internal"
port = 5432
max_connections = 100

Alle drei beschreiben identische Daten. Achten Sie darauf, woran Ihr Auge hängen bleibt. JSON trägt die meiste Interpunktion: Jeder Schlüssel steht in doppelten Anführungszeichen, jede Ebene fügt Klammern hinzu, und ein einziges verirrtes nachgestelltes Komma ist ein Syntaxfehler. YAML streicht fast all das, sodass die Struktur allein aus der Einrückung entsteht, was sich wunderbar liest, bis sich ein Tab einschleicht. TOML liegt dazwischen: Anführungszeichen nur bei Zeichenketten, key = value-Paare und ein [database]-Header, der den verschachtelten Block benennt, wie es eine alte INI-Datei täte. Beachten Sie, dass das Feld released in allen dreien eine Zeichenkette in Anführungszeichen ist, damit die Daten hier identisch bleiben. Das ist Absicht, denn Datumswerte sind genau der Punkt, an dem diese Formate aufhören, sich einig zu sein.

JSON – Der Standard für den Maschinenaustausch

JSON ist das Format, zu dem Sie ohne Nachdenken greifen, und meistens ist dieser Instinkt richtig. Jede gängige Sprache liefert einen Parser mit, jede HTTP-API spricht es, und seine Grammatik ist klein genug, um sie im Kopf zu behalten. Es ist strikt und eindeutig: Eine Zeichenkette ist eine Zeichenkette, 5432 ist eine Zahl, true ist ein Boolean, und es gibt genau einen Weg, jedes davon zu schreiben. Diese Striktheit macht JSON sicher für den Versand zwischen Systemen, die sich nie begegnet sind. Wenn ein Node-Dienst JSON an einen Go-Dienst sendet, stimmen beide Byte für Byte über die Bedeutung überein.

Genau diese Strenge ist der Grund, warum JSON auf seinem Heimterrain dominiert. package.json, tsconfig.json und composer.json sind JSON, weil Tools sie ständig erzeugen und umschreiben, und maschinengeschriebene Konfiguration will ein maschinenstriktes Format. Für API-Payloads und Message-Queues gibt es schlicht keinen Grund, etwas anderes zu wählen.

JSONs Schwächen zeigen sich alle in dem Moment, in dem ein Mensch es von Hand bearbeiten muss. Es gibt keine Kommentare. Es gibt keine nachgestellten Kommas, sodass das Umsortieren einer Liste bedeutet, Kommas zu korrigieren. Es gibt keine mehrzeiligen Zeichenketten, nur \n-Escapes. Jeder Schlüssel braucht doppelte Anführungszeichen. Und es gibt keinen Datumstyp, sodass 2026-07-02 als Zeichenkette in Anführungszeichen leben und per Konvention geparst werden muss. Für eine Konfigurationsdatei, die eine Person pflegt, summieren sich diese Lücken zu Reibung.

Das Problem „JSON hat keine Kommentare”

Das mit Abstand am häufigsten gewünschte JSON-Feature ist das, was Douglas Crockford bewusst weggelassen hat: Kommentare. Seine Begründung war, dass Kommentare Leute dazu verleiten, Parsing-Direktiven in Konfigurationsdateien zu schmuggeln, was die Interoperabilität bricht. Was auch immer Sie von dieser Entscheidung halten, Sie können eine reine JSON-Konfiguration nicht annotieren, was für alles schmerzhaft ist, was Menschen pflegen. Die praktische Lösung ist eine Obermenge. JSON5 fügt Kommentare, nachgestellte Kommas, Schlüssel ohne Anführungszeichen und einfache Anführungszeichen hinzu; JSONC (JSON with Comments) ist die leichtere Variante, die VS Code für seine Einstellungen verwendet. Beide behalten JSONs Form bei und machen es zugleich bearbeitbar. Wenn Sie Kommentare brauchen, aber in der JSON-Familie bleiben möchten, lesen Sie unseren JSON5- und JSONC-Formatierungsleitfaden, der zeigt, wann Sie welches verwenden und wie Sie das Tooling zufriedenstellen.

YAML – Der menschenfreundliche DevOps-Standard

YAML optimiert für den Menschen an der Tastatur. Es unterstützt Kommentare, sein einrückungsbasiertes Layout hält tief verschachtelte Strukturen sauber, und Anker lassen Sie einen Block einmal definieren und per Alias wiederverwenden, statt ihn per Copy-and-paste zu duplizieren:

defaults: &defaults
  timeout: 30
  retries: 3

staging:
  <<: *defaults
  host: staging.internal

production:
  <<: *defaults
  host: prod.internal

Der Anker &defaults benennt einen Block, und <<: *defaults merged ihn in beide Umgebungen, sodass eine Änderung am gemeinsamen Timeout an einer einzigen Stelle geschieht. Weder JSON noch TOML hat etwas Vergleichbares. Diese Lesbarkeit ist der Grund, warum YAML zur Lingua franca des Betriebs wurde: Kubernetes-Manifeste, GitHub-Actions-Workflows, Docker-Compose-Dateien und Ansible-Playbooks sind alle YAML. Wenn Ihre Konfiguration fünf Ebenen tief ist und ein Mensch sie täglich anpasst, ist YAMLs geringe Interpunktion eine echte Erleichterung.

Der Preis ist Komplexität und Überraschung. Die YAML-1.2-Spezifikation ist umfangreich, und vollständige Konformität ist selten, sodass verschiedene Parser sich an den Rändern uneinig sind. Einrückung ist bedeutungstragend, Tabs sind rundheraus verboten, und ein fehlausgerichtetes Leerzeichen kann die Bedeutung ändern oder das Parsen scheitern lassen. Die schärfste Kante ist die implizite Typisierung: YAML errät den Typ eines Skalars ohne Anführungszeichen aus seiner Form, und es rät oft genug falsch, um einen Spitznamen zu haben.

Das Norwegen-Problem in einem Absatz

Schreiben Sie country: NO in YAML, und viele Parser geben Ihnen den Boolean false zurück, nicht die Zeichenkette "NO", weil YAML 1.1 – dem die meisten Kubernetes-Tools noch folgen – NO, YES, ON, OFF, Y und N als Booleans behandelt. Norwegens Ländercode wird still zu false, ohne Fehler. Dieselbe implizite Typisierung macht aus 0755 eine Oktalzahl und aus 1.20 1.2. Die Lösung ist langweilig, aber zuverlässig: Setzen Sie Zeichenketten in Anführungszeichen, die mit etwas anderem verwechselt werden könnten. Dieser Fallstrick ist berühmt genug, um einen eigenen Tiefgang zu verdienen, samt echter Ausfälle und der Geschichte von YAML 1.1 versus 1.2, in unserem Leitfaden zum YAML-Norwegen-Problem. Für diesen Artikel ist die Erkenntnis einfach: YAMLs Bequemlichkeit und seine Gefahr kommen aus demselben Feature.

YAML gewinnt, wenn Menschen tief verschachtelte Konfiguration jeden Tag bearbeiten und das umgebende Ökosystem es bereits verlangt. Wenn Sie ein Helm-Chart schreiben, schreiben Sie YAML, und das ist in Ordnung.

TOML – Explizite Konfiguration, gebaut fürs Tooling

TOML (Tom’s Obvious, Minimal Language, erschaffen von Tom Preston-Werner) wurde als das Konfigurationsformat entworfen, das YAML-Nutzer sich gewünscht hätten: lesbar, aber ohne das Raten. Sein bestimmender Zug ist Explizitheit. Typen sind eindeutig, sodass port = 5432 immer eine Ganzzahl und name = "acme" immer eine Zeichenkette ist, ohne formbasierte Inferenz, über die man stolpern könnte. TOML-Syntax übernimmt den [section]-Header aus INI-Dateien, was die oberste Ebene einer Konfiguration scanbar macht, und es ist nicht einrückungssensitiv, sodass Whitespace nie die Bedeutung ändert. Die TOML-1.0.0-Spezifikation ist klein und stabil, was ein Vorteil ist: Es gibt weniger, das man falsch erinnern kann.

TOMLs herausragende Fähigkeit sind native Datums- und Zeittypen, die weder JSON noch reines YAML sauber handhaben. Es hat vier davon: Offset-Datum-Zeit mit Zeitzone (1979-05-27T07:32:00Z), lokale Datum-Zeit ohne eine, lokales Datum (1979-05-27, nur ein Kalendertag) und lokale Uhrzeit (07:32:00). Das bedeutet, ein Deployment-Datum bleibt ein echtes Datum, statt eine Zeichenkette zu sein, die Sie neu parsen müssen.

Drei Teile der TOML-Syntax erledigen den Großteil der Arbeit. Ein [section]-Header öffnet eine Tabelle; ein punktierter Header wie [tool.ruff] verschachtelt eine Tabelle in einer anderen ohne zusätzliche Einrückung; und eine Inline-Tabelle { version = "1.0", features = ["derive"] } packt ein kleines Objekt in eine Zeile. Wiederholte Abschnitte verwenden einen verdoppelten Header, das Array von Tabellen:

[[servers]]
name = "alpha"
ip = "10.0.0.1"

[[servers]]
name = "beta"
ip = "10.0.0.2"

Dieser Block wird zu einem JSON-Array aus zwei Objekten unter dem Schlüssel servers. Er liest sich gut für eine flache Liste, was genau das ist, was die meiste Tool-Konfiguration braucht.

Die Schwächen sind real, aber eng begrenzt. TOML hat keinen Null-Typ, sodass ein fehlender Wert einfach ein weggelassener Schlüssel ist. Tiefe Verschachtelung wird ausschweifend, weil jede Ebene einer wiederholten verschachtelten Struktur den vollen [[path]]-Header wiederholt, was lärmiger wächst als das YAML-Äquivalent. Und TOML ist jünger und weniger universell als JSON oder YAML, sodass nicht jedes Tool es spricht. TOML passt am besten zu Konfiguration, die überwiegend flach ist mit einer Handvoll benannter Abschnitte, also der großen Mehrheit der Tool-Konfiguration.

Warum TOML für Rust und Python?

TOMLs Aufstieg folgt zwei Ökosystemen, die es als Standard übernommen haben. Rusts Paketmanager Cargo verwendet Cargo.toml für jede Crate, sodass jeder Rust-Entwickler von Tag eins an TOML liest und schreibt. Python folgte: PEP 518 führte pyproject.toml ein, um Build-Anforderungen zu deklarieren, und PEP 621 standardisierte Projektmetadaten (Name, Version, Abhängigkeiten und [tool.*]-Abschnitte) in derselben Datei und ersetzte damit ein Sammelsurium aus setup.py, setup.cfg und werkzeugspezifischen Konfigurationen. Über diese beiden hinaus verwenden Hugo, Netlify, Poetry und Foundry standardmäßig TOML. Der gemeinsame Nenner ist Tooling-Konfiguration, die Beitragende von Hand bearbeiten und die davon profitiert, offensichtlich statt clever zu sein.

Direktvergleich – Die Unterschiede, die wirklich beißen

Feature-Tabellen sind ordentlich. Bugs sind es nicht. Dies sind die konkreten Unterschiede, die echte Probleme verursachen, jeder mit einem kleinen Beispiel, das Sie durch jeden beliebigen Parser schicken können.

Kommentare

JSON hat überhaupt keine Kommentarsyntax. TOML und YAML verwenden beide # bis zum Zeilenende.

# TOML: ein vorangestellter Kommentar
port = 5432  # und ein nachgestellter

# YAML: identischer Kommentarstil
port: 5432   # nachgestellter Kommentar

Sobald Sie ein // oder # in striktes JSON einfügen, scheitert das Parsen. Das ist nicht kosmetisch. Eine Konfiguration, die ein Mensch ohne Kommentare pflegt, sammelt Stammeswissen an, das nur in jemandes Kopf lebt.

Datentypen und Datumswerte

JSONs Typen sind explizit, aber spärlich, ohne Datumstyp. TOMLs Typen sind explizit und reichhaltig. YAMLs sind implizit und, wie oben behandelt, gelegentlich falsch. Datumswerte sind die klarste Trennlinie. TOML drückt alle vier Arten nativ aus:

odt = 1979-05-27T07:32:00Z   # Offset-Datum-Zeit (mit Zeitzone)
ldt = 1979-05-27T07:32:00    # lokale Datum-Zeit (ohne Zeitzone)
ld  = 1979-05-27             # lokales Datum (ein Kalendertag)
lt  = 07:32:00               # lokale Uhrzeit

Konvertieren Sie dieses TOML nach JSON, und jeder Wert wird zu einer Zeichenkette, die ihre Bedeutung behält: Ein lokales Datum bleibt "1979-05-27", statt zu einem falschen Mitternachts-Zeitstempel aufgebläht zu werden. Unser TOML-zu-JSON-Konverter bewahrt diese Datumsart exakt, was viele naive Konverter falsch machen. YAML wiederum behandelt 1979-05-27 möglicherweise als Datum oder auch nicht, je nach Parser und Schema-Version, was genau die Mehrdeutigkeit ist, die Sie in Produktionskonfiguration nicht wollen.

Verschachtelungstiefe

Je tiefer Ihre Konfiguration verschachtelt, desto stärker gehen die Formate auseinander. Nehmen Sie einen kleinen Baum im Docker-Compose-Stil:

services:
  web:
    build:
      context: .
      args:
        NODE_ENV: production
    ports:
      - "8080:8080"

YAML drückt Tiefe mit reiner Einrückung aus und bleibt kompakt. Dieselbe Struktur in TOML zwingt Sie, in jedem Header den vollen Pfad auszuschreiben und skalare Werte vor die Kindtabellen zu setzen:

[services.web]
ports = ["8080:8080"]

[services.web.build]
context = "."

[services.web.build.args]
NODE_ENV = "production"

JSON trägt den Baum in verschachtelten Klammern, was eindeutig, aber interpunktionslastig ist. Bei flacher Konfiguration fühlen sich die drei ähnlich an; jenseits von drei oder vier Ebenen ist YAML sichtbar schlanker und TOML sichtbar repetitiver. Dieser eine Unterschied erklärt, warum Kubernetes YAML und Cargo TOML gewählt hat.

Einrückungssensitivität

Nur YAML kümmert sich um Whitespace. In JSON und TOML können Sie einrücken, wie Sie möchten, oder gar nicht, und die Bedeutung ist identisch. In YAML ist die Einrückung die Struktur, und Tabs sind illegal, sodass ein Editor, der einen Tab einfügt, oder ein in falscher Tiefe eingefügter Block das Dokument still verändert oder das Laden verweigert. Ein Listenelement, das um ein Leerzeichen zu weit eingerückt ist, kann sich ohne jeden Fehler an den falschen übergeordneten Schlüssel hängen, was ein wahnsinnig schwer mit bloßem Auge zu findender Bug ist, weil die Datei immer noch vernünftig aussieht. Wenn Ihre Beitragenden gemischte Editoren und Einstellungen verwenden, ist das eine stehende Steuer, die YAML erhebt und die anderen beiden nicht, und es ist ein starker Grund, bei jeder großen YAML-Konfiguration einen Linter in der CI laufen zu lassen.

Mehrzeilige Zeichenketten

JSON kann keinen wörtlichen Zeilenumbruch in einer Zeichenkette halten; Sie escapen ihn als \n. YAML und TOML haben beide echte mehrzeilige Zeichenketten.

{ "note": "line one\nline two" }

note: |
  line one
  line two

note = """
line one
line two
"""

YAMLs | behält Zeilenumbrüche (ein >-Block faltet sie stattdessen zu Leerzeichen), und TOMLs """ verhält sich ähnlich und schneidet den Zeilenumbruch ab, der unmittelbar auf die öffnenden Anführungszeichen folgt. Für eingebettete Skripte, SQL oder Hilfetexte kann allein das über das Format entscheiden.

Nachgestellte Kommas und Striktheit

JSON ist das strikteste der drei. Ein nachgestelltes Komma nach dem letzten Array-Element ist ein Syntaxfehler:

# gültiges TOML – das nachgestellte Komma ist in Ordnung
ports = [
  8001,
  8002,
]

Dasselbe nachgestellte Komma nach 8002 scheitert in JSON beim Parsen, weshalb das Hinzufügen einer Zeile zu einem JSON-Array so oft auch bedeutet, das Komma in der Zeile darüber zu korrigieren. TOML erlaubt das nachgestellte Komma, und YAMLs Listensyntax mit einem Bindestrich pro Zeile umgeht die Frage ganz. Striktheit ist eine Tugend für den Maschinenaustausch und ein Ärgernis beim Bearbeiten von Hand, was derselbe Kompromiss ist, nur von der anderen Seite gesehen. Das ist auch die Reibung, die JSON5 und JSONC speziell für JSON beseitigen wollten.

Große Ganzzahlen und die 2^53-Grenze

Alle drei Formate können eine 64-Bit-Ganzzahl als Text schreiben. Der Ärger beginnt, wenn dieser Wert durch JavaScript läuft, denn JSON-Zahlen im Browser sind IEEE-754-Doubles und können Ganzzahlen nur exakt bis 2^53 − 1 (9007199254740991) darstellen. Eine Snowflake-ID oder ein Nanosekunden-Zeitstempel ist größer als das, sodass ein Roundtrip durch ein JS-basiertes Tool sie rundet und den Wert beschädigt:

snowflake = 1420070400000000000   # exakt im TOML-Text

{ "snowflake": "1420070400000000000" }

Die zuverlässige Lösung in jedem Format ist, solche Werte als Zeichenketten in Anführungszeichen zu speichern, sodass kein numerischer Parser sie je berührt. Das ist kein Mangel eines einzelnen Formats; es ist eine Beschränkung der Laufzeitumgebung, die die Konvertierung vornimmt. Unsere Konverter warnen Sie, wenn eine Ganzzahl diese Grenze überschreitet, statt sie still zu beschädigen.

Wie wählen – Entscheidungsmatrix und Flussdiagramm

Wenn Sie tatsächlich entscheiden, welches Config-Format Sie verwenden, gehen Sie die Fragen der Reihe nach durch und halten Sie beim ersten klaren Ja an.

1. Wird die Datei hauptsächlich von Programmen geschrieben und gelesen, oder schreibt das Ökosystem bereits ein Format vor? Wenn ja, verwenden Sie JSON. Ein API-Payload ist JSON. Eine Datei neben package.json ist JSON. Kämpfen Sie nicht gegen das Tooling.
2. Bearbeiten Menschen täglich tiefe, verschachtelte Konfiguration von Hand, innerhalb eines Stacks, der es erwartet (Kubernetes, CI, Ansible)? Wenn ja, verwenden Sie YAML und führen Sie eine Anführungszeichen-Konvention ein, um dem Norwegen-Problem auszuweichen.
3. Ist es Tool- oder Anwendungskonfiguration, überwiegend flach mit ein paar Abschnitten, bearbeitet von Beitragenden mit unterschiedlichem Können, wo typisiert und offensichtlich knapp schlägt? Wenn ja, verwenden Sie TOML.

Wenn zwei Antworten gleichstehen, entscheiden Sie anhand dieser Achsenkarte:

Anforderung	Beste Wahl	Warum
Kommentare in der Datei	TOML oder YAML	JSON hat keine
Native Datums-/Zeitwerte	TOML	Vier explizite Datumstypen
Sehr tiefe Verschachtelung	YAML	Einrückung bleibt kompakt
Null Whitespace-Überraschungen	JSON oder TOML	Nicht einrückungssensitiv
An eine Ökosystem-Datei gebunden	JSON	package.json, tsconfig.json
Menschliche Bearbeitung, wenige Abschnitte	TOML	Explizite Typen, INI-artige Header
Maschine-zu-Maschine-Austausch	JSON	Universell, strikt, schnell
Typinferenz darf nie raten	JSON oder TOML	YAML leitet implizit ab

Die meisten Projekte verwenden am Ende mehr als eines. Ein Repository könnte eine JSON-package.json haben, die es nie von Hand anfasst, eine TOML-pyproject.toml für sein Python-Tooling, YAML-Workflows in .github und eine .env-Datei für lokale Secrets, die keiner dieser Grammatiken folgt. Diese Mischung ist normal und sogar erwünscht: Jede Datei lebt in dem Format, das zu ihrem Bearbeiter passt. Wenn die .env-Schicht Teil Ihres Setups ist, behandelt unser Leitfaden zum .env-Dateiformat, wo es neben JSON-Konfiguration passt und wie man zwischen beiden konvertiert.

Konvertieren zwischen TOML, JSON und YAML

Sie konvertieren am Ende öfter zwischen diesen Formaten, als Sie erwarten würden. Ein CI-Job liest eine von Hand geschriebene pyproject.toml und braucht sie als JSON, um ein Abhängigkeits-Dashboard zu füttern. Eine Migration überführt eine App von einer YAML-Konfiguration zu TOML für strengere Typisierung. Ein Code-Review ist einfacher, wenn Sie die JSON-Form zweier Dateien vergleichen statt ihrer whitespace-empfindlichen Originale. Jede Richtung hat einen Fallstrick, den zu kennen sich lohnt, bevor Sie einfügen.

TOML zu JSON. Das Hauptrisiko sind Datumswerte. Ein lokales Datum wie 1979-05-27 sollte ein Kalenderdatum bleiben, nicht zu einem Mitternachts-UTC-Zeitstempel werden, der eine Uhrzeit und Zeitzone erfindet. Kommentare gehen ebenfalls verloren, da JSON sie nicht halten kann. Der TOML-zu-JSON-Konverter bewahrt jede Datumsart getreu, sodass Roundtrips verlustfrei bleiben.

JSON zu TOML. TOML ist strenger bei der Struktur, sodass zwei Dinge eine Konvertierung blockieren können. Die oberste Ebene muss ein Objekt sein, weil ein TOML-Dokument an seiner Wurzel immer eine Tabelle ist; ein bloßes Array oder ein Skalar hat keinen Platz. Und TOML hat kein Null, sodass ein Null-Objektwert weggelassen wird (mit einer Warnung, die auflistet, welche Schlüssel betroffen sind), während ein Null innerhalb eines Arrays überhaupt keine gültige TOML-Darstellung hat. Der JSON-zu-TOML-Konverter macht beide Fälle explizit sichtbar, statt fehlerhafte Ausgabe zu erzeugen.

JSON und YAML, beide Richtungen. Hier ist das Norwegen-Problem das, worauf zu achten ist: Ein NO oder 0755 ohne Anführungszeichen kann beim Überschreiten der Grenze den Typ wechseln. Der JSON-zu-YAML-Konverter und der YAML-zu-JSON-Konverter übernehmen das Setzen der Anführungszeichen, sodass eine Zeichenkette eine Zeichenkette bleibt.

Nach jeder Konvertierung lohnt es sich, das Ergebnis zu validieren. Die Ausgabe durch den JSON-Formatierer laufen zu lassen, bestätigt, dass das JSON wohlgeformt und konsistent eingerückt ist, bevor Sie es committen oder weiterreichen. Und weil Konfigurationsdateien Secrets tragen (Registry-Tokens, Datenbank-Zugangsdaten, Deploy-Schlüssel), laufen all diese vollständig in Ihrem Browser: Nichts wird hochgeladen, sodass eine Cargo.toml mit einem privaten Registry-Token oder eine Values-Datei mit Zugangsdaten Ihren Rechner nie verlässt.

FAQ

Ist TOML besser als YAML?

Keines ist universell besser; die Wahl zwischen TOML und YAML hängt von der Form ab. TOML ist dank expliziter Typen und ohne Einrückungsfallen schwerer falsch zu machen, sodass es bei überwiegend flacher Tooling-Konfiguration gewinnt. YAML drückt tiefe Verschachtelung kompakter aus, sodass es bei großer, geschichteter Infrastruktur wie Kubernetes gewinnt.

Sollte ich JSON oder YAML für Konfigurationsdateien verwenden?

Für Konfiguration, die ein Mensch bearbeitet, bevorzugen Sie YAML: Es erlaubt Kommentare und liest sich sauber, was JSON nicht tut. Für Konfiguration, die Programme erzeugen und konsumieren, bevorzugen Sie JSON: Es ist strikt, schnell und universell. Die Trennlinie ist, wer die Bearbeitung vornimmt, Mensch oder Maschine.

Warum erlaubt JSON keine Kommentare?

JSONs Erschaffer, Douglas Crockford, entfernte Kommentare absichtlich. Er befürchtete, dass Leute Parsing-Direktiven in ihnen einbetten und die Interoperabilität zwischen Parsern brechen würden. Wenn Sie Kommentare in einer JSON-förmigen Datei brauchen, verwenden Sie JSON5 oder JSONC, die sie wieder hinzufügen, ohne die Kernstruktur zu ändern.

Was ist das Norwegen-Problem in YAML?

Es ist YAML 1.1, das bestimmte Wörter ohne Anführungszeichen als Booleans behandelt, sodass country: NO zu false statt zur Zeichenkette "NO" wird. YES, ON und OFF verhalten sich genauso. Das Setzen von Anführungszeichen um den Wert verhindert es; die volle Geschichte finden Sie im oben verlinkten eigenen Leitfaden.

Unterstützt TOML Kommentare?

Ja. TOML verwendet # für Kommentare, sowohl in einer eigenen Zeile als auch nachgestellt hinter einem Wert, genau wie YAML. Beachten Sie, dass Kommentare verloren gehen, wenn Sie TOML nach JSON konvertieren, da JSON keine Kommentarsyntax hat, um sie zu halten.

Kann TOML alles darstellen, was JSON kann?

Fast. Die Lücke zwischen JSON und TOML ist klein, aber real: TOML hat keinen Null-Typ, sodass JSON-Nulls bei der Konvertierung weggelassen oder abgelehnt werden, und ein TOML-Dokument muss auf oberster Ebene eine Tabelle sein, sodass ein bloßes JSON-Array oder ein Skalar sich nicht konvertieren lässt, ohne zuerst unter einem Schlüssel eingepackt zu werden.

Ist YAML eine Obermenge von JSON?

Seit YAML 1.2 ja: Jedes gültige JSON-Dokument ist auch gültiges YAML, sodass ein YAML-Parser JSON direkt lesen kann. Das ist eine nützliche Tatsache, aber verlassen Sie sich nicht als Sicherheitsgrenze darauf, denn YAML-Parser fügen Features hinzu (wie Anker), die JSON nicht hat.

Welches Config-Format ist am schnellsten zu parsen?

JSON ist im Allgemeinen am schnellsten, mit den ausgereiftesten und optimiertesten Parsern in jeder Sprache. YAML ist wegen seiner umfangreichen Spezifikation und impliziten Typisierung das langsamste und komplexeste zu parsen. TOML liegt in der Mitte, in der Geschwindigkeit näher an JSON als an YAML.