Kostenloser YAML-zu-JSON-Konverter

Was ist YAML?

YAML (YAML Ain’t Markup Language) ist ein menschenfreundliches Datenserialisierungsformat, das einfach zu lesen und zu schreiben ist. Es wird häufig für Konfigurationsdateien, CI/CD-Pipelines und den Datenaustausch zwischen Programmiersprachen verwendet.

Warum YAML in JSON konvertieren?

• Universelle Kompatibilität · JSON wird von praktisch allen Programmiersprachen und Tools unterstützt.
• Konfigurationsverwaltung · Viele Tools erwarten JSON für die Konfiguration oder den Datenaustausch.
• API-Integration · Web-APIs erfordern in der Regel das JSON-Format.
• Datenverarbeitung · Konvertieren Sie YAML-Konfigurationsdateien zur Verwendung in automatisierten Workflows.

Häufig gestellte Fragen

Welche YAML-Funktionen werden unterstützt?

Der Konverter unterstützt alle Standard-YAML 1.2-Funktionen, einschließlich Maps, Listen, Skalartypen (Zeichenketten, Zahlen, Booleans, null), Ankern und Aliasen, mehreren Dokumenten und verschachtelten Strukturen.

Wird meine komplexe YAML-Struktur korrekt konvertiert?

Ja. Der Konverter verarbeitet tief verschachtelte Strukturen, Arrays von Objekten, Ankerreferenzen und gemischte Datentypen. Wenn Ihr YAML gültig ist, wird ein äquivalentes JSON erzeugt, das alle Datenbeziehungen beibehält.

Werden YAML-Kommentare beibehalten?

Nein. JSON unterstützt keine Kommentare, daher werden sie bei der Konvertierung entfernt. Nur die strukturierten Daten aus Ihrem YAML werden in das JSON-Format konvertiert.

Eine kurze Geschichte von YAML, ein Mailinglisten-Ableger von 2001

YAMLs Vorgeschichte beginnt auf der Mailingliste sml-dev, einem Ableger von xml-dev aus den 2000er-Jahren, der Menschen zusammenbrachte, die XML für von Menschen bearbeitete Daten als übertrieben empfanden. Zwei parallele Stränge liefen zusammen: Ingy döt Nets Perl-Modul Data::Denter, geschrieben als Serialisierungsformat für das Modul Inline Perl, und gemeinsame Arbeit von Oren Ben-Kiki und Clark Evans mit dem Ziel, XML zu vereinfachen. Am 11. Mai 2001 postete Clark Evans „YAML Draft 0.1“ auf sml-dev, und das Format wurde am nächsten Tag erstmals in einem xmlhack-Artikel öffentlich gemacht.

Die ursprüngliche Auflösung des Akronyms war augenzwinkernd gemeint: Yet Another Markup Language, ein Seitenhieb auf die Vermehrung von Markup-Formaten im Jahr 2001. Zwischen Dezember 2001 und April 2002 versahen die Autoren es nachträglich mit dem rekursiven Backronym YAML Ain't Markup Language: teils, um zu betonen, dass YAML ein Datenserialisierungsformat und kein Dokument-Markup-Format wie XML oder HTML ist, und teils, weil der Witz gealtert war. Die rekursive Auflösung ist bis heute der offizielle Slogan auf yaml.org.

Zeitleiste der Spezifikation

• Draft 0.1: 11. Mai 2001, Ankündigung auf der Mailingliste sml-dev.
• YAML 1.0: 29. Januar 2004, die erste stabile Spezifikation, von Ben-Kiki, Evans und Ingy döt Net.
• YAML 1.1: 18. Januar 2005, die Version, die die meisten „Legacy“-Parser standardmäßig noch nachbilden. Quelle des Norwegen-Problems und der meisten Macken der impliziten Typisierung.
• YAML 1.2.0: 21. Juli 2009, die erste Revision mit dem ausdrücklichen Ziel einer „JSON-Obermenge“. Die implizite Typisierung wurde neu geschrieben, um sich an den Token von JSON auszurichten.
• YAML 1.2.1: 1. Oktober 2009, eine reine Errata-Auffrischung von 1.2.0.
• YAML 1.2.2: 1. Oktober 2021, die Korrigenda-Revision durch das 2020 gebildete neue YAML Language Development Team.

