Zum Hauptinhalt springen
ToolsByUs

TOML zu JSON

Nichts wird hochgeladen: dieser Konverter analysiert TOML 1.0 in Ihrem Browser und erzeugt JSON. Tabellen werden zu Objekten, [[Array von Tabellen]]-Einträge werden zu Arrays von Objekten, RFC-3339-Datumsangaben bleiben als Strings erhalten, und doppelte Schlüssel führen mit einer zeilennummierten Fehlermeldung zu einem Abbruch, anstatt still zusammengeführt zu werden. Das JSON folgt RFC 8259.

Nur lokal

TOML zu JSON erklärt

TOML besitzt eine spezifische Nische: es ist das Konfigurationsformat von Cargo.toml, pyproject.toml und hundert Paketmanagern, gewählt, weil es ein Mensch bearbeiten kann, ohne es zu beschädigen. JSON besitzt eine andere – es ist das, was Programme austauschen. Früher oder später will ein Skript, ein Test-Fixtures oder eine API Ihr TOML als JSON, und dieser Übergang wirft genau zwei mechanische Fragen auf: wie wird ein [table]-Header zu einem JSON-Objekt, und wie wird ein [[array of tables]]-Header zu einem JSON-Array?

Die Zuordnung ist deterministisch. Ein [table] und seine Schlüssel werden zu einem verschachtelten Objekt; punktierte Schlüssel wie database.port werden ebenfalls zu verschachtelten Objekten; ein [[array of tables]] wird zu einem Array mit einem Objekt pro Header. TOML-Scalars werden direkt abgebildet – Booleans bleiben Booleans, Ganzzahlen und Fließkommazahlen bleiben Zahlen, und die Unterstriche, die TOML für Lesbarkeit erlaubt, verschwinden, weil 1_000_000 und 1000000 dieselbe Zahl sind. RFC-3339-Datumsangaben haben keinen JSON-Typ, daher kommen sie als Strings mit exakt erhaltener Textform an.

Alles läuft in diesem Browser-Tab. Der von Ihnen eingefügte TOML-Text wird von einer eingebetteten Engine analysiert, das JSON wird aus dem analysierten Dokument serialisiert, und beide berühren kein Netzwerk – öffnen Sie DevTools und beobachten Sie, wie das Netzwerk-Panel beim Konvertieren schweigt. Die Content-Security-Policy der Seite verbietet ausgehende Verbindungen, daher ist der Datenschutz-Claim nachprüfbar und nicht nur dekorativ.

Round-tripping ist der übliche Arbeitsablauf – Konfig aus einem Payload extrahieren, bearbeiten, wieder einfügen – und die JSON zurück zu TOML konvertieren Seite läuft diese Zuordnung umgekehrt ab, zuerst mit den Scalars.

Das JSON, das dieses Tool erzeugt, ist standardmäßig kompakt, daher wenn Sie es für die Lesbarkeit eingerückt haben möchten, der JSON-Formatierer druckt es mit Ihrer gewählten Zeicheneinzug neu aus.

Wie die Konvertierung tatsächlich funktioniert

Die Engine analysiert Ihr TOML zuerst in ein Dokumenten-Baum, weil jede JSON-Entscheidung aus TOMLs eigenen Geltungsbereichsregeln folgt: ein [table]-Header öffnet ein benanntes Objekt, ein [[array of tables]]-Header hängt ein neues Objekt an ein benanntes Array an, und Schlüssel über jedem Header gehören zum Wurzelobjekt. Sobald der Baum existiert, ist die JSON-Erzeugung eine einfache Serialisierung – die einzigen Urteile sind die Stellen, an denen TOML und JSON nicht übereinstimmen, und jede wird jedes Mal gleich entschieden:

  • Tabellen: [owner] mit einem name-Schlüssel erzeugt ein owner-Objekt – TOMLs Header und JSONs Klammern kodieren dieselbe Verschachtelung.
  • Tabellen-Arrays: jeder [[servers]]-Header hängt ein Objekt an das servers-Array an, in Dateireihenfolge.
  • Punktierte Schlüssel: database.port = 5432 verschachtelt sich unter database, genau wie TOML 1.0 punktierte Schlüssel definiert hat.
  • Datumsangaben: 1979-05-27T07:32:00Z hat keinen JSON-Typ, daher wird er als String „1979-05-27T07:32:00Z“ ausgegeben, Byte für Byte.
  • Zahlen: Unterstriche sind TOML-Zeichen, keine Daten – 1_000_000 wird als 1000000 ausgegeben – und TOMLs inf und nan werden zu null, weil JSON keine Literale dafür hat.

Wie das Aussehen des Outputs ist

Das Arbeitsbeispiel unten ist das exakte Paar, das der Konverter mit dem Button „Beispiel laden“ erzeugt: eine Wurzel mit drei skalaren Schlüsseln (einer davon mit Unterstrich), einer [issuer]-Tabelle und zwei [[items]]-Einträgen. Beobachten Sie, wie jede Form übergeht – die Unterstriche verschwinden in der Zahl, die issuer-Tabelle verschachtelt sich als Objekt, und das items-Array sammelt seine Objekte in Dateireihenfolge. Schlüssel bleiben in der Reihenfolge, die das TOML deklariert hat, weil Dokumentenreihenfolge die einzige Reihenfolge ist, die ein Konverter ehrlich beibehalten kann.

