Das YAML-Norway-Problem und JSON ↔ YAML-Unterschiede, die Entwickler kennen sollten

Es war ein routinemäßiges Helm-Deployment. Das Team hatte zwei Tage damit verbracht, eine values.yaml-Datei für einen Multi-Region-Rollout zu optimieren. Das Chart erstellte eine Kubernetes-ConfigMap mit Metadaten zu Lokalen — einschließlich des Ländercodes für ihr norwegisches Rechenzentrum. Jemand tippte country: NO und commitete es. Die CI-Pipeline wurde grün. Das Deployment ging raus.

Dann kamen die Alarme.

Die ConfigMap enthielt country: false statt country: "NO". Jeder nachgelagerte Dienst, der das Country-Feld las, erhielt einen booleschen Wert statt einer Zeichenkette. Der Zeichenkettenvergleich schlug fehl. Die Routing-Logik fiel auf einen Standardwert zurück. Traffic, der in Norwegen hätte bleiben sollen, wurde vom falschen regionalen Endpunkt verarbeitet.

Die Ursache war eine einzige Zeichenkette ohne Anführungszeichen in einer YAML-Datei. YAML 1.1 — die Version, die praktisch alle Kubernetes-Werkzeuge verwenden — behandelt NO als boolesches false. Es behandelt YES, ON, OFF, Y, N, no, yes, on, off, y, n und ein Dutzend weitere Varianten genauso. Keine Warnung. Kein Fehler. Stillschweigend falsch.

JSON hat dieses Problem nicht. {"country": "NO"} ist immer eine Zeichenkette. YAMLs implizite Typkonvertierung ist sowohl seine größte Bequemlichkeit als auch seine gefährlichste Falle.

Dieser Leitfaden deckt das gesamte Bild ab: Warum das Norway-Problem existiert, was sich in YAML 1.2 geändert hat (und warum die meisten Werkzeuge es ignorieren), wie man korrekte Anführungsstrategien schreibt, die Einrückungsregeln, die Neulinge stolpern lassen, Präzisionsfallen bei Zahlen und vier reale Konvertierungsszenarien von Kubernetes-Manifesten bis zu Terraform-Plänen. Wenn Sie einen JSON-Wert sicher ohne diese Falle nach YAML konvertieren müssen, bietet unser JSON-zu-YAML-Konverter automatisches Anführungszeichen für Norway-gefährdete Zeichenketten.

JSON vs. YAML — Wann welches verwenden?

Bevor wir uns in das Norway-Problem vertiefen, ist es hilfreich zu verstehen, für was jedes Format tatsächlich optimiert ist. Sie sind nicht austauschbar — jedes hat einen Designkern, der es in bestimmten Kontexten zur besseren Wahl macht.

Dimension	JSON	YAML
Syntax	Strikt — geschweifte Klammern, Anführungszeichen, Kommas erforderlich	Flexibel — einrückungsgesteuert, minimale Interpunktion
Typsystem	Explizit: Zeichenkette, Zahl, Boolean, null, Array, Objekt	Implizit — YAML 1.1 leitet Typen aus der Wertform ab
Menschliche Lesbarkeit	Entwicklerfreundlich, maschinell überprüfbar	Menschenfreundlich, leicht von Hand zu bearbeiten
Anführungsanforderung	Zeichenketten immer in Anführungszeichen	Die meisten Skalare können ohne Anführungszeichen sein (Quelle des Norway-Problems)
Kommentare	Nicht unterstützt	Mit `#` unterstützt
Primärer Einsatz	APIs, Datenaustausch, moderne Konfigurationssysteme	Kubernetes, Docker Compose, Ansible, CI-Pipelines
Überraschende Parses	Keine — striktes Parsen	Ja — Norway, Oktal, Timestamps
Schema-Durchsetzung	JSON-Schema-Ökosystem	YAML-Schema (weniger Werkzeuge)

JSON gewinnt, wenn Ihre Daten Systemgrenzen überqueren — REST-APIs, Message Queues, Datenbank-Serialisierung. Maschinen parsen es, Maschinen erzeugen es, und die strikte Syntax macht die Validierung unkompliziert. Verwenden Sie einen JSON-Formatierer, um die Struktur vor dem Senden zu validieren.

YAML gewinnt, wenn Menschen die Hauptautoren sind. Kubernetes-Manifeste, GitHub-Actions-Workflows, Helm-Charts, Ansible-Playbooks — das sind Dateien, die Entwickler dutzende Male lesen und bearbeiten. Die reduzierte Interpunktion und die Unterstützung für Kommentare machen sie wirklich wartungsfreundlicher als ihre JSON-Äquivalente.

Das Problem entsteht an der Grenze: wenn ein Werkzeug JSON erzeugt (wie kubectl get deploy -o json oder terraform show -json) und ein Mensch das Ergebnis als YAML in der Versionskontrolle speichern oder bearbeiten muss. Diese Konvertierung ist der Ort, an dem das Norway-Problem lebt. Unser YAML-zu-JSON-Konverter behandelt die umgekehrte Richtung, wenn Sie zurück müssen.

Das Norway-Problem — Tiefer Einblick

Das Norway-Problem ist kein Bug. Es ist eine Funktion der YAML-1.1-Spezifikation, die genau wie geplant funktioniert. Zu verstehen, warum es so konzipiert wurde — und warum so viele Systeme noch immer 1.1 implementieren — ist der Schlüssel zur Vermeidung.

Warum “no”, “yes”, “on”, “off”, “y”, “n” falsch geparst werden

Die YAML-1.1-Spezifikation definierte einen breiten booleschen Typ, der menschenfreundlich sein sollte. Sie erkannte alle der folgenden als true oder false:

True: y, Y, yes, Yes, YES, true, True, TRUE, on, On, ON

False: n, N, no, No, NO, false, False, FALSE, off, Off, OFF

Die Absicht war gut: Konfigurationsdateien verwenden oft yes/no statt true/false auf Englisch, und YAML wollte die natürliche Art und Weise unterstützen, wie Menschen Konfigurationen schreiben. Das Problem ist, dass yes, no, on, off, y und n auch völlig legitime Zeichenkettenwerte sind, die in den meisten Anwendungen etwas ganz anderes bedeuten.

Hier ist der Konflikt in konkretem YAML:

# YAML 1.1 (was die meisten Parser implementieren)
country: NO        # parst als: country: false   ← GEFAHR
enabled: yes       # parst als: enabled: true
restart: off       # parst als: restart: false
language: y        # parst als: language: true
shell: n           # parst als: shell: false

# Korrekt — explizite Zeichenketten-Anführungszeichen überschreiben die Typableitung
country: "NO"      # parst als: country: "NO"    ← sicher
enabled: "yes"     # parst als: enabled: "yes"
restart: "off"     # parst als: restart: "off"
language: "y"      # parst als: language: "y"
shell: "n"         # parst als: shell: "n"