Die 1.2.2-Spezifikation stellt ausdrücklich fest, dass es „keine normativen Änderungen gegenüber der YAML-Spezifikation v1.2“ gibt; die Arbeit bestand darin, die Quelle von DocBook nach Markdown zu konvertieren, Diagramme aus reinem LaTeX-Text neu zu erzeugen und den Entwicklungsprozess zu öffnen, damit externe Mitwirkende Pull Requests gegen die Spezifikation selbst einreichen können. Seit 2009 ist keine Sprachversion erschienen: Jeder Parser-Konformitätsfehler seither ist entweder ein 1.1-Überbleibsel oder eine Abweichung von einer Spezifikation, die nun seit über fünfzehn Jahren Bestand hat. Der offizielle MIME-Typ application/yaml wurde 2024 finalisiert; die Dateiendungen .yaml und .yml sind beide seit etwa 2006 anerkannt, wobei .yaml die empfohlene ist.

Die Beziehung zu JSON, „fast eine Obermenge“

Die YAML-1.2.2-Spezifikation formuliert es vorsichtig: „Durch reinen Zufall war JSON fast eine vollständige Teilmenge von YAML.“ JSON erschien zwischen YAML 1.0 (2004) und YAML 1.1 (2005); die YAML-Autoren entdeckten die Überschneidung erst rückwirkend. Das ausdrückliche Ziel der 1.2-Revision war, in ihren eigenen Worten, „YAML zu einer strikten Obermenge von JSON zu machen“, und das ist für JSON-formatierte YAML-1.2-Dokumente fast wahr, aber für YAML 1.1 nicht wahr.

Praktisch gesehen: Jedes JSON-Dokument ist gültiges YAML 1.2, das Flow-Style-Mapping {"a": 1, "b": [true, null]} wird in beiden identisch geparst. Die meisten JSON-Dokumente sind kein gültiges YAML 1.1 wegen der Fallstricke bei Booleschen Werten und beim Norwegen-Problem: Ein JSON-Dokument, das den Literalstring "NO" enthält, würde beim Hin- und Herwandeln durch einen 1.1-Parser mit Standardeinstellungen als false neu ausgegeben. Das Umgekehrte gilt nie: YAML kann Dinge ausdrücken, die JSON nicht kann, Kommentare (bei der Konvertierung verloren), Anker und Aliasse (bei der Konvertierung aufgelöst), Tags (typischerweise verworfen), Streams mit mehreren Dokumenten (nur das erste oder alle als Array überleben) und Nicht-String-Schlüssel in Mappings.

Das Norwegen-Problem

YAMLs meistzitierter Fallstrick. Er ist nach Norwegen benannt, weil der zweibuchstabige ISO-3166-1-Ländercode für Norwegen NO ist und die Boolesche Regex von YAML 1.1 NO als das Boolesche false erkennt. Schreiben Sie country: NO in YAML 1.1 (oder in einem beliebigen 1.2-Parser, der noch auf 1.1-Verhalten voreingestellt ist, was bei den meisten der Fall ist), parsen Sie es, geben Sie es als JSON aus, und Sie erhalten {"country": false}. Der Fehler ist still, es gibt keine Warnung, keinen Typfehler, nur Datenkorruption.

Die vollständige Boolesche Regex von YAML 1.1 aus dem offiziellen Schema yaml.org/type/bool.html lautet:

y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF

Das sind sechs Lexeme (y/n, yes/no, on/off, true/false) mit je drei Schreibweisen, zweiundzwanzig Strings, die alle ohne Warnung zu Booleschen Werten werden. Eine Liste gültiger Antworten [y, n, maybe] wird zu [true, false, "maybe"]; ein Feature-Flag dark_mode: on wird als dark_mode: true geparst; eine als OFF geschriebene Port-Modus-Einstellung wird zu false. YAML 1.2 hat dies auf Spezifikationsebene behoben: Das an JSON ausgerichtete Core-Schema erkennt nur true, True, TRUE, false, False, FALSE und erkennt y/n/yes/no/on/off überhaupt nicht. Aber diese Korrektur hat sich in der Praxis nicht durchgesetzt, PyYAML und LibYAML sind in allen derzeit ausgelieferten Versionen weiterhin auf 1.1 voreingestellt. Dieser Konverter verwendet js-yaml v4, das auf das YAML-1.2-/JSON-kompatible Schema voreingestellt ist; das ist ein Grund, warum ein browserseitiger Konverter tatsächlich sicherer ist, als yaml.load() in PyYAML auszuführen und von dort zu konvertieren.

