分析と広告のためのCookie
分析と広告のためにCookieを使っており、どちらもGoogleに送られます。拒否しても、目に見える動作は何も変わりません。プライバシーポリシーを読む
ここで TOML を XML に変換できます。無料、アカウント不要です。ファイルを上の枠に落とせば、数秒で結果がダウンロードできる状態になります。 変換はお使いのブラウザーの中で行われるので、ファイルはアップロードされません。Windows でも macOS でも Linux でも、iPhone でも Android でも同じように動き、通信を切っても動き続けます。
一度に100ファイルまで。フォーマットが混ざっていても構いません。
順番に変換し、まとめてZIPでダウンロードします。
TOML から XML
このページが本当に役立つのは設定の移行ではなく、報告や提出の場面です。プロジェクトの情報は Cargo や pip、Hugo が選んだ TOML のマニフェストにあり、それを求めるライセンス台帳や取引先ポータル、社内の取り込みツールは 2004 年から XML を読んできて、これからも変わりません。
ですから、TOML を忠実に XML で表現することが目的ではありません。誰かが定義した文書の形にどれだけ近づけるか、その差を自分の手でどう埋めるかが本題です。差は主に 5 か所あり、それぞれ以下の節で扱います。
XML はルートを 1 つだけ必要としますが、TOML の文書はいくつでもキーを持てるテーブルです。トップレベルのキーが 1 つだけで、それがテーブルなら、そのキーがルート要素になります。`[tool]` セクションだけのファイルは `<tool>` になります。トップレベルのキーが複数あるなら、すべてが汎用の `<root>` に包まれます
ルート名の変更はほぼ必ず最初の編集になります。繰り返し変換するなら、マニフェスト側をスキーマが求める名前のテーブル 1 つにまとめ直すほうが確実です。
`[[bin]]` ブロックが 3 回繰り返されていれば、それは 3 つの兄弟要素 `<bin>` になり、それぞれが自分の子要素を持ちます。これは XML がリストを表す方法そのもので、ここは何も決めなくて済む場所です。
単純なスカラー配列も同じ扱いです。`tags = ["a", "b"]` はカンマ区切りの文字列ではなく、テキストを持つ 2 つの `<tags>` 要素になります。
TOML は珍しく 4 種類の時間型を持ち、この変換は 1 つの UTC 時刻にまとめずに区別を保ちます。オフセット付き日時とローカル日時はどちらも有効な xs:dateTime になり、ローカルな日付は xs:date に、ローカルな時刻は xs:time になります。
すべての値にミリ秒が付きます。`08:00:00` は `08:00:00.000` になり、3 つの XSD 型はどれも小数秒を許容しますが、短い書き方の文字列と単純比較しているコードは一致しなくなります。
オフセットは正規化されず書かれたとおりに残ります。`+02:00` の日時は `Z` に変換されず `+02:00` のまま出力されます。文書として読むなら望ましい挙動ですが、文字列としてのソートには向きません。
ローカルの時刻はさらに注意が必要です。`at = 08:00:00` には日付がなく、要素が `xs:dateTime` として宣言されていると検証が通りません。その要素を `xs:time` として宣言するか、TOML 側に日付を足しておいてください。
TOML は引用符さえ付ければほぼ何でもキーにできますが、XML の要素名は数字で始められず、空白やコロンを含められません。文字、数字、アンダースコア、ハイフン、ピリオド以外はアンダースコアに置き換わります。
`"2024 report"` は `<_2024_report>` に、`"x:y"` は `<x_y>` になります。コロンが名前空間のつもりで書かれていた場合は特に注意してください。
既定ではすべてのキーが子要素になります。テーブルの中で `"@id" = 42` と書けば、`<id>` 要素ではなくその要素の `id="42"` という属性になります。
同じ仕組みで `"#text"` はその要素のテキスト内容になります。TOML 側でこれを使うほうが、変換してから XSLT で属性に移し替えるより速く確実です。
XML 宣言も名前空間の宣言もなく、文書はルート要素から始まります。空の TOML 配列 `tags = []` は要素そのものを生成せず、空行が残るだけです。
コメントはどちらの形式にもありますが、読み書きのどちらでも移されません。依存関係を固定した理由のような説明は XML には残らないので、TOML を編集の原本として扱い、XML は生成物として管理してください。
ルート名が違う、ローカル時刻が xs:dateTime を満たさない、属性であるべき値が子要素になっている、空の配列が消えている——最初の出力はこれらの理由でほぼ確実に検証を通りません。
`xmllint --schema contract.xsd out.xml --noout` は行番号付きで問題を一覧にしてくれます。TOML 側を作り直しながら通すほうが、XML を直接編集するより確実です。
このブラウザーのタブの中、プレーンな JavaScript で処理されます。何もアップロードされず、アカウントも 1 日の上限もありません。無料枠は 100 MB ですが、マニフェストがそこまで大きくなることはまずありません。
出力の XML は開始タグと終了タグの分だけ名前を 2 回書くので、元のマニフェストの 2 倍から 3 倍の大きさになります。これは形式そのものの通常のコストで、gzip などの転送圧縮で吸収されます。
| TOML | XML | |
|---|---|---|
| 正式名称 | Tom's Obvious Minimal Language | Extensible Markup Language |
| 拡張子 | .toml | .xml |
| メディアタイプ | application/toml | application/xml |
| 最初の公開 | 2013 | 1998 |
| 発行元 | — | W3C |
| 仕様 | TOML 1.0 | XML 1.0 |
| ライセンス | オープン標準 | オープン標準 |
| 現在の位置づけ | 現行 | 現行 |
| ブラウザで開けるか | 対応なし | すべてのブラウザ |
| 代わりに検討される形式 | YAML, JSON, INI | JSON, YAML |
失われるものはありません。TOML も XML も中身を劣化なしに保持します。この変換が変えるのは包み方であって品質ではないので、劣化が積み重なる心配をせずに何度でも繰り返せます。
コメントは引き継がれます。TOML にも XML にもコメントの構文があるので、あとで面倒を見る人のために残したメモが黙って消えることはありません。
XML は今のブラウザーならどれでも開けます。TOML はそこまでも届きません。ファイルがウェブページや申込フォームへ向かうのであれば、たいていはそれがこの変換の理由のすべてです。
Visual Studio Codeは TOML と XML のどちらも読めるので、別のプログラムを開かずに、結果を元のファイルと並べて確かめられます。
2 つは狙っている用途が違います。TOML は編集、XML はプログラム間のデータ受け渡しです。ここは考える価値があります。一方が存在する理由が、そのままもう一方が使いにくい理由になっていることが多いからです。
TOML は 2013 年に登場しました。 TOML 1.0 で規定されています。ファイルが、それを書いた道具より長く生きなければならないなら、この一点には値打ちがあります。
XML は W3C の形式で、1998 年から使われています。規定は XML 1.0 です。Visual Studio CodeとoXygen XML Editorがこの形式を読めます。
XML は 1998 年、TOML は 2013 年に登場しました。人に渡すならたいてい古いほうが安全で、新しいほうは同じ仕事をより少ないバイト数で片づけます。
いいえ。この変換は完全にブラウザーの中で行われるので、ファイルが端末から出ることはありません。ご自分で確かめられます。開発者ツールのネットワークタブを開いて、何か変換してみてください。ページそのものと、このサービスの費用をまかなっている分析・広告のリクエストは見えますが、あなたのファイルを運んでいるリクエストはひとつもありません。
はい。アカウントも透かしもなく、消費される 1 日の割り当てもありません。お使いの機械の上で動くので、何度でも戻ってきていただけます。ブラウザーが扱えるのは 100 MB までのファイルで、一度に 100 本です。
いいえ。XML は同じ内容を何も捨てずに保持できるので、結果は品質の点で元のファイルと同じです。
失われるものはありません。TOML も XML も中身を劣化なしに保持します。この変換が変えるのは包み方であって品質ではないので、劣化が積み重なる心配をせずに何度でも繰り返せます。