TOML パーサー

文字列、整数、浮動小数点数、ブール値、日時、配列、テーブル（ハッシュマップ）に対応しています。インラインテーブルと複数行文字列にも対応しています。

TOML は設定ファイル用に特化して設計されています。JSON と異なりコメントに対応し、人間がより読みやすい形式です。YAML と異なり、より厳格でシンプルな文法を持ち、パースエラーが発生しにくくなっています。

はい！すべての解析はブラウザ内で完結します。データがサーバーに送信されることはないため、設定ファイルのプライバシーが完全に保護されます。

[server] はテーブルを開始し、[server.tls] はその内部にネストしたテーブルを作成します。[[products]] はテーブルの配列を開始し、[[products]] ヘッダーが繰り返されるたびに新しい要素が追加されます。これは設定ファイルでレコードのリストを表現する定番の書き方です。インデントは見た目上のものにすぎず、構造を定義するのは角括弧のヘッダーです。

TOML 1.0 には 4 つの日時型があります。オフセット付き日時（1979-05-27T07:32:00Z、RFC 3339 形式）、オフセットなしのローカル日時、ローカル日付（1979-05-27）、ローカル時刻（07:32:00）です。タイムスタンプは第一級の値として扱われるため、引用符で囲んだり文字列としてパースしたりする必要がなく、JSON や YAML で文字列の日付が引き起こしていた一連の設定バグを回避できます。

INI と比較すると、TOML には正式な仕様があり、型付きの値（整数、浮動小数点数、真偽値、日付、配列）をサポートし、ドット区切りキーの慣習ではなく明快なネスト構造を提供します。JSON と比較すると、コメントや複数行文字列が使え、末尾カンマの落とし穴もありません。プログラム間のデータ交換には引き続き JSON が適しており、TOML は人が手で書く設定ファイルに特化しています。

Rust の Cargo（Cargo.toml）によって有名になり、Python ではビルド設定の標準として採用されています（pyproject.toml、PEP 518）。Hugo、Netlify、多くの CI システムでも利用されています。この形式は toml-lang 組織によって適合性テストスイートとともに保守されており、これが各言語のパーサー間で動作が一致する理由の 1 つです。

トリプルのダブルクォートは実際の改行を含む複数行文字列を表現でき、行末にバックスラッシュを置けば余分な空白を取り除けます。トリプルのシングルクォートは同様の機能を持ちながら、エスケープ処理を一切行いません。シングルクォートのリテラル文字列もエスケープを完全にスキップするため、Windows のパス（C:\Users\name）や、そうでなければすべてのバックスラッシュを二重にする必要がある正規表現パターンの記述に最適です。