Weitere Tretminen der impliziten Typisierung

Oktalzahlen. YAML 1.1 folgte der C-Konvention: Eine führende Null bedeutete oktal. So wurde 010 als die Ganzzahl 8 geparst, und permissions: 0777 (eine völlig natürliche Art, einen Unix-Dateimodus zu schreiben) wurde als 511 geparst. Die Korrektur in YAML 1.2 bestand darin, ein ausdrückliches 0o-Präfix zu verlangen, passend zum modernen Python, 0o777 ist 511, und 0777 ist einfach 777. Parser, die auf 1.1-Standardeinstellungen festsitzen, machen das immer noch falsch.

Sexagesimalzahlen. YAML 1.1 erbte von früheren Serialisierungsformaten die Konvention, dass jede durch Doppelpunkte getrennte Folge von Dezimalzifferngruppen als Ganzzahl oder Gleitkommazahl zur Basis 60 (sexagesimal) geparst werden sollte. Der beworbene Anwendungsfall waren Zeitdauern: 1:11:00 würde als die Ganzzahl 4260 geparst (eine Stunde, elf Minuten in Sekunden). Diese Regel beißt Menschen in der Praxis bis heute, wenn sie Zeitstempel wie 21:00 oder Versionsnummern wie 2:3:4 schreiben und feststellen, dass sie stillschweigend zu Ganzzahlen umgewandelt werden. Sexagesimal wurde in YAML 1.2 stillschweigend entfernt, aber PyYAML und andere 1.1-voreingestellte Parser wenden es weiterhin an.

Automatische Datums-/Zeit-Umwandlung. YAML 1.1 erkennt außerdem automatisch ISO-8601-Zeitstempel und parst sie als den nativen Datums-/Zeittyp der Hostsprache, was ein Problem ist, wenn Sie einen String wollten. Schreiben Sie version: 2024-01-15, und Sie erhalten ein Python-date-Objekt, nicht den String "2024-01-15". Die allgemeine Lehre, die Ruud van Asseldonks Essay „YAML document from hell“ einhämmert: Setzen Sie immer Strings in Anführungszeichen, die denkbar als etwas anderes geparst werden könnten. Ländercodes, Versionsnummern, Dateimodi, Zeitstempel und jeder Wert aus einem festen Vokabular sollten in einfache oder doppelte Anführungszeichen gesetzt werden.

Anker, Aliasse und der Merge-Schlüssel

YAMLs Anker-/Alias-System erlaubt es Ihnen, einen Knoten mit &name zu kennzeichnen und ihn später mit *name wiederzuverwenden. Das klassische Beispiel:

defaults: &defaults
  timeout: 30
  retries: 3
production:
  <<: *defaults
  host: prod.example.com

Hier verankert &defaults das Mapping, und <<: *defaults (der Merge-Schlüssel (ein 1.1-Schema-Merkmal, das die meisten Parser beibehalten) fügt es in den Produktionsblock ein. Wenn dies in JSON konvertiert wird, wird der Alias vollständig aufgelöst) die JSON-Ausgabe enthält den wörtlich wiederholten Inhalt, keine Referenz. Anker und Aliasse verschwinden, und etwaige Merge-Schlüssel werden eingeebnet.

Der berühmte Fehlermodus dieses Systems ist der Billion-Laughs-Angriff: Weil Anker mehrfach als Alias verwendet werden können und Alias-Ziele selbst Aliasse enthalten können, kann eine kleine YAML-Datei zu einer riesigen Struktur im Speicher expandieren (10 Ebenen × 10-fache Verschachtelung = 10¹⁰ String-Elemente). PyYAML, LibYAML und andere mussten Expansionsgrenzen hinzufügen, um dies abzumildern. Browserseitige Konverter haben natürliche Speichergrenzen (der Tab geht in den Speichermangel, lange bevor der Host leidet), aber das strukturelle Risiko ist real.

Streams mit mehreren Dokumenten und Front Matter

Ein YAML-Stream kann mehr als ein Dokument enthalten. Dokumente werden durch eine Zeile getrennt, die genau --- enthält (auch als Markierung für das Ende der Direktiven am Anfang des ersten Dokuments verwendet, weshalb Front Matter in Jekyll, Hugo und Eleventy von ----Zeilen eingeklammert wird). Eine Zeile, die ... enthält, markiert das Ende eines Dokuments, ohne ein neues zu beginnen, nützlich in Streaming-Protokollen.

