Entwicklertools · Syntaxkonverter
YAML bis JSON Typzwang: wie Ja, Nein und 0777 die Bedeutung ändern
· Wie es funktioniert
yaml json Datenformate
YAML löst Skalare ohne Anführungszeichen in Typen auf, und die Regeln unterscheiden sich zwischen YAML 1.1 und 1.2. Dieser Beitrag zeigt genau, wie ein Konverter entscheidet, ob ein Wert ein boolescher Wert, eine Ganzzahl, eine Gleitkommazahl oder ein String ist, und wie er das Ergebnis steuert.
Der Wert, der als wahr zurückgegeben wurde – ein einfacher YAML-Skalar, gedacht als Text, konvertiert in JSON als boolescher Wert, und der Dienst, der sich dann schlecht verhielt
Ein Wert wie `NO` kann in einem YAML 1.1-Loader falsch werden, aber das ist nicht das, was dieser Konverter liefert. Beide ToolAcre-Auswahlmöglichkeiten verwenden die Schemata YAML 1.2, daher bleiben `NO`, `yes`, `no`, `on` und `off` Zeichenfolgen. Die korrigierte Eröffnung ist wichtig, da ein Beispiel, das besagt, dass dieses Panel `NO` in wahr oder falsch umwandelt, das Gegenteil seines getesteten Verhaltens lehren würde.
Es gibt noch Typüberraschungen. Unter dem Standardschema JSON ist `null` null, während `~`, ein leerer Wert, und `0o755` Zeichenfolgen bleiben. Durch Auswahl von Core werden diese drei Formen in null, null und 493 geändert. Die Ausgabe ist gerade deshalb nützlich, weil sie den aufgelösten JavaScript-Wert offenlegt, anstatt so zu tun, als ob jedes einfache YAML-Token einen offensichtlichen Typ trägt.
Der Wert, der unter YAML 1.2 verblieben ist
Implizite Auflösung erfolgt, während js-yaml die Quelle liest. Das ausgewählte eingeschränkte Schema entscheidet, ob ein einfacher Skalar mit einer Null-, Booleschen oder numerischen Form übereinstimmt, bevor der Konverter JSON schreibt. Das Zitieren umgeht diese Entscheidung: `"0o755"` ist Text in beiden Schemata, und ein Blockskalar bleibt ein String, einschließlich der Zeilenumbrüche, die durch seinen Chomping-Indikator dargestellt werden.
Dies ist eine Analyse und Serialisierung, kein Ersatz durch reguläre Ausdrücke. Der Reader erstellt Zeichenfolgen, Zahlen, Boolesche Werte, Nullen, Arrays und Objekte. `JSON.stringify` gibt diese Werte dann mit der ausgewählten Einrückung aus. Kommentare und Token-Schreibweise sind bereits beim Schreiben verschwunden, sodass kein Serialisierer rekonstruieren kann, ob eine Zahl ursprünglich dezimal war oder in einer anderen akzeptierten YAML-Notation geschrieben wurde.
Die YAML 1.1-Regeln – „yes/no/on/off boolesche Werte“, 0777 als Oktalwert, 1:30 als Sexagesimalwert und Versionszeichenfolgen wie 1.10, die als Gleitkommazahlen gelesen werden
Die Gliederung listet YAML 1.1 Zwänge wie Sexagesimalzeit und Legacy-Oktal auf. Es handelt sich um relevante Kompatibilitätsrisiken, es handelt sich jedoch nicht um hier verfügbare Modi. ToolAcre bietet absichtlich kein 1.1-Schema an. Die Benutzeroberfläche besagt, dass keine der mitgelieferten Optionen `NO` als falsch liest, und Tests pinnen diesen Ländercode und die Wörter „Ja“, „Nein“, „Ein“ und „Aus“ als Zeichenfolgen an.
Diese Grenze ändert die Debugging-Methode. Wenn eine andere Anwendung diese Wörter in boolesche Werte umwandelt, vergleichen Sie ihre Parserkonfiguration mit ToolAcre, anstatt eine identische Ausgabe zu erwarten. Der Konverter kann zeigen, was seine eigenen beiden Schemata erzeugen; Es kann das Schema oder die Version nicht zertifizieren, die von einem CI-Runner, Framework oder Bereitstellungssystem verwendet werden, das die Datei später nutzt.
YAML 1.1 Zwänge sind Gefahren, die dieser Konverter vermeidet
Das Standardschema JSON akzeptiert nur skalare Schreibweisen, die mit dem Modell von JSON kompatibel sind. Core fügt die bekannten YAML-Nullformen, hexadezimale und oktale Ganzzahlen, Unendlichkeit und NaN hinzu. Der Kern bleibt immer noch in einem eingeschränkten Ladeprogramm: sprachspezifische Objekt-Tags, Datumsangaben, Mengen, geordnete Karten und binäre Tags werden abgelehnt und nicht erstellt.
Infinity und NaN offenbaren eine weitere Grenze. JavaScript kann sie speichern, aber JSON kann sie nicht schreiben. Der Konverter identifiziert jeden Pfad und warnt, dass der Wert null wird. Das ist ein zugegebenermaßen verlustbehafteter Schritt, keine verlustfreie Konvertierung. Ein in Anführungszeichen gesetztes `.inf` vermeidet dies, da der Wert dann die Literalzeichenfolge `.inf` bleibt.
Die beiden ausgelieferten YAML 1.2-Schemata unterscheiden sich nur in dokumentierten Skalarformen
Fügen Sie `tilde: ~`, `empty:`, `octal: 0o755`, `country: NO` und `answer: yes` ein. Wenn „strikt“ ausgewählt ist, sind die JSON-Werte `"~"`, `""`, `"0o755"`, `"NO"` und `"yes"`. Wenn Core ausgewählt ist, ändern sich nur die ersten drei: Tilde und Leer werden zu Null und Oktal wird zu 493. Land und Antwort bleiben in beiden Ausgaben Text.
Zitieren Sie nun jeden Wert und wiederholen Sie den Vorgang. Beide Schemas geben Zeichenfolgen zurück, da die Quelle den beabsichtigten Typ angibt. Dieser Vergleich ist codegenau und nützlicher als der Vergleich von YAML 1.1 mit 1.2 in einem Tool, das 1.1 nie lädt. Es bietet auch eine überprüfbare Möglichkeit, einen anderen Parser zu überprüfen, ohne allein anhand seiner Dokumentation raten zu müssen.
Bearbeitetes Beispiel: eine Datei unter den Schemata Strict und Core von ToolAcre
Explizite Standard-Tags werden nur akzeptiert, wenn das eingeschränkte Schema sie erkennt: `!!str 123` wird zur Zeichenfolge `123`, während `!!int "7"` zur Zahl 7 wird. Tags wie `!!binary`, `!!timestamp`, `!!set`, `!!js/function` und Python-Objektkonstruktoren werden abgelehnt. Dadurch wird verhindert, dass der YAML-Reader zu einer Factory für beliebige Objekte wird.
Quoting bleibt die tragbare Wahl, wenn ein Konfigurationswert lediglich getippt aussieht. Es behält führende Nullen, Versionsschreibweise und Sentinel-Wörter bei, ohne dass ein explizites Tag von einem anderen Tool überlebt wird. Das Ergebnis JSON zeigt den ausgewählten Typ, kann jedoch nicht den Anführungszeichenstil oder das Tag enthalten, das diesen Wert erzeugt hat.
Was dies nicht abdeckt – Parsen des resultierenden JSON auf Anwendungsebene, wodurch möglicherweise erneut Typen erzwungen werden (z. B. Zeichenfolge „1“ in Zahl)
Anwendungscode kann das resultierende JSON erneut erzwingen. Eine API kann `"1"` lesen und in eine Zahl umwandeln oder sie anhand eines Schemas ablehnen. Syntaxkonverter stoppt, nachdem JSON Text erzeugt wurde; Es führt keinen Framework-Validator, keinen Lader für Umgebungsvariablen und keine Geschäftsregel aus. Eine saubere Konvertierung beweist daher Syntax und Zuordnung, nicht die Akzeptanz durch den endgültigen Dienst.
Doppelte YAML-Schlüssel sind ein separates Problem. ToolAcre behält den letzten Wert und meldet den wiederholten Schlüssel mit einer Position. Multi-Dokument-Streams werden zu Arrays. Diese Entscheidungen können das, was eine Anwendung sieht, auch dann ändern, wenn jeder Skalartyp erwartet wird. Lesen Sie daher Warnungen, anstatt nur den formatierten JSON-Körper zu beurteilen.
Takeaway: Zitieren Sie alles, was eine Maschine möglicherweise falsch liest – und wie die Konvertierung von YAML in JSON im Browser genau zeigt, in was jeder Skalar aufgelöst wurde
Zitieren Sie Text, der einem Maschinen-Token ähnelt, und überprüfen Sie dann die Typen JSON. Verwenden Sie strict, wenn Sie das kleinste JSON-förmige Skalarvokabular wünschen; Wählen Sie Core bewusst, wenn YAML Null- und numerische Formen erforderlich sind. Keine der Optionen ist YAML 1.1 und keine davon führt dazu, dass ein nachgeschalteter Verbraucher dieselben Regeln befolgt.
Das Panel macht seine Parser-Auswahl sichtbar und gibt Warnungen für Werte zurück, die kein Ziel darstellen kann. Das ist das ehrliche Versprechen: Es zeigt, wie diese Implementierung jeden Skalar aufgelöst hat. Es wird kein universelles YAML-Verhalten beansprucht oder Kommentare, Tags und Rechtschreibung während eines Roundtrips beibehalten.