Zum Hauptinhalt springen

JSON zu TOML

Dieser Konverter erzeugt TOML 1.0 aus JSON vollständig in Ihrem Browser. Skalare Schlüssel werden zuerst geschrieben, dann [tables], dann [[arrays of tables]], sodass jede Definition den Headlines vorangeht, die sie vorangehen müssen. TOML-inkompatible Schlüssel werden markiert, null-Werte werden mit einem benannten Pfad abgelehnt, und ein top-level Array kann nicht konvertiert werden – TOML hat keinen anonymen Root.

Nur lokal

JSON zu TOML erklärt

Die Richtung ist wichtig: JSON entsteht normalerweise in einem Programm – eine API-Nutzlast, ein gespeichertes Dokument, der Zustand eines Build-Tools – während TOML normalerweise von einem Menschen gelesen wird, der etwas konfiguriert. Das Konvertieren von JSON zu TOML bedeutet also, in ein Format mit echten Platzierungsregeln einzutreten, und die größte ist unsichtbar, bis sie zuschlägt: In TOML entscheidet die Position eines Schlüssels in der Datei, zu welcher Tabelle er gehört. Schreiben Sie retries = 3 nach einer [servers]-Headline und es wird still zu einem Schlüssel von servers, nicht des Roots.

Dieser Konverter gibt zuerst skalare Schlüssel aus, dann [tables], dann [[arrays of tables]], sodass jedes Schlüssel/Wert-Paar unter der Headline geschrieben wird, zu der es gehört, und jede Tabelle vollständig definiert ist, bevor die nächste Headline beginnt. JSON-Objekte werden zu Tabellen, Arrays von Objekten werden zu Arrays von Tabellen, Arrays von Skalaren bleiben Inline-Arrays, und jeder Wert wird als der TOML-1.0-Typ ausgegeben, der er bereits ist – es gibt keinen Inferenzschritt, der falsch sein könnte.

Alles geschieht in diesem Browser-Tab. Das JSON, das Sie einfügen, wird mit dem JSON.parse des Browsers selbst geparst, das TOML wird aus diesem Dokument im Speicher erstellt, und nichts überschreitet das Netzwerk – das Network-Panel in DevTools bleibt leer, während Sie arbeiten, und die Content-Security-Policy der Seite sorgt dafür.

Die umgekehrte Richtung ist die häufigere – ein Cargo.toml in ein Script einlesen – und die TOML zurück zu JSON konvertieren Seite handhabt das, wobei Datumszeichenketten als Zeichenketten genau so empfangen werden, wie diese sie erhält.

Wenn das JSON von einem Skript statt von einem Formatierer stammt, führen Sie es durch den JSON-Validator ersten – ein Dokument, das dort nicht geparst werden kann, scheitert auch hier, mit der gleichen Meldung.

Warum Skalare zuerst, dann Tabellen, dann Arrays

Die Platzierungsregel von TOML ist der Grund, warum die Ausgabe so geordnet ist. Schlüssel, die nach einer [table]-Headline geschrieben werden, gehören zu dieser Tabelle, und Schlüssel, die nach einer [[array of tables]]-Headline geschrieben werden, gehören zu ihrem neuesten Eintrag – also würde ein Emitter, der Skalare und Headlines mischte, eine Datei erzeugen, die erfolgreich in die falsche Struktur geparst würde. Die Schlüssel/Wert-Paare einer Ebene zuerst auszugeben, dann ihre Sub-Tabellen, dann ihre Arrays von Tabellen, ist die einzige Reihenfolge, die ein Roundtrip ermöglicht, und dieselbe Regel gilt rekursiv in jeder verschachtelten Tabelle.

Zeichenketten haben eine eigene Regel: alles wird als TOML-Grundzeichenkette in doppelten Anführungszeichen ausgegeben, mit Backslashes, Anführungszeichen und Steuerzeichen, wie TOML 1.0 es definiert. Der Konverter wechselt nicht zu Literalzeichenketten, um Zeichensetzung zu sparen, weil zu entscheiden, wann ein Backslash literal ist, genau der Rat ist, den ein Konverter nicht geben darf. Schlüssel folgen derselben Disziplin, sodass ein Schlüssel wie port: 8080 in Anführungszeichen und unmissverständlich ankommt.

Die Abbildung von JSON zu TOML

Jede Form, die der Konverter handhabt, und ihre TOML-1.0-Zielstruktur:

JSONTOML-Ausgabe
Objekt[table]-Header, Schlüssel darunter
Array von Objekten[[array of tables]]-Einträge, je eines pro Objekt
Array von SkalarenInline-Array: ["schnell", "sicher"]
ZeichenketteGrundzeichenkette mit Standard-Escapes
Schlüssel mit Punkt oder LeerzeichenZitierte Zeichenkette: "app.name" = 1
nullAbgelehnt – TOML 1.0 hat kein null

Wie die Ausgabe aussieht

Das Arbeitsbeispiel unten ist das exakte Paar, das der Konverter mit dem Button Beispielladen erzeugt: ein Root-Objekt mit zwei skalaren Werten und einem Inline-tags-Array, ein verschachteltes owner-Objekt und ein servers-Array, das zwei Objekte enthält. Beachten Sie die Reihenfolge – die einfachen Schlüssel/Wert-Paare des Roots, einschließlich tags, erscheinen alle vor [owner], und beide servers-Einträge landen unter einer [[servers]]-Headerfamilie in Array-Reihenfolge. Diese Reihenfolge ist nicht nur kosmetisch; sie ist es, was die Datei in die gleiche Struktur zurückparsen lässt.