Weil das JSON aus dem analysierten Baum und nicht durch textuelles Zusammensetzen ausgegeben wird, wird auch das Format normalisiert: zwei Abstandsstile im TOML erzeugen ein konsistentes JSON, und eine fehlgeleitete Leerzeile ändert nichts. Was überlebt, ist Struktur und Werte – was genau ist, was ein Konverter versprechen sollte.

Doppelte Schlüssel und andere ehrliche Fehler

Ein ehrlicher Konverter lehnt Eingaben ab, die er nicht treu repräsentieren kann, und TOML 1.0 ist streng genug, dass solche Ablehnungen selten und eindeutig sind. Drei Eingaben werden mit einer spezifischen, zeilennummierten Nachricht abgelehnt, anstatt still umgeformt zu werden:

  • Doppelte Schlüssel – TOML 1.0 verbietet, einen Schlüssel mehr als einmal zu definieren, daher stoppt der Parser an der fehlerhaften Zeile, anstatt dass last-one-wins still Ihre Konfig überschreibt.
  • Mehrzeilige Strings – der unterstützte Subset dieses Parsers deckt einzeilige Basis- und Literal-Strings ab; ein """-Block wird mit einer Nachricht abgelehnt, die genau das sagt, anstatt eines verstümmelten Raten.
  • Ungeschlossene Konstrukte – ein [table]-Header oder ein String in Anführungszeichen, der nie endet, meldet die Zeile, an der der Parser aufgab, nicht einen generischen Syntaxfehler.

Die Zuordnung im Überblick

Jedes Konstrukt, das dieser Konverter unterstützt, und wo es im JSON landet:

TOML 1.0JSON-Ausgabe
[owner] TabelleVerschachteltes „owner“-Objekt
[[items]] Header„items“-Array von Objekten
database.port punktierter SchlüsselVerschachteltes „database“-Objekt
1979-05-27T07:32:00ZString, RFC-3339-Text erhalten
1_000_000Zahl 1000000
'literal string'String, Backslashes unverändert

Häufig gestellte Fragen

Lädt das Konvertieren von TOML zu JSON meine Datei irgendwo hoch?

Nein. Analyse und Serialisierung laufen beide in diesem Browser-Tab mit JavaScript, das beim Öffnen der Seite geladen wurde. Es gibt keine API-Route, an die Daten gesendet werden könnten, und die Content-Security-Policy blockiert ausgehende Verbindungen. Sie können beide Claims in Sekunden verifizieren: öffnen Sie DevTools, beobachten Sie das Netzwerk-Panel beim Konvertieren und sehen Sie, dass keine Anfrage gesendet wird.

Was passiert mit TOML-Datumsangaben in der JSON-Ausgabe?

Sie werden zu Strings. JSON (RFC 8259) hat keinen Datums- oder Datumszeit-Typ – nur String, Zahl, Boolean, null, Objekt und Array – daher wird 1979-05-27T07:32:00Z als exakter String „1979-05-27T07:32:00Z“ ausgegeben. Nichts wird neu formatiert oder in eine andere Zeitzone verschoben; der Text überlebt Byte für Byte, und Ihr nachgelagerter Code parst ihn, wenn er ein echtes Datum benötigt.

Wie unterscheidet sich [[array of tables]] von [table]?

Doppelte Klammern anhängen, einfache Klammern definieren. [servers] erstellt ein Objekt namens servers; ein zweiter [servers]-Header wäre ein Duplikatschlüssel-Fehler. [[servers]] erstellt ein Array und hängt ein Objekt pro Header an, daher werden drei [[servers]]-Blöcke zu einem dreielementigen Array. Die Einfach-gegen-Doppel-Unterscheidung ist der ganze Unterschied, weshalb dieser Konverter sie auch in umgekehrter Richtung erhält.

Warum ist ein doppelter Schlüssel ein Fehler anstatt einer Überschreibung?

Weil TOML 1.0 deklariert, dass ein Schlüssel mehrfach zu definieren ungültig ist, und ein Konverter, der den Konflikt auflösen würde, eine Datei zertifizieren würde, deren eigene Spezifikation sie ablehnt. Der Fehler nennt die Zeilennummer der zweiten Definition, was通常是 der Tippfehler oder die schlechte Zusammenführung ist, die Sie ohnehin finden mussten.

Mein TOML verwendet mehrzeilige, dreifach in Anführungszeichen gesetzte Strings – warum der Fehler?

Dieser Parser unterstützt einen dokumentierten Subset von TOML 1.0: einzeilige Basis-Strings, einzeilige Literal-Strings, Ganzzahlen, Fließkommazahlen, Booleans, Datumsangaben, Tabellen, Tabellen-Arrays und punktierte Schlüssel. Mehrzeilige Strings sind außerhalb des Subsets und werden mit einer klaren benannten Nachricht abgelehnt, anstatt teilweise analysiert zu werden. Teilen Sie den Wert in einen einzeiligen String mit \n-Escapes auf, und er wird sauber konvertiert.

Was ist mit meinen inf- und nan-Werten passiert?

TOML erlaubt Fließkomma-inf und nan, aber JSON hat keine Literale dafür – JSON.parse kann sie nicht erzeugen und JSON.stringify schreibt null. Der Konverter gibt null für diese beiden Werte aus und markiert sie in der Vorschau, weil unendlichkeit still in eine endliche-aussehende Zahl zu verwandeln die Art von Lüge ist, die Stunden kostet, um sie zurückzuverfolgen.

ToolsByUs-Team · Wie wir unsere Tools prüfen