INIファイルとは

INI はプレーンテキスト形式です。どのエディターでも開けます。 編集のために使われます。

拡張子は .ini、正式名称は INI Configuration です。ただしどちらも、そのファイルが中に何を持てるかほどには多くを語りません。このページの残りは、その中身についての話です。

1985 年までさかのぼります。

これだけ長く読まれ続けてきた形式なら、10 年後に取り出したいものを預けても大丈夫です。

仕様書がそのまま公開されているので、中身を推し量るのではなく文書を読んで実装できます。この形式が数多くのプログラムに載っているのはそのためであり、20 年前に書かれたファイルが今も開けるのもそのためです。ただし「仕様が公開されている」ことと「使用料が要らない」ことは別の話です。中でコーデックを包んでいる形式では、特許のライセンスは仕様書が答えていない別の問題として残ります。

今もどこでも開けますし、古いプログラムは今もこれを書き出します。ただ、この形式のまわりで新しいものは何も作られていません。残しておきたいものは移してください。そして今日始める仕事には、これを選ばないでください。

INI ファイルにはコメントを書く方法があります。人が面倒を見るファイルと、プログラムが書き出すファイルを分けるのは、まさにこの一点です。コメントを持てない形式へ変換すると真っ先に消え、しかも誰も警告してくれません。

NotepadとVisual Studio Codeが読めますし、同じ種類のプログラムならたいてい読めます。

ファイルが開かないとき、形式が悪いことはめったにありません。たいていはプログラムのほうが形式より古いのです。もっと古い形式に変換してしまうのが確実な逃げ道で、このサイトの残りの部分はそのためにあります。

これを読めるブラウザーはありません。

これを変換するいちばんよくある理由がこれです。形式が悪いのではありません。ファイルを見せたい場所が、それを読めないというだけのことです。

INI は、開いて手を入れるために作られています。作業が続いているあいだはこの形式でファイルを持ち、完成したものが必要になるたびに、ここから書き出してください。

INI は初期の Windows から生まれ、システムとあらゆるアプリケーションの設定を保持していました。標準化されたことは一度もありません。それを定義する文書はなく、それを所有する委員会もなく、それを読むあらゆるプログラムが自分なりの方言を実装しています。

核となる部分は普遍的です。角括弧で囲まれたセクションの見出し、その下にキーと値をイコールで結んだ行。それより先はコイントスです。コメントをセミコロンで始めるかハッシュで始めるか。値を引用符で囲めるか、囲んだ場合その引用符はどうなるか。キーが大文字小文字を区別するか。値が二行目に続けられるか。セクションが入れ子にできるか（たいていの方言ではできません）。同じファイルを読む二つのプログラムが正当に食い違うことがあり、しかも両方とも正しいのです。

timeout=30 と書けば、ファイルには文字の 3 と 0 が入っています。それが数値になるかどうか、秒を意味するのかミリ秒を意味するのかは、まったく読む側のプログラムが決めます。true、yes、on、1 についても同じで、どれもブール値を表すよくある書き方ですが、この形式では何一つ定義されておらず、ライブラリごとに違う部分集合を受け入れます。

これが JSON や YAML、TOML との実際上の違いで、これらはどれも型を持っています。だから INI の設定ファイルはたいてい、値が何を意味するかを説明する文書やコメントを伴っていて、同じプログラムの二つの実装のあいだで設定ファイルを移動させるのは、見た目より危険です。

Windows では今も、フォルダーの表示方法を制御する desktop.ini、起動とドライバーの設定、変える理由が一度もなかった長い尾のようなアプリケーション群。ゲームはとくに豊かな供給源です。膨大な数の PC ゲームが画質と入力の設定を INI に保持していて、これが調整ガイドが軒並み編集手順であふれている理由です。

ほかの場所では、現代の代替が生まれる前からのツール群の中に残っています。PHP の php.ini、Git の設定、Python の setup.cfg やパッケージングツール、systemd のユニットファイル、そして数えきれない小さなユーティリティ。新しいプロジェクトは TOML や YAML を選びがちですが、既にインストールされているものが書き直されることはありません。

どんなテキストエディタでも構いません。二つの規則が、人がやってしまう被害のほとんどをカバーします。変更する前にファイルをコピーすること、そして一度に一つだけ変えること。悪い設定ファイルのせいで起動しなくなったプログラムは、どの行が問題だったのかを教えてくれないことが多いからです。

そして、実際に失敗を招く細部があります。BOM なしの UTF-8 で保存すること。ファイル先頭の見えないバイトが、多くのパーサーで最初のセクションの見出しを壊してしまいます。イコールの周りにスペースを加えないでください。読む側がそれをトリムしてくれるとは限らず、しなければ値が先頭に空白を持つ文字列になってしまいます。そして引用符はそのままにしておくこと。既存の値が引用符なしなら、引用符を加えることは値を区切るのではなく、値に二文字を足すことになるかもしれません。

それは分かりやすさです。一度もそのファイルを見たことがない人でも開いて、fullscreen という設定を見つけ、false を true に変えて、それで正しくできます。これは本物の性質で、1990 年代にこれを置き換えるはずだったあらゆるものより長生きしている理由です。

また、浅いケースでは緩やかに失敗します。未知のキーはたいてい致命的にならず無視されるので、新しいバージョンのプログラム向けに書かれた設定ファイルは、たいてい古いバージョンでも動きます。代替の形式はもっと厳格で、正しさにとっては良いことですが、真夜中にゲームの設定を編集している人にとっては良くありません。

設定が文字列の平坦なセクション以上に育ったときです。入れ子構造、リスト、日付、数値であるべき数値、あるいは文字列の "false" とブール値の false の違いが問題になる値。これらはすべて、INI が役に立たなくなり、バグを隠し始める場所です。

TOML はまさにこの答えとして設計されました。見た目は INI に似ているので誰も新しい形を学び直す必要がなく、仕様と本物の型、定義された入れ子を持っています。YAML はもう一つのよくある選択肢で、より強力で、間違えやすさも大きく増します。ファイルが大きくなろうとしているなら、TOML は小さな一歩であり、INI を使う価値があった読みやすさを保ってくれる選択です。