XML を INI に変換

.NET の App.config を置き換える小さなツールや、INI しか読めない古いインストーラー、20年前から変わっていない機器の設定パーサー。こうした読み込み先に値を渡すために、XML の階層構造をフラットなキーと値の並びに変換する必要が出てくる場面があります。

このページは XML のツリー構造を、セクションとドット区切りのキーに変換します。翻訳ではなく抽出だと考えてください。

この変換は、各値までの経路をドット区切りのパスとして組み立て、それを最初のドットで1回だけ区切ります。区切りより前がセクション名、後ろがキーになります。XML の文書はルート要素を1つしか持たないため、そのパスの最初の部分はファイル内のすべての値で同じになり、結果として1つのセクションの下に長いキーの一覧が並びます。

YAML や JSON からの同じ変換では、トップレベルのキーの数だけセクションができるのとは対照的です。論理的なまとまりごとにセクションを分けたい場合は、ルート直下の子要素ごとに個別に変換するほうが確実です。

典型的な .NET の構造——configuration というルートの下に appSettings があり、その中に key と value という属性を持つ add 要素がいくつも並ぶ形——を変換すると、configuration という1つのセクションの中に、appSettings.add.0.@key が Timeout、appSettings.add.0.@value が 30 という形のキーが並びます。

正確ではありますが、読みやすくはありません。本当に欲しかった情報「Timeout は 30」は、同じ番号でつながった2行に分かれてしまいます。スクリプトに渡すだけなら、この2行を読んで Timeout=30 と書き直すほうが、この形のまま読み込ませるより早いことがよくあります。

すべての属性は @ を先頭に付けたキーの一部になります。id という属性を持つ要素なら、@id で終わるキーになります。属性とテキストの両方を持つ要素では、テキストの部分は #text という名前のセグメントに入ります。属性がすでに要素自体のキーを使っているためです。

どちらの記号も INI の標準的な慣習ではなく、INI を読むソフトが特別扱いすることもありません。プログラムに渡す前に、まず取り除くことを検討してください。INI 側にはもう壊れる構造がないので、キー名のリネームは安全に行えます。

同じタグを持つ兄弟要素が2つ以上あると、add.0、add.1 のように、文書に現れた順に番号が振られます。順序は保たれるので、ルールの一覧や検索パスのような用途では重要な性質です。

一方で、その要素が1つしかない場合には番号が付きません。パーサーには、その要素が繰り返しうるものかどうかを知る手段がないためです。つまり、設定が1件のときと2件のときとでキー名が変わってしまいます。番号付きのキーを前提にしたスクリプトは、設定が1件しかない日に何も見つけられません。

バージョンと文字コードの宣言で始まる文書は、?xml という名前のセクションを作ります。ルート要素の名前空間の宣言があれば、@xmlns のようなキーとして本来のセクションに紛れ込みます。どちらも設定の内容ではなく、XML そのものについての情報です。

この2つは削除してください。放置しても INI としては違反にはなりませんが、次にこのファイルを見る人や、場合によってはパーサーを混乱させます。文字コードの値も、そのまま信用しないほうがよいでしょう。1.0のような値は数値として解釈され、1として出力されるため、元の宣言と一致しなくなっていることがあります。

ライセンス文やスクリプト、整形された説明文のように、1つの要素の中に複数行のテキストが入っていることがあります。現在の書き出し処理では、こうした値を引用符で囲み、改行はバックスラッシュとnで表現するため、要素は1つの項目のまま壊れずに戻ってきます。

それでも、こうした複数行のテキストを含む要素がどこにあるかは把握しておく価値があります。読み込み先のプログラムがバックスラッシュをそのまま文字として読んでしまう場合があるためです。それが重要な場面では、テキストを別ファイルに分け、INI にはそのパスだけを持たせるほうが安全です。

セミコロンやスラッシュ、空白、内部に含まれる等号は、そのまま値として残ります。INI パーサーは最初の等号だけで区切るため、Server=db;Database=xのような接続文字列も1つの値として正しく戻ります。

要素の並び順、属性と子要素の相対的な位置もすべて保たれます。数値らしく見える値は読み込み時に解釈されるため、1.0と書かれたバージョン番号は1に、007と書かれたゼロ埋めの識別子は7になります。トークンとして扱っていた値は、変換後に確認しておく価値があります。

コメントは失われ、名前空間は単なる文字列の一部になり、属性と子要素の区別は文字列中の @ だけが頼りになります。INI にはスキーマ言語という概念自体がないため、検証もできなくなります。

これは方向性としては当然の結果です。XML は1998年から W3C の勧告として存在し、スキーマや XPath、変換や署名といった仕組みを持ちますが、INI は1985年から続く、行の並びだけの形式です。元の XML はバージョン管理に残しておくことをおすすめします。

この変換にたどり着く人の多くは、実際には文書全体ではなく、いくつかの設定値だけを必要としています。その場合は XML から値を読み取り、読み込み先が期待する形で INI に直接書いたほうが早く、読みやすい結果になります。

この変換が向いているのは、手作業で読むには量が多すぎる場合や、ベンダーの設定ファイルに何が入っているかを一通り把握したい場合です。変換した結果をそのまま新しい設定ファイルとして配布するのは避けてください。

XML の解析も INI への書き出しも、このページの JavaScript が行います。認証情報を含む設定ファイルであっても、外部に送信されることはありません。