JSON-zu-YAML-Konverter

1. 1

   JSON einfügen oder hochladen

   Fügen Sie JSON in den Editor ein oder legen Sie eine .json-, .ndjson- oder .jsonl-Datei auf der Seite ab. Nichts wird hochgeladen — die Datei wird auf Ihrem Gerät gelesen.

2. 2

   Ziel-Parser wählen

   Portabel ist die Voreinstellung und quotiert jeden Wert, den ein YAML-1.1-Parser oder ein Parser mit Zeitstempelauflösung als anderen Typ lesen würde. Wählen Sie YAML 1.2 für minimale Quotierung oder alles quotieren, wenn der Leser unbekannt ist.

3. 3

   Layout festlegen

   Wählen Sie den Einzug, wie Null geschrieben wird und ob das Dokument mit --- beginnt. Die Vorschau aktualisiert sich bei jeder Änderung.

4. 4

   Konvertieren und prüfen

   Klicken Sie auf In YAML konvertieren. Das Ergebnis wird mit einem unabhängigen Parser zurückgelesen und mit Ihrem ursprünglichen JSON verglichen; das Abzeichen sagt, ob jeder Wert erhalten blieb.

5. 5

   Herunterladen oder kopieren

   Laden Sie die .yaml-Datei herunter oder kopieren Sie sie. Für die Gegenrichtung gibt es das Werkzeug YAML zu JSON.

Dieser kostenlose Konverter wandelt JSON auf Ihrem Gerät in YAML um. Fügen Sie JSON ein oder laden Sie es hoch, wählen Sie den Parser, für den Ihr YAML geschrieben wird, und der Konverter quotiert genau die Werte, die sonst unterwegs ihren Typ ändern würden. Jedes Ergebnis wird mit einem unabhängigen Parser zurückgelesen und mit Ihrem ursprünglichen JSON verglichen, bevor es Ihnen angeboten wird. Ungültiges JSON wird zeichengenau lokalisiert, mit Caret und einem Weg nach vorn.

• Quotierung für einen benannten Parser — Wählen Sie YAML 1.2, portabel oder alles quotieren. Portabel ist die Voreinstellung und ist unter PyYAML, js-yaml, Ruby Psych und Go sicher.
• Rückleseprüfung — Das YAML wird mit einem unabhängigen Parser erneut gelesen und Wert für Wert mit Ihrem JSON verglichen. Das Abzeichen nennt den ersten abweichenden Pfad, falls es einen gibt.
• Lesbare mehrzeilige Zeichenketten — Eine Zeichenkette mit Zeilenumbrüchen wird als Blockliteral geschrieben, damit Skripte, Zertifikate und SQL lesbar bleiben statt in Escapes zu zerfallen.
• NDJSON hinein, YAML-Stream hinaus — Ein JSON-Wert pro Zeile wird zu einem YAML-Dokument pro Eingabezeile, getrennt durch ---. Leerzeilen werden übersprungen.
• Fehler auf Ihrem Gerät lokalisiert — Meldung, Zeile, Spalte, ein Caret unter dem genauen Zeichen und was dort erwartet wurde — in jedem Browser identisch, statt das zu melden, was der Browser-Parser gerade sagt.
• Nichts verlässt Ihr Gerät — Die Datei wird lokal gelesen, geparst, konvertiert und geprüft. Es gibt keinen Upload-Schritt, also nichts, dem man widersprechen müsste.

Diese Einstellung entscheidet über die Korrektheit der Konvertierung und ist der Grund, warum es dieses Werkzeug gibt. YAML hat keine einheitliche Lesart für ein nicht quotiertes Wort: dieselbe Datei bedeutet für verschiedene Parser Verschiedenes, und ein Konverter mit minimaler Quotierung wettet darauf, welchen Sie verwenden werden.

• Portabel (Voreinstellung) — Quotiert die Vereinigung von allem, was ein YAML-1.2-Kernparser, ein YAML-1.1-Parser und ein Parser mit Zeitstempelauflösung umtypisieren würden. Etwas mehr Anführungszeichen; überall dieselben Werte.
• YAML 1.2 — Minimale Quotierung nach dem YAML-1.2-Kernschema. Korrekt, wenn — und nur wenn — der Leser ein 1.2-Parser ohne Zeitstempelauflösung ist. Das Werkzeug zählt und meldet trotzdem, welche Werte ein 1.1-Leser ändern würde.
• Alles quotieren — Jede Zeichenkette wird quotiert. Ausführlich, eindeutig und die richtige Wahl, wenn Sie nicht wissen, was die Datei liest.
• Wer liest YAML 1.1 — PyYAML und damit Ansible und SaltStack, Rubys Psych und ein langer Schweif darauf aufbauender Werkzeuge. Das ist keine Randerscheinung, sondern ein Großteil der Infrastrukturwelt.