Dasselbe Normalisierungsprinzip gilt wie überall in dieser Familie: die Ausgabe wird aus dem geparsten Dokument generiert, also sind Eigenheiten der Einrückung im Quell-JSON in der Bedeutung und der Schlüsselreihenfolge erhalten, aber in einem konsistenten TOML-Stil neu gedruckt, den ein Prüfer vergleichen kann.

Randfälle, die dieser Konverter ablehnt, anstatt sie zu verändern

Einige Eingaben haben keine treue TOML-1.0-Darstellung, und das Gegenteil vorzutäuschen, würde Ihnen eine Konfigurationsdatei in die Hand geben, die lügt:

  • Ein top-level Array oder Skalar – TOML-Dokumente sind immer ein Root-Table von Schlüssel/Wert-Paaren, also wird eine JSON-Datei, deren Top-Level kein Objekt ist, mit einer klaren Meldung abgelehnt.
  • Jedes null, überall – TOML 1.0 hat kein null, also lehnt der Konverter ab und benennt den exakten Pfad, sodass Sie den Schlüssel löschen oder einen Wert bewusst wählen können.
  • Punktartige Schlüssel – ein unzitiertes Schlüsselwort a.würde als punktetierter Schlüssel geparst und in eine verschachtelte Tabelle landen, also werden solche Schlüssel als zitierte Grundzeichenketten ausgegeben, und die Vorschau markiert sie, damit Sie Namen erkennen können, die wahrscheinlich als Verschachtelung gemeint waren.

Häufig gestellte Fragen

Wird mein JSON während der Konvertierung an einen Server gesendet?

Nein. Die Konvertierung läuft vollständig in diesem Browser-Tab: JSON.parse und der TOML-Writer sind seitenlokales JavaScript, das einmal beim Laden geladen wird. Es gibt keinen Upload-Endpunkt, und die Content-Security-Policy verbietet der Seite, Verbindungen zu öffnen. DevTools beweist es – beobachten Sie, wie das Network-Panel bei beliebig vielen Konvertierungen leer bleibt.

Warum müssen Skalare vor den [table]-Headlines geschrieben werden?

In TOML gehört jeder Schlüssel nach einer [servers]-Headline zu servers, also würde das Mischen von Skalaren und Headlines die Bedeutung der Datei ändern, während sie noch sauber geparst wird. Die Schlüssel/Wert-Paare einer Ebene zuerst zu schreiben, dann ihre Sub-Tabellen und Arrays von Tabellen, ist die einzige Reihenfolge, die in die Struktur zurückparsen lässt, mit der Sie angefangen haben – es ist Korrektheit, kein Stil.

Was tut der Konverter mit JSON null?

Er lehnt ab. TOML 1.0 hat keinen null-Wert – die Sprache bietet keine Schreibweise dafür – also gibt es keine treue Ausgabe. Der Konverter meldet den exakten Pfad des problematischen Schlüssels, wie z. B. owner.middle, und stoppt. Den Schlüssel zu löschen oder eine Sentinel-Zeichenkette einzusetzen, ist Ihre Entscheidung, nicht ein stiller Rat, der in der Ausgabe eingebaut ist.

Wie werden Arrays konvertiert?

Nach ihrem Inhalt. Ein Array, bei dem jedes Element ein Objekt ist, wird zu einem [[array of tables]], ein Eintrag pro Objekt. Ein Array von Skalaren oder gemischten Werten wird zu einem TOML-Inline-Array in einer Zeile, und ein leeres Array wird als [] ausgegeben. Nichts wird abgeflacht oder umgeformt – der Konverter rendert die Struktur, die er erhalten hat, was das Ergebnis vorhersagbar macht.

Was geschieht mit Schlüsseln, die Punkte, Leerzeichen oder Doppelpunkte enthalten?

TOML-Bare-Schlüssel erlauben nur Buchstaben, Ziffern, Unterstriche und Bindestriche, also muss alles andere ein zitiertes Schlüsselwort sein. Dieser Konverter gibt solche Schlüssel als Grundzeichenketten aus – "app.name" = 1 – was TOML 1.0 als einen einzigen Schlüssel, nicht als einen punktierten Pfad definiert. Die Vorschau markiert zitierte Schlüssel, damit Sie sehen können, welche Namen wahrscheinlich als Verschachtelung gemeint waren und sie von Hand umbenennen können.

Kann ich echte TOML-Datumsangaben aus einer JSON-Zeichenkette erhalten?

Nicht durch Konvertierung, und ehrlicherweise so. JSON hat keinen Datentyp, also kann der Konverter nicht wissen, ob "1979-05-27T07:32:00Z" ein Zeitstempel oder ein Satz ist, der zufällig so aussieht; jede Zeichenkette wird als zitierte Grundzeichenkette ausgegeben. Wenn Sie eine nackte TOML-Datumzeit wollen, entfernen Sie die Anführungszeichen in der Ausgabe von Hand – der Text ist bereits gültiges RFC 3339.