Und der JSON-Vergleich:

{"country": "NO"}

In JSON ist NO innerhalb von Anführungszeichen immer und bedingungslos eine Zeichenkette. Es gibt keine implizite Typableitung. Die Striktheit, die JSON geschwätzig wirken lässt, ist auch das, was es sicher macht.

Neben der booleschen Konvertierung konvertiert YAML 1.1 auch implizit:

123e4 → die Zahl 1230000 (wissenschaftliche Notation)
0x1A → die Zahl 26 (hexadezimal)
0755 → die Zahl 493 (oktal — dies bricht Unix-Dateiberechtigungszeichenketten)
2024-05-04 → ein Datumsobjekt in vielen Parsern (nicht nur eine Zeichenkette)
1_000_000 → die Zahl 1000000 (Unterstrich-Trennzeichen)

Das Norway-Problem ist wirklich nur das bekannteste Mitglied einer ganzen Familie von impliziten YAML-Typkonvertierungen.

YAML 1.1 vs. 1.2 — Was sich geändert hat

YAML 1.2 wurde 2009 veröffentlicht — vier Jahre nach YAML 1.1. Ihr Hauptziel war es, YAML in strikte Übereinstimmung mit JSON zu bringen (da JSON eigentlich eine gültige YAML-1.2-Teilmenge ist) und die überraschenden impliziten Typkonvertierungen zu reduzieren.

In YAML 1.2:

Boolean ist auf genau true und false (Groß-/Kleinschreibung beachten) eingeschränkt. Das war’s. yes, no, on, off sind einfache Zeichenketten.
Oktal-Literale erfordern das 0o-Präfix (0o755) — die alte Form 0755 ist eine Zeichenkette.
Timestamps werden nicht implizit geparst — 2024-05-04 bleibt eine Zeichenkette, es sei denn, Sie taggen es explizit.
Die Spezifikation selbst ist eine JSON-Obermenge, was bedeutet, dass jedes gültige JSON-Dokument gültiges YAML 1.2 ist.

Auf dem Papier löst YAML 1.2 das Norway-Problem vollständig. In der Praxis hat sich das Ökosystem kaum bewegt.

Bibliothek	Standard-Spezifikation	Norway-Risiko
PyYAML (Python)	YAML 1.1	Ja — `yaml.safe_load` parst `NO` noch als `False`
ruamel.yaml (Python)	YAML 1.2 (optional)	Konfigurierbar — standardmäßig sicherer
js-yaml (Node.js)	YAML 1.1	Ja in älteren Versionen; neuere Versionen haben `FAILSAFE_SCHEMA`-Option
eemeli/yaml (Node.js)	YAML 1.2	Nein — 1.2 standardmäßig oder explizit wählbar
gopkg.in/yaml.v2 (Go)	YAML 1.1	Ja
gopkg.in/yaml.v3 (Go)	YAML 1.2	Deutlich sicherer
Kubernetes / Helm	YAML 1.1 (über Go yaml.v2)	Ja — historisch, sehr schwer zu migrieren
Ansible	YAML 1.1 (über PyYAML)	Ja

Der Grund, warum die Migration langsam ist, ist Rückwärtskompatibilität. Systeme, die sich ein Jahrzehnt lang auf yes/no als boolesche Werte verlassen haben, können dieses Verhalten nicht stillschweigend ändern, ohne bestehende Konfigurationen zu beschädigen. Kubernetes insbesondere ist eine massive installierte Basis, bei der die Änderung der YAML-Parsing-Semantik eine cluster-weite Breaking Change wäre.

Die praktische Schlussfolgerung: Gehen Sie in jedem Werkzeug, das Sie nicht explizit konfiguriert haben, von YAML-1.1-Semantik aus. Setzen Sie Zeichenketten, die als boolesche Werte, Timestamps oder Zahlen missverstanden werden könnten, immer in Anführungszeichen.

Wie Produktionssysteme betroffen werden

Der norwegische Ländercode ist das am häufigsten zitierte Beispiel, weil er kontraintuitiv ist — NO sieht wie eine offensichtliche Abkürzung aus, kein boolescher Wert. Aber das Muster wiederholt sich in vielen realen Szenarien:

IATA-Flughafencodes. Der norwegische Flughafen Harstad/Narvik hat den Code EVE. Sicher. Oslo Gardermoen ist OSL. Auch sicher. Aber jede Anwendung, die YAML verwendet, um regionale Flughafencodes zu speichern, ist einen no-Routencode von einem booleschen false in der Produktion entfernt.

Umgebungsvariablennamen. ON ist in einigen Legacy-Systemen ein völlig gültiger Umgebungsvariablenwert, der “aktiviert” bedeutet. OFF ist sein Gegenstück. Das Migrieren von Konfigurationen aus Shell-Skripten nach YAML ohne Anführungszeichen dieser Werte führt zu stiller Typkonvertierung.

E-Mail-Benutzerfelder. Ein Benutzer, dessen Vorname oder Benutzername buchstäblich n, y oder eines der auslösenden Wörter ist, wird falsch serialisiert, wenn die Anwendung YAML ohne ordentliche Anführungszeichen ausgibt. Dies ist besonders heimtückisch, weil es nur für eine Teilmenge der Benutzer fehlschlägt.

Docker-Compose-Neustart-Richtlinien. Der restart_policy-Feldwert "no" bedeutet “nicht neustarten.” Wenn er seine Anführungszeichen in einem YAML-Round-Trip verliert, wird der Wert zu false, und Docker Compose interpretiert es möglicherweise als “keine Neustart-Richtlinie angegeben” oder wirft einen Validierungsfehler — in jedem Fall ist das Container-Neustartverhalten falsch.

GitHub-Actions-shell:-Feld. Die gültigen Shell-Werte sind bash, pwsh, python, sh, cmd, powershell. Keiner davon ist ein Norway-Wort. Aber jemand, der shell: yes oder shell: on als Platzhalter beim Entwurf eintippt, könnte überrascht sein, wenn YAML es in einen booleschen Wert umwandelt, bevor der Validator es überhaupt sieht.

Die Lösung ist in allen Fällen dieselbe: Setzen Sie Zeichenketten, die semantisch Zeichenketten sind, in Anführungszeichen, unabhängig davon, ob ein Mensch sie als Schlüsselwörter erkennen würde. Unser JSON-zu-YAML-Konverter wendet dies automatisch an — jeder Wert in der Norway-Wortliste wird in der Ausgabe in Anführungszeichen gesetzt.

Zeichenketten-Anführungsstrategie

Sobald Sie verstehen, warum Norway-Wörter konfligieren, besteht die Lösung darin, die richtige Anführungsstrategie für Ihren Anwendungsfall zu wählen. YAML unterstützt drei Modi, jeder mit unterschiedlichen Abwägungen.