Kubernetes verwendet ---, um mehrere Ressourcen-Manifeste in einer Datei zu bündeln. JSON hat kein Äquivalent. Ein Konverter hat drei Möglichkeiten, wenn er auf YAML mit mehreren Dokumenten trifft: nur das erste Dokument ausgeben, ein JSON-Array von Dokumenten ausgeben oder ein JSON-Dokument pro --- ausgeben, getrennt durch Zeilenumbrüche (JSON Lines). Die meisten Konverter verwenden standardmäßig die erste oder zweite Option; js-yamls loadAll gibt ein Array zurück.

Mehrzeilige Strings, gefaltet vs. wörtlich

YAML hat zwei Block-Skalar-Stile. Der wörtliche Stil (|) bewahrt Zeilenumbrüche exakt. Der gefaltete Stil (>) ersetzt einzelne Zeilenumbrüche durch Leerzeichen und bewahrt Leerzeilen als Absatztrenner. Beide akzeptieren Chomping-Indikatoren: |- und >- entfernen alle abschließenden Zeilenumbrüche, |+ und >+ behalten sie alle, und das unveränderte | oder > („clip“) bewahrt einen einzelnen abschließenden Zeilenumbruch. Bei der Konvertierung in JSON erzeugen beide Stile gewöhnliche String-Werte, der gefaltete Block wird zu einem langen String mit eingebettetem \n nur an bewahrten Leerzeilen; der wörtliche Block hat \n an jedem Zeilenumbruch.

Was bei der Konvertierung verloren geht

• Null-Darstellungen fallen zusammen. YAML akzeptiert null, Null, NULL, ~ und einen leeren Wert (key: ohne etwas dahinter) als null. Alle fünf werden zu JSON-null, ununterscheidbar.
• Kommentare verschwinden stillschweigend. YAML-Kommentare beginnen mit #, und die 1.2-Spezifikation stellt ausdrücklich klar, dass sie nur der Darstellung dienen und nicht Teil des Datenmodells sind. JSON hat keine Kommentarsyntax. Wenn Sie sie bewahren müssen, speichern Sie sie vor der Konvertierung als Daten (z. B. ein _comment-Feld).
• Nicht-String-Schlüssel werden umgewandelt. YAML-Mappings erlauben jeden Knoten als Schlüssel, einschließlich Ganzzahlen (1: foo), Boolescher Werte (true: yes) und sogar verschachtelter Sequenzen. JSON verlangt String-Schlüssel. Die meisten Konverter wandeln in Strings um ("1": "foo"); einige werfen einen Fehler.
• Tags werden typischerweise verworfen. Benutzerdefinierte Tags wie !!set, !!omap oder anwendungsspezifische !myapp/Type haben kein JSON-Äquivalent.
• Datums-/Zeitwerte überleben als Strings. Ein YAML-Datum oder -Zeitstempel wird in JSON üblicherweise zu einem ISO-8601-String, da JSON keinen nativen Datumstyp hat.
• Große Ganzzahlen verlieren in JavaScript an Präzision. JSON-Zahlen sind in JS IEEE-754-Doubles, sodass eine YAML-Ganzzahl wie 9007199254740993 nach der Konvertierung stillschweigend zu 9007199254740992 wird.
• Anker werden expandiert. Ein YAML-Graph, der einen Teilbaum über mehrere Positionen hinweg teilt, wird zu einem JSON-Baum mit dupliziertem Teilbaum. Zyklische Referenzen (die YAML erlaubt) sind in JSON überhaupt nicht darstellbar.

Wo YAML tatsächlich verwendet wird