Das sind keine exotischen Zeichenketten, sondern genau die, die Menschen in Konfigurationsdateien speichern — und jede kommt aus einem Parser, dem man nichts anderes gesagt hat, als anderer Typ zurück. Portabel quotiert sie alle; YAML 1.2 quotiert nur die erste Zeile und sagt Ihnen, wie viele der übrigen unquotiert blieben.

• true, false, null, 12, 1.5, 0x1F — Von jedem Parser umtypisiert, auch von YAML 1.2. In jedem Modus immer quotiert.
• yes, no, on, off, y, n — Zeichenketten unter YAML 1.2. Boolesche Werte unter YAML 1.1 — ein Konfigurationswert „no“ wird in Ansible also zu false.
• 0755, 0644 — Eine Dateiberechtigung — und für einen YAML-1.1-Parser eine Oktalzahl mit führender Null: aus 0755 wird 493.
• 1:30, 12:30:45 — Für Sie eine Dauer oder Uhrzeit; für einen YAML-1.1-Parser Zahlen zur Basis 60, der 1:30 als 90 liest.
• 2024-01-01 — Ein Datumsobjekt für alles mit Zeitstempelauflösung, einschließlich des Standardschemas von js-yaml, PyYAML und Gos yaml.v3.
• 1_000, 0b1010 — Nach dem Buchstaben der 1.2-Spezifikation Zeichenketten, für js-yaml Zahlen. Trotzdem quotiert, denn es zählt der Leser und nicht die Spezifikation.

Die Abbildung ist direkt und die Struktur Ihres Dokuments bleibt exakt erhalten. Nichts wird umsortiert, nichts entfällt, und kein Schlüssel wird umbenannt.

• Objekte — Eingerückte Schlüssel-Wert-Blöcke. Die Schlüsselreihenfolge bleibt erhalten, sofern Sie nicht sortierte Schlüssel wählen.
• Arrays — Listen mit Bindestrich. Eine Liste innerhalb einer Zuordnung kann eingerückt werden oder auf der Spalte des Schlüssels stehen.
• Leeres Objekt und leeres Array — Werden {} und [] geschrieben statt leer gelassen, denn ein leerer Wert wird als null zurückgelesen und würde die Struktur still verändern.
• null — Standardmäßig als null, alternativ als Tilde oder leer. Die leere Form wird nur für Zuordnungswerte verwendet — siehe die Anmerkung zum Layout weiter unten.
• Zeichenketten mit Zeilenumbrüchen — Blockliterale, deren Chomping-Indikator aus den abschließenden Zeilenumbrüchen abgeleitet wird, sodass die Zeichenkette exakt zurückkommt.
• Schlüssel — Nach denselben Regeln quotiert wie Werte. Ein Schlüssel „n“ oder „yes“ wird quotiert, denn unquotiert wird er in einem YAML-1.1-Leser zu einem booleschen Schlüssel.

Ein Shell-Skript in einer ConfigMap, ein PEM-Zertifikat, eine SQL-Anweisung — das sind die Werte, die am ehesten lesbar bleiben sollen, und die ein naiver Konverter zu einer einzigen Zeile aus Escapes verstümmelt.

• Blockliterale — Eine mehrzeilige Zeichenkette wird nach einem | geschrieben, damit Zeilen Zeilen bleiben. Der Chomping-Indikator ergibt sich aus den abschließenden Zeilenumbrüchen, sodass keiner hinzukommt oder verlorengeht.
• Wenn kein Block möglich ist — Eine Zeichenkette, deren erste Zeile leer oder eingerückt ist oder die einen Wagenrücklauf oder ein Steuerzeichen enthält, wird stattdessen quotiert. Solche Fälle brauchen einen expliziten Einzugsindikator, und ein falscher ist stille Datenkorruption.
• Lange Zeilen umbrechen (Pro) — Eine Umbruchspalte faltet lange Werte mit einem maskierten Zeilenumbruch — die einzige Umbruchform in YAML, die exakt umkehrbar ist. Gefaltete einfache und gefaltete Block-Skalare sind es nicht, deshalb wird ein umzubrechender Wert zuerst quotiert.
• Kein unbeabsichtigtes Falten — Ohne Umbruch — die Voreinstellung — bleiben lange Zeichenketten in einer Zeile, sodass nichts neu umbrochen wird.

NDJSON — auch JSON Lines genannt — ist ein JSON-Wert pro Zeile und das, was Log-Pipelines, Datenbankexporte und jq -c erzeugen. Als Gesamtdatei ist es kein gültiges JSON, weshalb die meisten Konverter es ablehnen.

• Auf zwei Wegen erkannt — An einer Endung .ndjson oder .jsonl und am Inhalt: eine Datei, die kein einzelnes gültiges JSON-Dokument ist, deren nicht leere Zeilen aber jede für sich parsen.
• Ein Dokument pro Datensatz — Jeder Wert wird zu einem eigenen YAML-Dokument, getrennt durch ---, so wie jeder Parser einen YAML-Stream liest.
• Ein einzeiliges Array ist kein NDJSON — [1,2] ist ein gültiges JSON-Dokument und wird als eines konvertiert. Genau dafür wird die Einzeldokument-Lesart zuerst versucht.
• Eine fehlerhafte Zeile stoppt die Konvertierung — Die Zeilennummer wird gemeldet, statt einen teilweise konvertierten Stream mit still verworfenen Datensätzen zu erzeugen.