Auto vs. Doppelt vs. Einfach

Auto-Anführungszeichen (empfohlen für die meisten Konvertierungen) lassen die Bibliothek entscheiden, wann Anführungszeichen notwendig sind. Werte, die ohne Anführungszeichen falsch gelesen würden — Norway-Wörter, Zahlen, Timestamps, Zeichenketten, die wie YAML-Syntax aussehen — werden automatisch in Anführungszeichen gesetzt. Alles andere bleibt als einfaches Skalar. Dies erzeugt die lesbarste Ausgabe, während es sicher bleibt.

# Auto-Modus-Ausgabe
name: Alice          # einfach — keine Mehrdeutigkeit
country: "NO"        # in Anführungszeichen — Norway-Wort
age: 30              # einfach — eindeutige Zahl
created: "2024-05-04" # in Anführungszeichen — würde sonst als Datum geparst
port: "8080"         # abhängig von Bibliothek — einige setzen numerisch aussehende Zeichenketten in Anführungszeichen

Doppelt angeführte Zeichenketten umschließen alle Zeichenkettenwerte mit doppelten Anführungszeichen. Dies ist explizit und prüfbar — jeder Leser kann sehen, dass all diese Werte Zeichenketten sind, ohne über die Spezifikation nachzudenken. Der Kompromiss ist Ausführlichkeit und reduzierte menschliche Lesbarkeit, besonders für tief verschachtelte Konfigurationen.

# Doppelt-Anführungszeichen-Modus
name: "Alice"
country: "NO"
replicas: "3"         # sogar Zahlen werden Zeichenketten — kann Schema-Fehler verursachen

Vorsicht: Wenn Ihr Zielschema eine Zahl erwartet und Sie sie als angeführte Zeichenkette serialisieren, wird der YAML-Parser sie korrekt als Zeichenkette typisieren, aber Kubernetes oder ein anderer strikter Verbraucher könnte das Feld als falschen Typ ablehnen.

Einfach angeführte Zeichenketten sind eine reine YAML-Funktion — JSON hat keine Einfachanführungszeichensyntax. Einfache Anführungszeichen sind literal: keine Escape-Sequenzen darin. Der einzige Sonderfall ist, dass ein einfaches Anführungszeichen innerhalb einer einfach angeführten Zeichenkette verdoppelt werden muss (''). Einfache Anführungszeichen sind ideal für Zeichenketten, die Backslashes oder Sonderzeichen enthalten, die in doppelten Anführungszeichen escaped werden müssten.

# Einfach-Anführungszeichen-Modus
pattern: 'C:\Users\alice\Documents'  # kein Escaping nötig
regex: '\d+\.\d+'                    # Backslashes literal

Für JSON-zu-YAML-Konvertierungen, die zurück nach JSON gehen sollen, bevorzugen Sie Auto- oder Doppelt-Modus. Einfach angeführte Zeichenketten führen eine YAML-spezifische Syntax ein, die auf dem Rückweg einen YAML-fähigen Parser erfordert.

Block-Skalare (| und >)

YAMLs Block-Skalar-Syntax ist genuinen Nutzen für mehrzeilige Zeichenketten — etwas, das JSON mit \n-Escape-Sequenzen umständlich handhabt.

Literal Block-Skalar | behält Zeilenumbrüche genau bei:

# Literal Block — Zeilenumbrüche beibehalten
script: |
  #!/bin/bash
  set -euo pipefail
  echo "Starting deployment"
  kubectl apply -f manifest.yaml

# Äquivalente JSON-Darstellung (unleserlich)
# {"script": "#!/bin/bash\nset -euo pipefail\necho \"Starting deployment\"\nkubectl apply -f manifest.yaml\n"}

Gefalteter Block-Skalar > verbindet Zeilen mit Leerzeichen und wandelt jeden Zeilenumbruch in ein Leerzeichen um (außer Leerzeilen, die zu Zeilenumbrüchen werden):

# Gefalteter Block — Zeilenumbrüche werden Leerzeichen
description: >
  This service handles authentication
  for the entire platform. It supports
  OAuth2, SAML, and API key authentication.

# Ergebnis: "This service handles authentication for the entire platform. It supports OAuth2, SAML, and API key authentication.\n"

Block-Skalare eignen sich hervorragend zum Einbetten von TLS-Zertifikaten, mehrzeiligen Shell-Skripten oder SQL-Abfragen in YAML-Konfigurationen — Szenarien, bei denen das JSON-Äquivalent eine lange, escaped, einzeilige Zeichenkette wäre, die kein Mensch lesen kann.

Bei der Konvertierung von JSON nach YAML verwenden die meisten Konverter (einschließlich unseres) den Auto-Modus und stellen mehrzeilige Zeichenketten nur dann mit Block-Skalaren dar, wenn eingebettete Zeilenumbrüche erkannt werden. Einzeilige Zeichenketten erhalten Flow-Skalare (angeführt oder einfach). Verwenden Sie unseren JSON-zu-YAML-Konverter, um die Ausgabe zu sehen, bevor Sie sie in ein Manifest einchecken.

Einrückung — 2 vs. 4 Leerzeichen, Tabs verboten

YAMLs Einrückungsregeln sind strenger als sie aussehen. Die Spezifikation hat eine absolute Regel und eine Konvention, die je nach Ökosystem variiert.

Die absolute Regel: Tabs sind verboten. Jede Einrückungsebene muss Leerzeichen verwenden. Ein Tab-Zeichen in einer YAML-Datei ist in den meisten Parsern ein Parse-Fehler:

# FALSCH — Tabs verursachen Parse-Fehler
apiVersion: apps/v1
kind: Deployment
metadata:
	name: my-app     # ← Tab-Zeichen hier → ParseError

# KORREKT — nur Leerzeichen
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app      # ← zwei Leerzeichen

Die Fehlermeldung, die Sie sehen werden, variiert je nach Bibliothek. In Pythons PyYAML:

yaml.scanner.ScannerError: while scanning for the next token
found character '\t' that cannot start any token

In Gos yaml.v3:

yaml: line 4: found character that cannot start any token

Konfigurieren Sie Ihren Editor so, dass er Tabs für YAML-Dateien in Leerzeichen umwandelt. In VS Code fügen Sie Ihren Workspace-Einstellungen hinzu: "[yaml]": { "editor.insertSpaces": true, "editor.tabSize": 2 }.

Die Konvention: 2 vs. 4 Leerzeichen. Beide sind gültig. Ökosystem-Konventionen unterscheiden sich:

Ökosystem	Konvention	Grund
Kubernetes-Manifeste	2 Leerzeichen	Offizielle Docs und Beispiele verwenden 2
Helm-Charts	2 Leerzeichen	Folgt K8s-Konvention
Docker Compose	2 Leerzeichen	Offizielle Compose-Spec-Beispiele
GitHub Actions	2 Leerzeichen	Offizielle Workflow-Beispiele
Ansible-Playbooks	2 Leerzeichen	Offizielle Dokumentation
Traditionelle Konfigurationen	4 Leerzeichen	Entspricht JSON-Beautify-Standard

Für jede Datei, die von Kubernetes oder Docker Compose verwendet wird, verwenden Sie 2 Leerzeichen. Für eigenständige Konfigurationsdateien, die nur von Menschen und benutzerdefinierten Werkzeugen gelesen werden, funktioniert beides — seien Sie nur innerhalb einer Datei konsistent. Unser JSON-zu-YAML-Konverter verwendet standardmäßig 2-Leerzeichen-Einrückung und ermöglicht es Ihnen, für Projekte, die es bevorzugen, auf 4 zu wechseln.

Eine weitere Regel: Kindelemente müssen mehr als ihre übergeordneten Elemente eingerückt sein, aber die Anzahl der zusätzlichen Leerzeichen kann eine beliebige positive Ganzzahl sein (1, 2, 3, 4…) — solange sie innerhalb eines Blocks konsistent ist. In der Praxis verwenden Sie immer 2 oder 4 für die Lesbarkeit.

Zahlenbehandlung über JSON ↔ YAML

Beide Formate unterstützen Zahlen, aber die Grenzfälle unterscheiden sich genug, um Produktionsfehler zu verursachen.

Präzisionsverlust bei großen Zahlen

JavaScripts Number-Typ ist ein 64-Bit-IEEE-754-Float. Er kann Ganzzahlen exakt bis 2^53 − 1 = 9.007.199.254.740.991 darstellen. Darüber hinaus geht die Ganzzahlpräzision verloren:

// JavaScript-Präzisionsverlust — dies ist kein YAML-Problem, betrifft aber JSON-Parsing
JSON.parse('{"v": 9007199254740993}').v
// → 9007199254740992   (die 3 wurde 2 — ein Bit verloren)

// Sicher — innerhalb des 2^53-Bereichs
JSON.parse('{"v": 9007199254740991}').v
// → 9007199254740991   (exakt)

Dies ist wichtig für die JSON-zu-YAML-Konvertierung in JavaScript-Umgebungen, weil die Präzision bereits verloren ist, bevor die YAML-Serialisierung beginnt. Kubernetes metadata.resourceVersion ist ein Zeichenkettenfeld, speziell weil Ressourcenversionen den sicheren Ganzzahlbereich überschreiten können. Andere Felder, die wie kleine Zahlen aussehen — observedGeneration, uid-Komponenten — sind sicherer, aber jedes int64-Feld in einer K8s-Antwort ist potenziell betroffen.

Abhilfen:

Verwenden Sie Python oder Go für Konvertierungspipelines mit großen Zahlen — beide verarbeiten beliebige Ganzzahlen nativ.
In Node.js verwenden Sie einen JSON-Parser, der BigInt unterstützt: JSON.parse(text, (_, v) => typeof v === 'number' && !Number.isSafeInteger(v) ? BigInt(v) : v).
Für Felder, die ohne Verlust weiterverarbeitet werden müssen, serialisieren Sie sie als Zeichenketten an der Quelle.
Achten Sie bei der Überprüfung von konvertiertem YAML auf Felder wie resourceVersion, generation und timestamp-abgeleitete Werte.

Oktal- und Hex-Eigenheiten

YAML 1.1 behandelt bestimmte zahlenähnliche Zeichenketten als nicht-dezimale Ganzzahlen:

# YAML-1.1-Parsing-Überraschungen
permissions: 0755   # parst als oktal 493, nicht dezimal 755
value: 0x1A         # parst als hex 26, nicht Zeichenkette "0x1A"

# YAML-1.2-Verhalten
permissions: 0755   # bleibt als Ganzzahl 755 (dezimal) — oktal erfordert 0o-Präfix
permissions: 0o755  # parst als oktal 493 in 1.1 und 1.2

# Sicher für beide Spezifikationen — jeden führenden Nullwert in Anführungszeichen setzen
permissions: "0755"  # immer die Zeichenkette "0755"

Die Oktal-Falle ist besonders gefährlich für Unix-Dateiberechtigungen, IP-Adresskomponenten mit führenden Nullen (einige Netzwerkgeräte) und alle numerischen Codes, die führende Nullen für das Auffüllen verwenden (Postleitzahlen, Produktcodes). Setzen Sie diese Werte beim Schreiben von YAML von Hand immer in Anführungszeichen, oder stellen Sie sicher, dass Ihr Konverter sie in Anführungszeichen setzt — unser JSON-zu-YAML-Konverter erkennt numerische Zeichenketten aus JSON und bewahrt ihren Zeichenkettentyp.

Reale Konvertierungen

Das Norway-Problem und Anführungsstrategien werden konkret, wenn man sie auf reale Konvertierungsszenarien anwendet.

Kubernetes-Manifest aus JSON

Der kanonische Workflow: kubectl get deploy my-app -o json gibt Ihnen das Live-Objekt als JSON. Sie möchten es bereinigen (entfernen Sie status, creationTimestamp, verwaltete Felder) und es als YAML-Manifest in Git einchecken.

Quell-JSON (abgekürzt):

{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "name": "my-app",
    "namespace": "production",
    "labels": {
      "app": "my-app",
      "region": "NO"
    }
  },
  "spec": {
    "replicas": 3,
    "selector": {
      "matchLabels": { "app": "my-app" }
    },
    "template": {
      "spec": {
        "containers": [{
          "name": "app",
          "image": "registry.example.com/my-app:v1.2.3",
          "env": [
            { "name": "REGION", "value": "NO" },
            { "name": "ENABLE_FEATURE", "value": "yes" }
          ]
        }]
      }
    }
  }
}

Erwartete YAML-Ausgabe (mit Norway-Schutz):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
  labels:
    app: my-app
    region: "NO"          # in Anführungszeichen — Norway-Wort
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    spec:
      containers:
        - name: app
          image: registry.example.com/my-app:v1.2.3
          env:
            - name: REGION
              value: "NO"           # in Anführungszeichen — Norway-Wort
            - name: ENABLE_FEATURE
              value: "yes"          # in Anführungszeichen — Norway-Wort

Beachten Sie, dass replicas: 3 ohne Anführungszeichen belassen wird — es ist eine legitime Ganzzahl, die Kubernetes als Zahl erwartet. Die Norway-Wörter in labels und env-Werten sind in Anführungszeichen. Ein naiver Konverter, der YAML-1.1-Booleans nicht behandelt, würde stillschweigend region: false und value: false erzeugen.