YAML ist in der modernen Infrastruktur allgegenwärtig: Kubernetes-Manifeste (das gesamte Objektmodell ist per Konvention YAML; Dateien mit mehreren Dokumenten, getrennt durch ---, sind Standard), Docker Compose (docker-compose.yml für Services, Netzwerke, Volumes), GitHub Actions (.github/workflows/*.yml: striktes YAML-1.2-Schema wird meist eingehalten, aber der Parser erkennt on: weiterhin als Schlüssel, ein Beinahe-Treffer des Norwegen-Problems, den GitHub ausdrücklich umgeht), GitLab CI/CD, Ansible-Playbooks, CircleCI / Travis CI / Drone / Bitbucket Pipelines, Jekyll / Hugo / Eleventy / Gatsby / Astro Front Matter, OpenAPI-/Swagger-Spezifikationen (offiziell „ein JSON-Objekt, das entweder in JSON oder YAML dargestellt werden kann“), Prometheus / Grafana / Loki / Tempo Monitoring-Stack-Konfiguration, cloud-init (Erstboot-Bereitstellung von EC2-/GCE-/Azure-VMs) und AWS CloudFormation / Azure Resource Manager / Google Cloud Deployment Manager. Für die meisten davon ist die YAML-zu-JSON-Konvertierung unverzichtbar, wann immer Sie Konfiguration in reine JSON-Protokolle einbetten, Dateien mit jq vergleichen oder die Ausgabe einem Werkzeug zuführen, das JSON erwartet.

Warum die browserseitige Konvertierung sicherer ist als die serverseitige

PyYAMLs yaml.load() mit Standardeinstellungen konnte über das Tag !!python/object beliebigen Python-Code auf jeder nicht vertrauenswürdigen Eingabe ausführen, das in tatsächliche Python-Objekte mit Seiteneffekten deserialisiert, CVE-2017-18342, CVSS-v3.1-Wert 9,8 (Kritisch), behoben in PyYAML 5.1 (März 2019), indem der unsichere Standard für veraltet erklärt und safe_load() zum empfohlenen Einstiegspunkt gemacht wurde. Javas SnakeYAML hatte ein eigenes Äquivalent (CVE-2022-1471, ebenfalls CVSS 9,8) rund um die Constructor-Klasse, die beliebige Instanziierung erlaubte. Rusts De-facto-Crate serde_yaml wurde im März 2024 für veraltet erklärt; das Ökosystem einigt sich noch auf einen Nachfolger (serde_yml, serde_yaml_ng, serde_norway).

Das Parsen im Browser über js-yaml v4 umgeht all dies: Es gibt keinen Server, den man kompromittieren könnte, js-yaml kennt kein Konzept der Ausführung beliebigen Codes über Tags (unbekannte Tags werden zu schlichten Skalaren statt zu konstruierten Objekten), und v4 ist auf das sicherere 1.2-Schema voreingestellt. Das Absolutool-Tool profitiert standardmäßig davon.

Weitere Fragen

Wie behandelt der Konverter YAML-Dateien mit mehreren Dokumenten?

Er lädt sie mit js-yamls loadAll, das ein Array geparster Dokumente zurückgibt, die JSON-Ausgabe ist daher ein JSON-Array mit einem Element pro durch --- getrenntem Dokument. Wenn Sie nur ein einzelnes Dokument haben, erhalten Sie ein JSON-Array mit einem Element; klammern Sie Ihre Eingabe in ----/...-Markierungen ein, wenn Sie eine ausdrückliche Einzeldokument-Semantik wünschen.

Wird mein Kubernetes-Manifest korrekt konvertiert?

Fast immer ja. Kubernetes verwendet größtenteils YAML-1.2-kompatiblen Inhalt, und js-yaml v4 behandelt alle Standard-Primitive (Strings, Ganzzahlen, Boolesche Werte, Nullwerte, Sequenzen, Mappings) plus Anker und Aliasse. Die beiden Teile, die nicht überleben, sind Kommentare (entfernt) und alle Anker, die zu wiederholtem Inhalt statt zu Referenzen expandiert werden.

Warum wird mein Ländercode NO als Boolescher Wert gelesen?

In diesem Konverter sollte das nicht passieren, js-yaml v4 ist auf das YAML-1.2-/JSON-kompatible Schema voreingestellt, das y/n/yes/no/on/off nicht als Boolesche Werte erkennt. Wenn Ihnen das in einem anderen Werkzeug begegnet (etwa PyYAML), besteht die Lösung darin, den Wert in Anführungszeichen zu setzen: country: "NO".

Wie groß ist das Dateigrößenlimit?

5 MB beim Upload-Widget, aber eingefügter Inhalt kann größer sein, wenn Ihr Browser den Speicher hat. Der Engpass ist die Darstellung im Speicher, nicht das Netzwerk, es ist kein Server im Spiel. Für Dateien größer als ~50 MB ziehen Sie stattdessen eine Desktop-YAML-Toolchain in Betracht (etwa yq auf der Kommandozeile).

Verwandte Tools