Entwicklertools · Syntaxkonverter
Ist JSON gültig YAML? Was YAML 1.2 verspricht und wo es bricht
· Hintergrund
json yaml Datenformate
YAML 1.2 wurde so konzipiert, dass jedes JSON-Dokument auch ein YAML-Dokument ist, weshalb sich die Konvertierung von JSON in YAML trivial anfühlt. In diesem Beitrag wird erläutert, was die Spezifikation tatsächlich garantiert und in welchen Grenzfällen das Versprechen versagt.
JSON in eine YAML-Datei einfügen und damit durchkommen – warum das funktioniert und das eine Mal nicht
Ein gewöhnliches JSON-Objekt kann in die Quellseite YAML eingefügt und unter dem Schema YAML 1.2 JSON von ToolAcre gelesen werden. Klammern, Klammern, Schlüssel in Anführungszeichen, Zeichenfolgen, Zahlen, boolesche Werte und Null werden zum gleichen einfachen JavaScript-Wert. Das erklärt, warum sich die Grenze oft trivial anfühlt.
Die Garantie sollte Parser-spezifisch bleiben. ToolAcre schränkt Tags ein, begrenzt Aliase und Verschachtelungen und wendet eine Eingabebeschränkung an. Ein Text kann unter einem breiteren YAML-Prozessor gültig sein, hier jedoch aus Sicherheits- oder Formgründen abgelehnt werden, die nichts mit seinem JSON-ähnlichen Kern zu tun haben.
Gewöhnliches JSON wird über diesen YAML 1.2-Leser geladen; Nicht unterstützte Erweiterungen schlagen aus unterschiedlichen Gründen fehl
Die ausgewählten Schemata erzeugen JSON-förmige Werte: Zeichenfolgen, Zahlen, Boolesche Werte, Nullen, Arrays und Zuordnungen. Diese Ausrichtung ermöglicht das Analysieren und anschließende Serialisieren anstelle des Ersetzens von Satzzeichen. Der Quellcode legt nicht jeden Wortlaut oder Erratum der YAML-Spezifikation fest, daher berichtet der Artikel über getestetes Verhalten, anstatt eine erschöpfende Konformität zu beanspruchen.
Im strikten Modus bleiben Tilde, leerer Wert und `0o755` Zeichenfolgen. Das sind YAML-Tokens, die JSON selbst nicht enthalten würde. Core löst sie unterschiedlich auf und gibt dennoch eine JSON-förmige Ausgabe zurück.
Die ausgelieferten Schemata richten sich nach JSON-förmigen Daten, ohne dass jede Spezifikationsgrenze nachgewiesen werden muss
Doppelte YAML-Zuordnungsschlüssel behalten den letzten Wert mit einer Warnung; Eine strenge Auslegung an anderer Stelle könnte sie ablehnen. Ältere YAML 1.1-Leser können Wörter wie `NO` anders eingeben, während dieser Reader sie als Zeichenfolgen behält. Diese Unterschiede erschweren umfassende Aussagen zur Portabilität.
Tabulatoren, die als Einrückung verwendet werden, führen zu einem Fehler, wohingegen Tabulatoren in zitierten JSON-Strings maskiert werden. Sehr tiefe oder übergroße Werte können lokale Sicherheitsobergrenzen erreichen. Eine theoretische Sprachbeziehung setzt Implementierungsgrenzen nicht außer Kraft.
Doppelte Schlüssel und Unterschiede zwischen Legacy-Parsern bleiben Interoperabilitätsgrenzen
Das Gegenteil ist für diese Wertepipeline eindeutig falsch. YAML-Kommentare haben keine JSON-Darstellung, Aliase werden in wiederholte Daten aufgelöst, Multi-Dokument-Streams werden zu Arrays und nicht unterstützte Tags werden abgelehnt. Blockskalare werden zu Strings, ihre Darstellung geht jedoch verloren.
Sogar ein unterstütztes YAML-Dokument kann daher in einen gültigen JSON konvertiert werden und kehrt nie zum gleichen YAML-Text zurück. Die Datengleichheit kann für gewöhnliche Werte bestehen bleiben, während dies bei Kommentaren, Ankern, Rechtschreibung und Stream-Identität nicht der Fall ist.
Was dies für die Konvertierung bedeutet: JSON zu YAML ist eine Stiländerung, YAML zu JSON ist eine Übersetzung, bei der Informationen verloren gehen können
JSON-to-YAML ist normalerweise eine Stil- und Serialisierungsänderung für JSON-förmige Eingaben. YAML-to-JSON interpretiert zunächst die YAML-spezifische Syntax und projiziert dann das Ergebnis in das kleinere Wertemodell von JSON. Die Richtungen sind nicht symmetrisch.
ToolAcre testet gewöhnliche JSON-to-YAML-to-JSON-Dokumente, die verschachtelte Werte, Unicode, Nullen, Arrays und mehrdeutig aussehende Zeichenfolgen enthalten. Diese Fixtures beweisen die abgedeckte Datenklasse, nicht jedes mögliche JSON- oder YAML-Prozessorpaar.
Arbeitsbeispiel: ein JSON-Dokument, das als YAML geladen wurde – dieselbe Struktur, dann eine nur YAML-Funktion hinzugefügt, um anzuzeigen, wo die JSON-Werkzeuge aufhören
Fügen Sie `{"country":"NO","items":[1,null],"nested":{"ok":true}}` als YAML-Eingabe ein. Der strikte Leser gibt denselben Baum zurück. Fügen Sie einen YAML-Kommentar hinzu und der Wert bleibt gleich, während der Kommentar verschwindet. Ersetzen Sie ein wiederholtes Objekt durch einen Anker und einen Alias. Das JSON enthält jetzt Kopien statt Referenzsyntax.
`---` und ein zweites Dokument hinzufügen; Das Ergebnis wird zu einem Array von Dokumenten mit einer Warnung. `!!binary` hinzufügen; der eingeschränkte Leser lehnt es ab. Jeder Schritt markiert eine eindeutige Grenze: ignorierte Darstellung, aufgelöste Struktur, Stream-Konvention und nicht unterstützter Typ.
Was dies nicht abdeckt – Kompatibilität auf Schemaebene, wobei YAML-Typen wie Zeitstempel kein JSON-Gegenstück haben
Bei der Schemakompatibilität geht es nicht nur um die Oberflächensyntax. Core kann Infinity oder NaN erstellen, die JSON mit Warnungen als Null schreibt. Zeitstempel und binäre Tags werden in den eingeschränkten Schemata abgelehnt und nicht konvertiert. ToolAcre schränkt YAML bewusst auf sichere JSON-förmige Daten ein.
Eine andere YAML-Implementierung unterstützt möglicherweise zusätzliche Typen. Das macht es an diesen Punkten weniger kompatibel mit einfachen JSON-Werten, nicht automatisch besser oder schlechter. Wählen Sie basierend auf dem Zielvertrag und den Sicherheitsanforderungen.
Die Kompatibilität auf Schemaebene umfasst nicht endliche Werte und zeitliche Tags, die dieser eingeschränkte Reader einschränkt oder ablehnt
Gewöhnliche JSON-förmige Daten passieren sauber diesen YAML 1.2 Leser und Schreiber. Umfassendere Ansprüche an alle Dokumente oder Parser erfordern Vorrichtungen, die doppelte Schlüssel, Schemaversionen, Tags und Ressourcengrenzen abdecken.
Verwenden Sie Syntaxkonverter, um den tatsächlichen Text zu testen und seine Warnungen zu lesen. Behandeln Sie „JSON ist YAML“ erst dann als nützliche Abkürzung, nachdem Sie den Parser, das Schema und die nicht unterstützten Funktionen benannt haben, die die tatsächliche Grenze präzise machen.
Behalten Sie für einen Portabilitätstest ein Gerät vollständig im Wertemodell von JSON und ein anderes, das jeweils nur eine YAML-Funktion hinzufügt. Führen Sie beide über jeden vorgesehenen Verbraucher aus. Der erste misst den praktischen Teilmengenanspruch; Die zweite identifiziert genau, wo Kommentare, Aliase, Streams, Tags oder Skalarregeln voneinander abweichen. Diese abgestufte Methode ist informativer als die abstrakte Frage, ob zwei Sprachen Teilmengen sind, da sie Fehler erzeugt, die mit den Parsern zusammenhängen, die Ihr System tatsächlich verwendet.