Nach der Konvertierung validieren Sie mit: kubectl apply --dry-run=client -f manifest.yaml. Dies erkennt Schema-Fehler, ohne den Cluster zu berühren.

Probieren Sie die Konvertierung in unserem JSON-zu-YAML-Konverter — fügen Sie das JSON oben ein und sehen Sie Norway-sichere Ausgabe sofort. Verwenden Sie unseren YAML-zu-JSON-Konverter, um den Round-Trip zu überprüfen.

Docker Compose aus JSON

CI/CD-Pipelines generieren manchmal Docker-Compose-Konfigurationen programmatisch aus einem JSON-Konfigurationsspeicher und schreiben sie dann als YAML auf die Festplatte, damit Entwickler sie lesen können.

Kritische Falle — Neustart-Richtlinie:

{"restart_policy": "no"}

In Compose ist restart_policy: "no" ein gültiger Wert, der “Container nie neustarten” bedeutet. Ohne Anführungszeichen in YAML wird dies zu restart_policy: false, was Docker Compose entweder als dieselbe Semantik behandeln (falsy = kein Neustart) oder mit einem Typvalidierungsfehler ablehnen kann — das Verhalten variiert je nach Compose-Version. Die Anführungszeichen sind obligatorisch.

Achten Sie auch auf: Compose v3 deploy.restart_policy.condition: "on-failure" — der Wert on-failure enthält das Wort on, ist aber durch einen Bindestrich getrennt und nicht in der Triggerliste, daher ist er eigentlich sicher. Jedoch würde condition: on (ohne das -failure) konfligieren. Setzen Sie Umgebungsvariablenwerte im environment:-Block in Anführungszeichen, wenn sie Norway-Wörter sein könnten.

Validieren Sie Compose-Dateien nach der Konvertierung: docker-compose config parst und gibt die kanonische Form aus und bringt Typfehler zum Vorschein.

GitHub-Actions-Workflow

GitHub-Actions-Workflows sind YAML-Dateien, die von Entwicklern von Hand bearbeitet werden. Das häufigste Konvertierungsszenario ist das Lesen von Workflow-Daten aus der GitHub-API (die JSON zurückgibt) und die Konvertierung in eine lokale YAML-Datei zum Bearbeiten.

Die Schlüsselfelder, auf die zu achten ist:

# SICHER — keine Norway-Wörter in Standard-GitHub-Actions
on:                        # "on" ist hier ein YAML-Schlüssel, kein Wert — wird anders behandelt
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: |
          npm install
          npm test
        env:
          NODE_ENV: production   # sicher — kein Norway-Wort
          DEBUG: "off"           # Norway-Wort im Wert — braucht Anführungszeichen

Hinweis: on: als YAML-Schlüssel ist besonders — das Norway-Problem gilt für Werte, nicht für Schlüssel. Aber on als Wert (wie DEBUG: on) würde die Konvertierung auslösen. Der env:-Block verdient besondere Aufmerksamkeit, weil Umgebungsvariablenwerte Zeichenketten sind, aber viele von ihnen kurze Flags sind, die mit Norway-Wörtern kollidieren könnten.

Für Workflows, die shell:-Spezifikationen enthalten, sind gültige Werte (bash, pwsh, sh, python) alle sicher vor Norway-Konvertierung. Benutzerdefinierte Werte sollten proaktiv in Anführungszeichen gesetzt werden.

Terraform-JSON-Plan → YAML

terraform show -json tfplan > plan.json gibt eine detaillierte JSON-Darstellung dessen aus, was Terraform plant zu erstellen, zu ändern oder zu zerstören. Die Konvertierung nach YAML macht es lesbarer für Pull-Request-Reviews und Compliance-Audits.

terraform plan -out=tfplan
terraform show -json tfplan > plan.json
# Dann mit unserem Werkzeug oder einer Bibliothek konvertieren

Das Terraform-Plan-JSON ist komplex und tief verschachtelt. Wichtige Überlegungen bei der Konvertierung:

Große Ganzzahl-IDs. Cloud-Ressourcen-IDs (AWS-Konto-IDs, GCP-Projektnummern) und berechnete Attributwerte können große Zahlen sein. Konvertieren Sie über Python oder Go, um float64-Präzisionsverlust zu vermeiden.
Versionseinschränkungs-Zeichenketten. Terraform verwendet ~>, >=, <= in Provider-Versionseinschränkungen. Dies sind Zeichenkettenwerte, die YAML korrekt behandelt, solange sie keine Norway-Wörter sind — aber ~> ist sicher.
Provider-Konfigurationswerte. Terraform-Planausgaben können Konfigurationswerte für Ressourcen enthalten. Wenn ein boolesches Feld standardmäßig false ist und in einigen Provider-Schemas als "no" dargestellt wird, ist das auf dem Rückweg nach YAML ein Norway-Risiko.
Der .sensitive_values-Block. Sensible Werte werden im Plan-JSON als true-Booleans redigiert. Diese überleben die Konvertierung sauber, da true in keiner YAML-Version ein Norway-Wort ist.

Die Terraform-zu-YAML-Konvertierung dient primär der menschlichen Überprüfung, nicht dem Zurückladen in Terraform. Verwenden Sie YAML-Manifeste nicht als Terraform-Eingabe — Terraforms natives Format ist HCL, und sein JSON-Eingabeformat ist separat und dokumentiert.

Code-Beispiele — 4 Sprachen

Node.js (eemeli/yaml + js-yaml)

Das Node.js-Ökosystem hat zwei dominante YAML-Bibliotheken mit bedeutsam unterschiedlicher Norway-Behandlung:

// eemeli/yaml — empfohlen, YAML 1.2 standardmäßig, Norway-sicher
import { stringify } from 'yaml';
import { readFileSync } from 'fs';

const jsonInput = readFileSync('input.json', 'utf8');
const data = JSON.parse(jsonInput);

// Standard: YAML 1.2 — "NO" bleibt als "NO", keine boolesche Konvertierung
const yamlOutput = stringify(data);
console.log(yamlOutput);
// region: NO      ← sicher in 1.2, aber für maximale Kompatibilität explizit anführen

// YAML-1.1-Verhalten erzwingen (für K8s/Helm-Umgebungen, die 1.1 parsen)
const yamlForK8s = stringify(data, { version: '1.1' });
// region: 'NO'    ← automatisch in Anführungszeichen, weil 1.1 NO als false parsen würde
console.log(yamlForK8s);

// js-yaml — weit verbreitet, aber YAML-1.1-Semantik, Norway-riskant ohne Sorgfalt
import yaml from 'js-yaml';
import { readFileSync } from 'fs';

const data = JSON.parse(readFileSync('input.json', 'utf8'));

// Standard dump — Norway-Wörter werden möglicherweise nicht in Anführungszeichen gesetzt
const unsafe = yaml.dump(data);
// region: NO    ← wird als false geparst, wenn von einem 1.1-Parser erneut gelesen!

