Konvertiertes Ergebnis wird hier angezeigt...
Konvertieren Sie zwischen YAML- und JSON-Formaten mit Syntax-Hervorhebung.
Das Tool ist eine Zwei-Wege-Brücke zwischen YAML und JSON. YAML zu JSON schickt den Text durch load von js-yaml und dann durch JSON.stringify mit Zwei-Leerzeichen-Einrückung. JSON zu YAML führt JSON.parse und dann dump von js-yaml aus, ebenfalls mit Zwei-Leerzeichen-Einrückung. Alles geschieht im Browser-Tab; die Seite braucht nach dem Laden keinen Netzwerkaufruf. Syntaxfehler werden mit Zeilennummer gemeldet, sodass eine Meldung wie „at line 4“ direkt auf die fehlerhafte Einrückung oder das Zeichen zeigt. Der Bereich bietet außerdem Kopieren und Herunterladen, damit Sie das Ergebnis in eine Datei übernehmen können.
YAML-Skalare sind untypisierter Text, und der Parser entscheidet im Nachhinein, ob jeder einzelne ein String, eine Zahl, ein Boolean, null oder ein Zeitstempel ist. Dieses Raten ist der Ausgangspunkt der meisten Konvertierungsfehler, weil dieselben Zeichen in verschiedenen Parsern zu unterschiedlichen Typen werden können.
| Sie schreiben | Hier geparst als | Überraschung |
|---|---|---|
version: 1.10 | Zahl 1.1 | Nachfolgende Null verloren |
zip: 01234 | Zahl 1234 | Führende Null verloren |
country: NO | String "NO" | YAML-1.1-Parser läsen false (das Norwegen-Problem) |
enabled: yes | String "yes" | YAML-1.1-Parser läsen true |
flag: True | Boolean true | Groß-/Kleinschreibung ist bei true und false egal |
count: 1e3 | Zahl 1000 | Wissenschaftliche Notation ist eine Zahl |
id: 12345678901234567890 | gerundete Zahl | Präzision oberhalb von 2^53 verloren |
big: .inf | Infinity, dann null | JSON kann es nicht ausdrücken |
Die Lehre ist nicht, dass YAML kaputt ist, sondern dass unquotierte Skalare Bedeutung tragen. Das Norwegen-Problem ist das kanonische Beispiel: Ein Ländercode als NO ist für einen YAML-1.2-Parser ein String und für einen YAML-1.1-Parser der Boolean false. Wenn zwei Systeme sich über das Schema uneinig sind, ändern sich die Daten stillschweigend in ihrer Bedeutung.
Betrachten Sie diese Eingabe:
service: checkout
version: 1.10
retries: 3
enabled: yes
region: NO
Die JSON-Ausgabe ist:
{
"service": "checkout",
"version": 1.1,
"retries": 3,
"enabled": "yes",
"region": "NO"
}
Zwei Dinge gingen stillschweigend schief. Die Version verlor ihre nachfolgende Null, und enabled und region sind Strings, die jeder Leser der Datei für einen Boolean und einen Ländercode halten würde. Die korrigierte YAML quotiert die mehrdeutigen Werte:
service: checkout
version: "1.10"
retries: 3
enabled: "yes"
region: "NO"
Jetzt kann kein Parser sie mehr umdeuten.
Quotieren ist das wichtigste Mittel. Doppelte Anführungszeichen sind am portabelsten; einfache funktionieren ebenfalls und sind das, was der YAML-Dumper ausgibt, wenn er einen String schützen muss. Sie können auch explizit mit einem Tag arbeiten, etwa version: !!str 1.10. Bei der Umwandlung von JSON zurück nach YAML erledigt der Dumper diese Arbeit für Sie: Ein JSON-String "yes" wird als 'yes' geschrieben und ein String "1.10" als '1.10', genau damit das erneute Lesen der YAML sie nicht in einen Boolean oder eine Zahl verwandelt. Deshalb erhält eine Runde JSON → YAML → JSON String-Werte korrekt.
----Trenner erzeugt einen Fehler; konvertieren Sie Abschnitte getrennt.Die beiden Formate überschneiden sich stark, die Wahl dreht sich also meist darum, wer die Datei bearbeitet und wie streng der Konsument ist. YAML lässt sich angenehm von Hand schreiben: Es unterstützt Kommentare, lässt die meisten Klammern weg und behandelt mehrzeilige Strings mit Block-Skalaren. Der Preis ist die Einrückungsempfindlichkeit und das oben beschriebene Typ-Raten. JSON ist eindeutig und wird von nahezu jeder Sprache und API unterstützt, hat aber keine Kommentare, verlangt quotierte Schlüssel und lehnt nachfolgende Kommas ab.
| Situation | Bessere Wahl |
|---|---|
| Handbearbeitete Konfiguration mit Kommentaren | YAML, mit Anführungszeichen um mehrdeutige Strings |
| API-Request- oder -Response-Body | JSON |
| Daten über Sprachgrenzen hinweg | JSON, weil seine Typen fest sind |
| Konfiguration für ein YAML-1.1-Tool | YAML, aber alles quotieren, was ein Boolean sein könnte |
| Werte, die führende Nullen oder nachfolgende Dezimalstellen behalten müssen | Beides, aber die Werte quotieren |
Eine praktische Regel: Verwenden Sie YAML dort, wo Menschen schreiben und prüfen, JSON dort, wo Maschinen austauschen, und quotieren Sie jeden String, den ein Parser für eine Zahl oder einen Boolean halten könnte.
Ein zweites Praxisbeispiel zeigt, wie der Dumper Strings auf dem Rückweg von JSON schützt. Nehmen Sie diese Eingabe:
{"name":"web","replicas":3,"enabled":true,"version":"1.10","labels":["prod","eu"]}
Die YAML-Ausgabe ist:
name: web
replicas: 3
enabled: true
version: '1.10'
labels:
- prod
- eu
Drei Details sind bemerkenswert. Die Zahl 3 wird nackt geschrieben, weil sie eine echte Zahl ist, während true nackt geschrieben wird, weil es ein echter Boolean ist. Der String "1.10" wird als '1.10' mit Anführungszeichen geschrieben, weil der Dumper weiß, dass ein unquotiertes 1.10 als Zahl 1.1 zurückkäme. Das Array wird zu einer eingerückten Blockliste statt zur Klammernotation, was der Standardstil des Dumpers ist. Die Einrückung beträgt durchgehend zwei Leerzeichen.
YAML hat keinen expliziten Zahlentyp, also rät der Parser. Das Skalar 1.10 sieht wie eine Gleitkommazahl aus, und beim Parsen in eine JavaScript-Zahl ist die nachfolgende Null nicht signifikant, sodass 1.10 und 1.1 denselben Wert ergeben. Die JSON-Ausgabe schreibt dann 1.1. Muss die Version als Text erhalten bleiben, quotieren Sie sie in der Quelle: version: "1.10". Das Quotieren weist den Parser an, die Zeichen als String zu behandeln, und der Wert übersteht die Runde unverändert.
Hier nicht. Dieser Konverter verwendet das Standard-Core-Schema von js-yaml, in dem nur true und false (in beliebiger Groß-/Kleinschreibung) Booleans sind; NO wird also als String "NO" gelesen und geschrieben. Das berühmte Norwegen-Problem gehört zu YAML-1.1-Parsern wie manchen Versionen von PyYAML, die unquotierte NO, yes, on und off als Booleans lesen. Weil dieselbe Datei in verschiedenen Tools Verschiedenes bedeuten kann, ist es sichere Gewohnheit, jeden String zu quotieren, der für einen Boolean gehalten werden könnte.
JSON kennt keine Kommentarsyntax, Kommentare können in der JSON-Ausgabe also nicht dargestellt werden und gehen beim Laden der YAML verloren. Ist die Erhaltung der Kommentare wichtig, behalten Sie die ursprüngliche YAML-Datei und behandeln Sie das JSON als abgeleitetes Artefakt. Eine Rückumwandlung von JSON nach YAML stellt sie nicht wieder her, weil die Information nie in den geparsten Daten gespeichert wurde.
Nein. Der Konverter lädt ein einzelnes Dokument, und ein YAML-Stream mit mehr als einem Top-Level-Dokument wird mit einem Fehler für ein erwartetes einzelnes Dokument abgelehnt. Teilen Sie die Datei an jedem --- Trenner und konvertieren Sie die Abschnitte einzeln, oder verwenden Sie ein Skript, das einen Multi-Dokument-Loader aufruft.
Nein, nicht jenseits des sicheren Ganzzahlbereichs von JavaScript, also 2^53 − 1. Ein Wert wie 12345678901234567890 wird in ein Double geparst, das ihn nur näherungsweise darstellen kann, und die JSON-Ausgabe zeigt die gerundete Zahl. Muss ein Bezeichner wie eine lange Kontonummer oder eine Snowflake-ID erhalten bleiben, setzen Sie ihn in Anführungszeichen, damit der Parser ihn als String behandelt.
YAML kann positive Unendlichkeit, negative Unendlichkeit und Not-a-Number darstellen, und der Parser lädt sie als JavaScript Infinity und NaN. JSON kann diese Werte nicht schreiben, daher gibt der Serialisierer null aus. Sind diese Werte wichtig, behalten Sie die Daten in YAML oder ersetzen Sie sie vor dem Serialisieren durch einen Sentinel-String.
Geprüft vom HandyTools-Hub-Team · Zuletzt aktualisiert