Keine dieser Einstellungen ändert die Bedeutung des Dokuments. Alle ändern, wie es sich liest, und die Vorschau aktualisiert sich bei jeder Bewegung.

• Einzug — 1 bis 8 Leerzeichen pro Ebene. Zwei ist die Voreinstellung und das, was die meisten YAML-Werkzeuge erwarten.
• Null-Stil — null, eine Tilde oder leer. Die leere Form gilt nur für Zuordnungswerte: ein leerer Listeneintrag am Ende einer verschachtelten Liste wird von verschiedenen Parsern unterschiedlich gelesen und wird dort als Tilde geschrieben.
• Dokumentmarkierung — Die Datei mit --- beginnen. Zwischen Dokumenten eines Streams wird sie unabhängig davon immer gesetzt.
• Schlüssel sortieren (Pro) — Alphabetische Schlüssel für Diffs, die sich nicht bewegen, wenn ein Erzeuger seine Ausgabe umsortiert.
• Anführungsstil (Pro) — Einfache oder doppelte Anführungszeichen, wo quotiert werden muss. Einfache weichen auf doppelte aus, wenn sie eine Zeichenkette nicht darstellen können.
• Listeneinzug (Pro) — Eine Liste unter ihrem Schlüssel einrücken oder auf dessen Spalte setzen — der Hausstil von Kubernetes-Manifesten und vier Spalten weniger pro Liste.
• Mehrzeiliger Stil (Pro) — Lesbare Blockliterale oder eine einzelne maskierte, doppelt quotierte Zeile.

Jeder andere Konverter dieser Kategorie gibt Ihnen YAML und überlässt es Ihnen, später herauszufinden, ob es noch dasselbe bedeutet wie Ihr JSON. Dieser prüft es, bevor Sie etwas herunterladen.

• Ein unabhängiger Leser — Das Ergebnis wird von einer anderen Implementierung geparst als der, die es geschrieben hat. Ein Schreiber, den sein eigener Leser prüft, beweist nichts — beide teilten jedes Missverständnis.
• Wert für Wert verglichen — Gegen Ihr ursprüngliches JSON, nicht gegen eine neu serialisierte Kopie davon. Verglichen werden auch die Typen, sodass eine als Datum zurückkommende Zeichenkette durchfällt.
• Der erste Unterschied wird benannt — Per Pfad — /servers/3/started — mit beiden Typen und beiden Werten, statt eines nackten „Prüfung fehlgeschlagen“ auf einer Datei mit 40.000 Zeilen.
• Gegen den gewählten Parser gelesen — Die Prüfung verwendet das Schema Ihres Ziels, sodass „geprüft“ immer heißt: geprüft für den Leser, für den Sie schreiben wollten.
• Abschaltbar — Sie kostet ein zweites Lesen des Dokuments. Bei einer großen Datei bekannter Form wollen Sie das vielleicht nicht; die Einstellung gehört Ihnen, und das Ergebnis wird als veraltet markiert, wenn Sie sie ändern.

Angetrieben von optimierten Verarbeitungsalgorithmen.

YAML ist das Konfigurationsformat der Infrastrukturwelt, und JSON ist das, was fast alles ausgibt. Die Umwandlung zwischen beiden ist der Weg, auf dem Daten aus einer API, einer Datenbank oder einer Anwendung in einem Kubernetes-Manifest, einer Compose-Datei, einem GitHub-Actions-Workflow oder einem Ansible-Playbook landen.

• Konfigurations-Workflows — JSON-förmige Daten in Kubernetes, Docker Compose, GitHub Actions, Ansible und allem anderen weiterverwenden, das YAML liest.
• Lesbarkeit — YAML lässt Klammern und Anführungszeichen weg, sodass ein verschachteltes Dokument leichter zu lesen und im Pull Request zu prüfen ist.
• Kommentare — YAML unterstützt Kommentare, JSON nicht — die Umwandlung ist deshalb oft der erste Schritt, um generierte Daten in etwas zu verwandeln, das ein Mensch pflegt.
• Korrektheit zählt hier mehr — Eine Konfigurationsdatei wird ausgeführt. Eine Versionsangabe, die zur Zahl wird, oder eine Berechtigung, die oktal wird, scheitert nicht laut — sie wird deployt.
• Datenschutz — Nichts wird hochgeladen, also verlässt eine API-Antwort mit Zugangsdaten oder Kundendaten nie den Rechner, auf dem sie geöffnet wurde.

• YAML zu JSON
• JSON-Formatierer
• JSON-Validator
• JSON-Minifizierer
• JSON zu XML
• JSON-Viewer