// Sicherer: ein benutzerdefiniertes Schema verwenden oder Anführungszeichen erzwingen
const safer = yaml.dump(data, {
  schema: yaml.JSON_SCHEMA,   // schränkt auf JSON-kompatible Typen ein
  noCompatMode: false,
  lineWidth: -1,
  quotingType: '"',
  forceQuotes: false,         // setzt nur in Anführungszeichen wenn nach JSON-Schema nötig
});

Für neue Projekte bevorzugen Sie eemeli/yaml. Sein YAML-1.2-Standard ist sicherer, seine Document-API gibt feingranulare Kontrolle über Anführungszeichen, und es behandelt die Round-Trip-Treue besser. Für Projekte, die bereits js-yaml verwenden, nutzen Sie die JSON_SCHEMA-Option, um auf JSON-sichere Typen zu beschränken.

Python (PyYAML + ruamel.yaml)

Python ist die dominante Sprache für Kubernetes-Werkzeuge, Ansible und Datenpipelines — alle starken YAML-Nutzer.

import json
import yaml
import sys

# PyYAML — einfach, standard, aber YAML 1.1 standardmäßig
with open('input.json') as f:
    data = json.load(f)

output = yaml.dump(data, default_flow_style=False, allow_unicode=True)
# country: 'NO'   ← PyYAML ist schlau genug, Norway-Wörter automatisch in Anführungszeichen zu setzen
# Aber es setzt "yes", "no" (Kleinschreibung) in einigen Konfigurationen nicht in Anführungszeichen:
# enabled: 'yes'   ← in Anführungszeichen
# tag: y           ← kann oder muss nicht in Anführungszeichen gesetzt werden je nach Version

print(output)

import json
import sys
from ruamel.yaml import YAML

# ruamel.yaml — Round-Trip-Treue, unterstützt YAML 1.2, für Produktion empfohlen
yaml_rt = YAML()
yaml_rt.default_flow_style = False
yaml_rt.width = 4096              # unerwünschten Zeilenumbruch verhindern
yaml_rt.best_map_flow_style = False

with open('input.json') as f:
    data = json.load(f)

yaml_rt.dump(data, sys.stdout)
# Behält Schlüsselreihenfolge bei, behandelt Norway-Wörter korrekt, unterstützt Anker beim Round-Trip

Für Ansible- und Kubernetes-Automatisierungsskripte, bei denen Sie JSON-API-Antworten in YAML-Manifeste konvertieren, ist ruamel.yaml die sicherere Wahl. PyYAML ist für einfache Skripte geeignet, bei denen Sie die Eingabedaten kontrollieren und überprüft haben, dass keine Norway-Wörter vorkommen.

Go (gopkg.in/yaml.v3)

Go ist die Sprache des Kubernetes-Ökosystems selbst — kubectl, Helm, Argo, Flux und die meisten K8s-Operatoren sind in Go geschrieben.

package main

import (
    "encoding/json"
    "fmt"
    "os"

    "gopkg.in/yaml.v3"
)

func main() {
    // JSON-Eingabe lesen
    jsonBytes, err := os.ReadFile("input.json")
    if err != nil {
        panic(err)
    }

    // JSON in eine generische Map unmarshalln
    var data map[string]interface{}
    if err := json.Unmarshal(jsonBytes, &data); err != nil {
        panic(err)
    }

    // Nach YAML marshalln — yaml.v3 verwendet YAML-1.2-Semantik
    yamlBytes, err := yaml.Marshal(data)
    if err != nil {
        panic(err)
    }

    fmt.Println(string(yamlBytes))
    // country: "NO"     ← yaml.v3 setzt Norway-Wörter korrekt in Anführungszeichen
    // replicas: 3       ← Ganzzahlen bleiben Ganzzahlen
    // enabled: true     ← boolesche Werte bleiben boolesche Werte
}

yaml.v3 ist eine erhebliche Verbesserung gegenüber yaml.v2 für die Norway-Sicherheit. Die v2-Bibliothek folgte YAML 1.1 und schrieb NO ohne Anführungszeichen; v3 setzt mehrdeutige Werte korrekt in Anführungszeichen. Wenn Sie ein älteres Go-Projekt pflegen, das v2 verwendet, upgraden Sie auf v3 — die API ist weitgehend kompatibel und die Sicherheitsverbesserung ist die Migration wert.

Für typsichere Konvertierung mit Go-Structs (statt map[string]interface{}), verwenden Sie Struct-Tags:

type DeploymentLabels struct {
    App    string `yaml:"app" json:"app"`
    Region string `yaml:"region" json:"region"`
}
// yaml.Marshal auf einem Struct-Feld, das "NO" enthält, setzt es in v3 korrekt in Anführungszeichen

Bash CLI (yq + jq)

Für Shell-Skripte und schnelle Einzelkonvertierungen konvertiert yq (Mike Farahs Version, mikefarah/yq) JSON mit einem einzigen Befehl nach YAML:

# yq installieren
brew install yq                         # macOS
sudo wget -qO /usr/local/bin/yq \
  https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64
chmod +x /usr/local/bin/yq              # Linux

# JSON-Datei nach YAML konvertieren
yq -P < input.json > output.yaml

# Aus kubectl-JSON-Ausgabe konvertieren
kubectl get deploy my-app -o json | yq -P > manifest.yaml

# Zuerst durch jq filtern/transformieren, dann nach YAML konvertieren
kubectl get deploy my-app -o json \
  | jq 'del(.status, .metadata.creationTimestamp, .metadata.managedFields)' \
  | yq -P > clean-manifest.yaml

Das jq | yq-Pipeline-Muster ist leistungsstark: Verwenden Sie jq für JSON-Manipulation (Felder filtern, Struktur umformen, Werte abfragen) und yq -P als finalen YAML-Serialisierer.

Norway-Vorsicht mit yq: yq (mikefarah) respektiert den Eingabetyp aus JSON — eine JSON-Zeichenkette "NO" in der Eingabe wird als YAML-Zeichenkette mit Anführungszeichen serialisiert. Aber wenn Sie YAML direkt mit yq generieren (nicht aus JSON-Eingabe), müssen Sie Norway-Wort-Werte explizit in Anführungszeichen setzen. Verwenden Sie unseren YAML-zu-JSON-Konverter, um den Round-Trip nach yq-Ausgabe zu validieren.

Randfälle und Fallstricke

Neben dem Norway-Problem hat die JSON ↔ YAML-Konvertierung mehrere Randfälle, die erfahrene Entwickler stolpern lassen:

Multi-Dokument-YAML (----Trennzeichen). Eine einzige YAML-Datei kann mehrere durch --- getrennte Dokumente enthalten. JSON hat kein äquivalentes Konzept. Bei der Konvertierung von Multi-Dokument-YAML nach JSON nehmen die meisten Werkzeuge entweder nur das erste Dokument, fügen alle Dokumente in ein Array zusammen oder erzeugen einen Fehler. Bei der Konvertierung von JSON nach YAML wird konventionell ein einzelner ----Dokumentheader hinzugefügt. Entscheiden Sie das Verhalten explizit für Pipelines, die auf Multi-Dokument-Dateien stoßen könnten.
YAML-Anker und -Aliase. YAML unterstützt &Anker-Definitionen und *Alias-Referenzen für DRY-Konfigurationen. Bei der Konvertierung von YAML nach JSON müssen Anker expandiert werden — das resultierende JSON kann viel größer sein als das Quell-YAML. Bei der Konvertierung von JSON nach YAML kann der Konverter Anker, die im Original nicht existierten, nicht rekonstruieren. Aliase sind eine reine YAML-Funktion.
Implizites Timestamp-Parsen. YAML-1.1-Parser konvertieren 2024-05-04 und 2024-05-04T12:00:00Z in sprachnativen Datumsobjekte, keine Zeichenketten. Wenn dieses Datumsobjekt zurück nach JSON serialisiert wird, hängt die Ausgabe von der Bibliothek ab: Einige geben ISO-Zeichenketten aus, einige Unix-Timestamps, einige null. Das Weiterleiten von Datumswerten durch YAML ohne explizites Zeichenketten-Anführungszeichen ("2024-05-04") kann das Format stillschweigend ändern.
Der !!binary-Tag. YAML kann base64-kodierte Binärdaten mit dem !!binary-Tag einbetten. JSON hat keinen Binärtyp — Binärdaten müssen eine base64-Zeichenkette sein. Bei der Konvertierung von YAML mit !!binary-Feldern nach JSON zu base64-Zeichenkette dekodieren. Beim Zurückkonvertieren können Sie den Binär-Tag ohne Kenntnis des Schemas nicht rekonstruieren. Kubernetes verwendet !!binary für einige Secret-Werte.
Schlüsseltyp-Kollisionen. JSON erfordert, dass Objektschlüssel Zeichenketten sind. YAML erlaubt Schlüssel beliebigen Typs — Ganzzahl-Schlüssel, boolesche Schlüssel, sogar komplexe Objekt-Schlüssel. Eine YAML-Datei mit true: value oder 1: value als Schlüssel kann nicht treu als JSON dargestellt werden. Die meisten Konverter stringifizieren die Schlüssel, aber die Semantik ändert sich.
Null-Darstellungsvarianz. In YAML bedeuten null, ~, Null, NULL und ein leerer Wert alle null. In JSON ist nur null null. Bei der Konvertierung von YAML nach JSON normalisieren sich alle zu null. Aber bei der Rückkonvertierung von JSON nach YAML ist die Wahl der Null-Darstellung wichtig — ~ ist kompakter, null ist expliziter. Wählen Sie eine und bleiben Sie dabei.
Reihenfolgeänderungen. JSON-Objekte haben technisch gesehen keine definierte Schlüsselreihenfolge (obwohl die meisten Parser die Einfügereihenfolge beibehalten). YAML-Mappings haben ebenfalls keine erforderliche Reihenfolge. Aber einige YAML-Bibliotheken sortieren Schlüssel standardmäßig alphabetisch bei der Serialisierung. Dies kann zu großen Diffs in der Versionskontrolle führen, wenn das Quell-JSON eine andere Reihenfolge verwendet hat. Konfigurieren Sie sort_keys=False in PyYAML und äquivalente Optionen in anderen Bibliotheken.

Wann man NICHT konvertieren sollte

Konvertierung ist nicht immer die richtige Antwort. Hier sind die Szenarien, in denen es besser ist, im ursprünglichen Format zu bleiben:

Konvertieren Sie YAML nicht nach JSON, wenn das YAML Kommentare enthält, die Geschäftslogik dokumentieren. YAML-Kommentare sind nicht Teil des Datenmodells — sie verschwinden bei jeder Serialisierung nach JSON. Wenn ein Kubernetes-Manifest Kommentare enthält, die erklären, warum ein bestimmtes Ressourcenlimit gewählt wurde oder warum eine Sicherheitsrichtlinienausnahme gemacht wurde, zerstört die Konvertierung nach JSON diese Dokumentation. Behalten Sie das YAML.

Konvertieren Sie Konfigurationen in CI-Pipelines nicht automatisch ohne Round-Trip-Tests. Wenn Ihre Pipeline JSON nach YAML konvertiert und das YAML dann auf einen Cluster anwendet, fügen Sie einen Round-Trip-Validierungsschritt hinzu: YAML zurück nach JSON, dann mit dem Original vergleichen. Dies erkennt Typkonvertierungs-Überraschungen, bevor sie die Produktion erreichen.

Konvertieren Sie nicht nur, weil ein Werkzeug JSON ausgibt. kubectl, aws, terraform und docker inspect geben alle JSON aus, aber die meisten dieser Werkzeuge akzeptieren auch YAML als Eingabe. Bevor Sie einen Konvertierungsschritt erstellen, prüfen Sie, ob das Zielwerkzeug direkt YAML-Eingabe akzeptieren kann — die meisten modernen DevOps-Werkzeuge können. Unser YAML-zu-JSON-Konverter ist am nützlichsten, wenn Sie speziell JSON für ein Werkzeug benötigen, das kein YAML akzeptiert.

Konvertieren Sie nicht, wenn die Schemas sich unterscheiden. Wenn Ihr JSON camelCase-Schlüssel verwendet und Ihr YAML-Verbraucher snake_case erwartet (oder umgekehrt), benötigen Sie einen Transformationsschritt zusätzlich zu einer Formatkonvertierung. Eine bloße Formatkonvertierung erzeugt syntaktisch korrektes, aber semantisch falsches YAML. Adressieren Sie das Schema-Mapping explizit.

Halten Sie nicht beide Formate manuell synchron. Wenn Sie eine config.json und eine config.yaml pflegen, die equivalent sein sollen, werden sie auseinanderlaufen. Wählen Sie ein kanonisches Format und leiten Sie das andere automatisch ab — oder wählen Sie besser ein Format und eliminieren Sie die Duplizierung.

FAQ

Betrifft das YAML-Norway-Problem noch moderne Systeme?

Ja — es ist im Ökosystem weit verbreitet. Kubernetes und Helm verwenden Gos yaml.v2-Bibliothek (YAML-1.1-Semantik) in wesentlichen Teilen ihrer Codebasen. Ansible verwendet PyYAML (YAML 1.1). GitHub-Actions-Workflows werden von GitHubs internem YAML-Parser geparst, der sein eigenes Verhalten hat. Die meisten CI/CD-YAML-Dateien in der freien Wildbahn werden von YAML-1.1-Parsern verarbeitet. Gehen Sie von 1.1-Semantik aus, bis Sie das Gegenteil überprüft haben.

