TOML-Parser

TOML unterstützt Zeichenketten, Ganzzahlen, Gleitkommazahlen, Boolesche Werte, Datum/Uhrzeit, Arrays und Tabellen (Hash-Maps). Es unterstützt auch Inline-Tabellen und mehrzeilige Zeichenketten.

TOML wurde speziell für Konfigurationsdateien entwickelt. Im Gegensatz zu JSON unterstützt es Kommentare und ist besser lesbar. Im Gegensatz zu YAML hat es eine strengere und einfachere Grammatik, was es weniger anfällig für Analysefehler macht.

Ja! Die gesamte Analyse erfolgt vollständig in Ihrem Browser. Es werden keine Daten an einen Server gesendet, sodass Ihre Konfigurationsdateien vollständig privat bleiben.

[server] öffnet eine Tabelle; [server.tls] verschachtelt eine darin; und [[products]] startet ein Array von Tabellen, wobei jeder wiederholte [[products]]-Header ein neues Element anhängt - das idiomatische Muster für Listen von Datensätzen in Konfigurationsdateien. Einrückung ist rein kosmetisch; die Klammer-Header definieren die Struktur.

TOML 1.0 hat vier zeitbezogene Typen: Offset-Date-Time (1979-05-27T07:32:00Z, RFC-3339-Format), Local Date-Time ohne Offset, Local Date (1979-05-27) und Local Time (07:32:00). Zeitstempel sind Werte erster Klasse - kein Quoting, kein String-Parsing - wodurch eine ganze Klasse von Konfigurationsfehlern entfällt, die Datumsangaben als Strings in JSON oder YAML verursachen.

Gegenüber INI: TOML bietet eine echte Spezifikation, typisierte Werte (Ganzzahlen, Gleitkommazahlen, Booleans, Datumsangaben, Arrays) und sauberes Verschachteln statt Dotted-Key-Konventionen. Gegenüber JSON: Kommentare, mehrzeilige Strings und keine Fallstricke mit nachgestellten Kommas. JSON bleibt besser für den Datenaustausch zwischen Programmen; TOML ist gezielt auf von Menschen geschriebene Konfiguration ausgelegt.

Rusts Cargo (Cargo.toml) machte es berühmt; Python hat es für Build-Konfiguration standardisiert (pyproject.toml, PEP 518); und es taucht in Hugo, Netlify und vielen CI-Systemen auf. Das Format wird von der toml-lang-Organisation mit einer Konformitätstestsuite gepflegt - ein Grund, warum Parser sprachübergreifend übereinstimmen.

Dreifache doppelte Anführungszeichen umfassen mehrere Zeilen mit echten Zeilenumbrüchen und unterstützen Backslashes am Zeilenende, die Whitespace entfernen; dreifache einfache Anführungszeichen tun dasselbe ohne jegliche Escape-Verarbeitung. Einfache literale Strings verzichten ebenfalls vollständig auf Escapes - ideal für Windows-Pfade (C:\Users\name) und Regex-Muster, die sonst jeden Backslash verdoppeln müssten.