YAML und JSON beschreiben dieselben Formen — Zuordnungen, Listen und Skalare — die Umwandlung dazwischen ist also überwiegend ein Wechsel der Notation. Die Richtung wird aus dem Eingefügten erkannt, oder Sie legen sie fest. Die Einrückung der YAML-Seite bestimmen Sie, und die Schlüssel lassen sich alphabetisch sortieren, was sich lohnt, wenn die Ausgabe in die Versionsverwaltung geht und Sie einen lesbaren Diff wollen.
Die Umwandlung ist nicht immer symmetrisch, und das Werkzeug sagt es, statt es Sie später herausfinden zu lassen: YAML kennt Typen, die JSON nicht hat, und alles, was nicht übersteht, wird mit seinem Pfad gemeldet. Datumsangaben werden zu Zeichenketten, Unendlichkeiten zu null, und Anker und Aliase — YAMLs Art, einen Block wiederzuverwenden — werden zu Kopien aufgelöst, sofern Sie sie nicht behalten, denn JSON kennt kein Gegenstück.
Was den Hin- und Rückweg nicht übersteht
-
Kommentare gehen immer verloren:
JSON hat keine Kommentarsyntax, die Kommentare einer YAML-Datei können also nicht zurückkommen. Das ist der übliche Grund, warum eine hin und zurück umgewandelte Konfiguration schlechter dasteht als zuvor.
-
Anker und Aliase werden aufgelöst:
Ein an drei Stellen wiederverwendeter Block wird zu drei Kopien. Die Daten sind identisch, die Datei länger, und die eine gemeinsame Definition ist dahin.
-
YAMLs Wahrheitswerte ohne Anführungszeichen führen in die Irre:
Wörter wie yes, no, on und off lesen ältere YAML-Parser als Wahrheitswerte. Setzen Sie sie in Anführungszeichen, wenn sie als Wörter gemeint sind — das Norwegen-Problem, bei dem der Ländercode NO zu false wurde.
-
In YAML ist die Einrückung die Struktur:
Anders als bei JSONs Klammern ist die Verschachtelung der Leerraum. Eine mit der falschen Einrückungseinstellung umgewandelte Datei ist gültig und bedeutet etwas anderes.
Same shapes, different notation, not always symmetric
YAML and JSON both describe maps, lists and scalars, so most of what the [msm_tool slug="yaml-json-converter"] does is a change of notation rather than a change of meaning. The conversion is not perfectly symmetrical in both directions, though, and rather than letting that surface later as a surprise, anything that cannot survive the trip is reported by its path at the time it happens.
Comments never come back
JSON has no comment syntax at all, so a YAML file's comments have nowhere to go once converted — this is the ordinary reason a configuration file converted to JSON and back reads worse than it started, even though the data itself is unchanged.
Anchors and aliases expand into copies
YAML's mechanism for reusing a block in several places has no equivalent in JSON, so a block referenced three times becomes three separate copies in the output. The data itself is identical either way; what is lost is the single shared definition, along with the fact that editing one instance no longer updates the rest.
The Norway problem
Bare words such as `yes`, `no`, `on` and `off` are read as booleans by YAML, which is how a country code of `NO` becomes the boolean `false` rather than the two letters intended — a well-known enough trap to have its own name. Quoting a value that is meant to stay text, rather than leaving it bare, is what avoids it.
Indentation is structure, not decoration
Where JSON uses braces to mark nesting, YAML uses whitespace itself, so a file converted with the wrong indentation setting is still perfectly valid YAML — it simply means something different from what was intended. That makes indentation a semantic choice here, not a cosmetic one.
Choosing a format for configuration
YAML suits configuration that people actually edit by hand, since comments and readability are exactly what it offers over JSON. JSON is the better choice wherever a machine produces and consumes the file, since it has fewer surprises and nothing YAML-specific to trip over — dates becoming strings and infinities becoming null in the conversion are both reported rather than silently applied either way.