Warum sollte ich JSON nach YAML konvertieren, wenn YAML schwieriger zu parsen ist?

Die Konvertierung hat nichts mit Parser-Schwierigkeit zu tun — es geht um menschliche Editierbarkeit. JSON ist ideal für Maschinen; YAML ist ideal für Menschen, die Konfigurationsdateien lesen, bearbeiten und überprüfen müssen. Ein Kubernetes-Manifest, das in Git eingecheckt, in Pull Requests überprüft und von Ingenieuren von Hand angepasst wird, sollte YAML sein. Dasselbe Manifest, das von der API für programmatische Verarbeitung abgerufen wird, sollte JSON sein. Unser JSON-zu-YAML-Konverter überbrückt beide Welten.

Kann ich JSON ↔ YAML verlustlos hin- und herkonvertieren?

Mit Einschränkungen, ja — für JSON-kompatible Daten. JSON ist eine Teilmenge von YAML 1.2, daher ist jedes gültige JSON-Dokument gültiges YAML 1.2. JSON → YAML → JSON sollte für alle Daten ohne implizite Typkonvertierung verlustlos sein. Das Norway-Problem bedeutet, dass eine JSON-Zeichenkette "NO" den Vorwärtsdurchgang nur überleben könnte, wenn der Konverter sie in Anführungszeichen setzt, und dann den Rückwärtsdurchgang nur, wenn der YAML-Parser die Anführungszeichen respektiert. Verwenden Sie eine YAML-1.2-Bibliothek für beide Richtungen, um verlustlose Round-Trips zu garantieren.

Was ist die sicherste YAML-Bibliothek für die Produktion?

Für Python: ruamel.yaml konfiguriert für YAML 1.2. Für Node.js: eemeli/yaml (das yaml-Paket auf npm). Für Go: gopkg.in/yaml.v3. Alle drei implementieren YAML-1.2-Semantik oder haben explizite YAML-1.2-Modi und behandeln Norway-Wörter korrekt. Vermeiden Sie YAML-1.1-Bibliotheken in neuen Projekten. Wenn Sie aus Kompatibilitätsgründen eine 1.1-Bibliothek (PyYAML, js-yaml, yaml.v2) verwenden müssen, setzen Sie Norway-gefährdete Zeichenketten immer explizit in Anführungszeichen.

Unterstützen Kubernetes-Manifest-YAML nach der JSON-Konvertierung Kommentare?

Nein — Kommentare können aus JSON nicht wiederhergestellt werden. JSON hat keine Kommentarsyntax, also gibt es nichts zu konvertieren. Wenn Sie kubectl get deploy -o json ausführen und die Ausgabe nach YAML für die Git-Speicherung konvertieren, hat das resultierende YAML keine Kommentare. Kommentare in einem Kubernetes-Manifest müssen von einem Menschen nach der Konvertierung geschrieben werden. Dies ist ein Grund, warum das Beibehalten des handgeschriebenen YAML als kanonische Quelle oft gegenüber dem Round-Trip durch die JSON-API vorzuziehen ist.

Wie gehe ich mit großen Ganzzahlen wie resourceVersion oder Nanosekunden-Timestamps um?

Kubernetes metadata.resourceVersion ist absichtlich ein Zeichenkettenfeld — das Kubernetes-Team wusste, dass JSON-Parser in JavaScript und anderen float64-basierten Laufzeiten bei großen Ganzzahlen Präzision verlieren würden. Behandeln Sie es immer als Zeichenkette. Für genuinen numerischen großen Ganzzahlen (wie Nanosekunden-Epoch-Timestamps in einigen Tracing-Systemen) verwenden Sie Pythons int-Typ, Gos int64 oder Node.js BigInt zum Parsen. Übergeben Sie sie niemals durch JSON.parse() in JavaScript ohne eine benutzerdefinierte Reviver-Funktion. Bei der Konvertierung nach YAML sind diese großen Ganzzahlen sicher — YAML hat kein Präzisionslimit für Ganzzahlen. Die Gefahr liegt im Round-Trip zurück durch JavaScripts JSON-Parser.

Ist YAML 1.2 bereits weit verbreitet?

Ungleichmäßig. Die wichtigsten Sprachbibliotheken migrieren: Gos yaml.v3, Pythons ruamel.yaml und Node.js eemeli/yaml unterstützen oder verwenden standardmäßig YAML 1.2. Aber Kubernetes, Ansible und ein Großteil des DevOps-Ökosystems laufen aufgrund der Rückwärtskompatibilitätskosten noch auf YAML-1.1-Parsern. YAML-1.2-Adoption in neuen Projekten wird empfohlen, aber gehen Sie für jedes System, das Sie nicht selbst konfiguriert haben, von 1.1 aus.

Sollte unser Team JSON oder YAML für Konfigurationen standardisieren?

Standardisieren Sie nach Zweck, nicht nach Format. Verwenden Sie JSON für Konfigurationen, die von Code verarbeitet werden (API-Anfragen-Bodies, SDK-Konfigurationsdateien, programmatische Werkzeuge). Verwenden Sie YAML für Konfigurationen, die von Menschen verarbeitet werden (Kubernetes-Manifeste, CI-Pipelines, Deployment-Konfigurationen, Ansible-Playbooks). Vermeiden Sie das Mischen beider für dieselbe Konfiguration — wählen Sie eine Darstellung pro Konfigurationstyp und automatisieren Sie die Konvertierung, wenn Sie beide benötigen. Wenn Sie konvertieren müssen, laufen sowohl unser JSON-zu-YAML- als auch unser YAML-zu-JSON-Konverter vollständig in Ihrem Browser — keine Daten verlassen Ihr Gerät.

Jetzt ausprobieren

Bereit, eine echte Datei zu konvertieren? Probieren Sie unseren JSON-zu-YAML-Konverter zum Bereinigen von JSON in sicheres Kubernetes-YAML — er setzt Norway-Wörter automatisch in Anführungszeichen (NO, yes, on, off und die vollständige YAML-1.1-Booleanliste) und ermöglicht es Ihnen, zwischen 2-Leerzeichen- und 4-Leerzeichen-Einrückung zu wählen. Für die umgekehrte Richtung verarbeitet unser YAML-zu-JSON-Konverter Anker, Aliase und Multi-Dokument-YAML. Beide Werkzeuge laufen vollständig in Ihrem Browser — Ihre Daten verlassen niemals Ihr Gerät, was wichtig ist, wenn Sie mit Produktions-Kubernetes-Manifesten oder Terraform-Plänen arbeiten, die sensible Ressourcenkonfigurationen enthalten.

Das YAML-Norway-Problem und JSON-YAML-Unterschiede für Entwickler