INI を XML に変換

対応関係は予測できるほど直接的です。セクションの見出しは要素になり、その下の各キーは子要素になり、値はその要素のテキストになります。[db] というセクションに host と port を持つ INI ファイルは、host 要素と port 要素を含む db 要素になり、階層ごとに 2 スペースずつインデントされます。

この予測可能さこそ、この組み合わせがスクリプトではなくツールに値する理由です。解決すべきあいまいさがありません。INI ファイルが変換ツールに解釈させるものはほとんどないからです。1 段のグループ化、1 行に 1 つのキーと値。興味深いことはすべて端のところで起きており、このページの残りはその端の話です。

XML は最外殻の要素をちょうど 1 つ必要としますが、INI ファイルにはその概念がありません。変換ツールは読み込んだ内容を見て解決します。ファイルにセクションが 1 つだけしかなかった場合、そのセクションがルートになります。[settings] という 1 セクションのファイルは、ルートタグが settings の文書になります。それ以外——セクションが 2 つ以上あるか、最初のセクション見出しより上にキーが書かれている場合——は汎用のルート要素で包まれます。

結果に対して XSD や XPath を書く前に知っておく価値があります。元の INI ファイルにセクションを 1 つ追加すると、出力のルート要素は settings から root へ黙って変わり、以前の版に対して書かれたパス式はすべて一致しなくなります。文書の形が下流で重要なら、セクション数に決めさせるのではなく、包み方を自分で決めて安定させてください。

INI にはそもそも型システムがありません。等号の右側にあるものはすべて文字です。それでも読み込み処理は推測を行い、true と false を真偽値に、数値として解析できるものを数値に変換します。XML ライターは受け取ったものをそのままテキストとして出力します。ほとんどのキーではこの往復は見えません。

一部では見えます。007 と書かれた値は数値の 7 として読まれ 7 として書き戻されます。1.0 と書かれたバージョン番号は 1 になります。0x1F と書かれた 16 進数のマスクは 31 として出てきて、0755 と書かれた Unix のファイルモードは 755 として出てきますが、これは異なるモードです。単位が付いているものはそのまま無事に残ります。128M は 128M のままで、127.0.0.1 のようなドット区切りのアドレスや 08:00 のような時刻もそのままです。単一の数値としては解析できないからです。

XML は INI よりずっと名前に厳格です。INI のキーはスペースやスラッシュ、コロン、角括弧を含められますが、要素名は文字、数字、アンダースコア、ハイフン、ドットくらいしか含められず、数字で始めることもできません。そのためライターは、使えない文字をすべてアンダースコアに置き換え、文字やアンダースコア以外で始まる名前には先頭にアンダースコアを付けます。

この置き換えは可逆ではないので、句読点だけが違う 2 つのキーが同じ要素名に衝突することがあります。「log level」と「log-level」はハイフンが正当な文字なので衝突しませんが、「log level」と「log/level」はどちらも log_level になります。INI ファイルにそうしたキーがあるなら、あとからどの行がどの要素になったか調べるより、変換前に元データでリネームしてください。

[database.pool] のように書かれたセクション見出しは、入れ子になりそうに見え、TOML ならそうなります。ここではそうなりません。読み込み処理は角括弧の間のすべてを 1 つのセクション名として扱うので、出力は database.pool という名前の 1 つの要素の中にキーを持ちます。ドットは XML の要素名として正当なので文書は有効です。ただ、期待していたかもしれない深さがなく、平坦なだけです。

目的のスキーマが本物の入れ子を求めているなら、その構造は変換ではなく作り直す必要があります。正直な手順は、まず変換してから、XSLT か手作業でできあがった XML を組み直すことです。句読点から入れ子を推測する変換ツールは、ドットが区切り文字ではなく名前の一部であるすべての INI ファイルで推測を誤ります。date.timezone のようなキーがいたるところにある PHP の設定ファイルは、まさにそのケースです。

INI には標準がなく慣習しかなく、実装が食い違う点の 1 つが、セクション見出しの重複が何を意味するかです。2 つのブロックを結合する実装もあります。この読み込み処理はそうしません。見出しを見るたびに新しい空のセクションを作るので、[logging] が 2 回現れるファイルは 2 回目の出現からのキーだけを保持し、最初のブロックはエラーもなく完全に失われます。

手書きされたファイルでは重複した見出しは珍しく、連結によって組み立てられたファイル——基本の設定に環境ごとの上書きを追加する、実在するデプロイパターン——ではよくあります。変換する前に元データで重複した見出しを検索してください。失敗は静かで、出力は完全に整った XML 文書ですが、単に設定が欠けているだけです。

どちらの形式もコメントに対応しています。INI はセミコロンかハッシュで、XML は山括弧のブロックで示しますが、この変換はそのどちらも引き継ぎません。コメント行は読み込み時に読み飛ばされ、二度と現れません。レジストリはどちらの形式もコメント対応と記録しており、これはこの目的地の限界ではなく、この処理経路特有の欠落です。

設定ファイルでは、これは見た目以上に重要です。タイムアウトの上に書かれた「1 件の遅いレポートのために 90 秒に上げた」という説明の行が、その判断についてどこかに残る唯一の記録であることがよくあります。変換する前にコメント付きの元データをバージョン管理へコピーし、変換後の XML に説明を付け直してください。この種の自動変換の中に、それを代わりにやってくれるものはありません。

この移行を行う理由は構文ではないことがほとんどです。XML 1.0 は 1998 年から W3C 勧告で、その周りには INI が持てなかった仕組みが揃っています。誤字のあるキーを含む設定をアプリケーションが起動する前に拒否できる XSD スキーマ、大きな文書から 1 つの値を取り出す XPath、それを組み直す XSLT、設定ファイルが改ざんされていないことを証明する XML デジタル署名などです。

それらはこの変換と一緒には届きません。出力はスキーマも名前空間も持たない整った文書で、スキーマを書くことこそが本当の作業です。この変換は、それを書くための出発点となる文書を用意するだけです。結果を検証したり署名したり変換したりするつもりがないなら、この移行は冗長さを買うだけで、それ以外の何も得られません。

ファイルを読むアプリケーションがそれを書いたアプリケーションと同じで、下流の誰もスキーマを必要としないなら、変換は見返りのないコストです。INI ファイルは、メモ帳を開ける人なら誰でも編集でき、それは深夜 2 時に設定を変える人が開発者ではないときに、実務上本物の価値を持ちます。

ファイル全体ではなく 2、3 個の値だけが必要な場合も、この変換は間違った道具です。それらは直接読み取ってください。この変換ツールは INI ファイルが設定そのものであり、その設定が移動する場面のためのものであって、断片を抽出するためのものではありません。