Loading article…
INI ファイルは、セクションごとに整理されたキーと値のペアで構成される構造と構文を持つプレーン テキストからなる、コンピュータ ソフトウェアの設定ファイルです。 [ 1 ]これらの設定ファイルの名前は、このソフトウェア設定方法を普及させたMS-DOSオペレーティングシステムで使用されていた、 initializationの略であるファイル拡張子INIに由来しています。この形式は、多くの設定のコンテキストで非公式の標準となっていますが、他のオペレーティングシステム上の多くのアプリケーションでは、confやcfgなど、異なるファイル拡張子を使用しています。[ 2 ]
Windowsにおけるソフトウェア構成の主要なメカニズムは、元々はテキスト ファイル形式で、1 行につき 1 つのキーと値のペアを含むテキスト行がセクションに整理されていました。この形式は、デバイス ドライバ、フォント、スタートアップ ランチャーなどのオペレーティングシステム コンポーネントに使用されていました。INI ファイルは、アプリケーションが個々の設定を保存するためにも一般的に使用されていました。[ 3 ]
この形式は、 Windows 3.1xまでの16 ビットMicrosoft Windowsプラットフォームで維持されていました。Windows 95以降、 Microsoft はWindows レジストリの使用を推奨し、開発者が構成に INI ファイルを使用しないように促し始めました。それ以降のすべてのバージョンの Windows では、システム構成に Windows レジストリが使用されていますが、.NET Framework で構築されたアプリケーションは特別なXML .configファイルを使用します。初期化ファイル関数は Windows に引き続き搭載されており、開発者は引き続き使用できます。
Windowsソフトウェア以外にも、プラットフォームに依存しないソフトウェアが設定ファイルにこのファイル形式を使用する場合があります。Unix系の設定ファイルの中にも同様の形式を使用するものがあります。INI形式は人間が読みやすく、解析も容易なため、それほど複雑な設定を必要としない設定ファイルに適した形式です。
以下は、INIファイルが存在する場所の網羅的ではないリストです。
Desktop.iniWindowsでは、フォルダのアイコンを指定するなど、ディレクトリのプロパティを設定するためにファイルが引き続き使用されています。[ 4 ] [ 5 ]php.iniファイルは INI 形式を採用しています。[ 6 ] [ 7 ].git/configファイルは INI 形式で記述されています。[ 8 ]*.desktopエントリは INI 形式で記述されます。[ 9 ]*.serviceユニット設定ファイルは INI 形式で書き込まれます。[ 10 ]afp.confファイルは INI スタイルの設定言語で記述されています。[ 11 ]pacman.confファイルはINI形式で記述されています。[ 12 ]app.ini設定ファイルは INI 形式で記述されています。[ 13 ].editorconfig設定ファイルは INI 形式で記述されています。[ 14 ]以下のサンプルファイルには、ソフトウェアの所有者用と給与データベースへの接続用の2つのセクションがあります。コメントには、ファイルを最後に変更したユーザーと変更理由が記録されます。
; 最終更新日 2001 年 4 月 1 日、John Doe [所有者]名前= John Doe組織= Acme Widgets Inc.[データベース] ; ネットワーク名解決が機能しない場合はIPアドレスを使用しますserver = 192.0.2.62 port = 143 file = "payroll.dat"より広い意味では、INIは非公式なフォーマットであり、アドホックな実装に適しており、人間による設定も可能です。そのため、INIの方言と呼ばれる、さまざまな仕様（場合によってはパーサーの実装のみが記述されている）が存在します。
INIの解釈は、空白の保持、フィールド型の情報、大文字小文字の区別、推奨されるコメント区切り文字など、個人の好みやコンピューティング環境のニーズに大きく依存します。そのため、INIは多様な形態に分かれやすい傾向があります。とはいえ、INIの実装は一般的に共通の設計上の特徴を備えています。それは、各行にキーと値のペアがあり、等号で区切られ、角括弧で示されるセクションに整理されたテキストファイルです。
最も複雑な解釈では、INI形式は任意のS式を表現することができ、 XMLやJSONのような標準化された形式と同等の性能を持ちますが、構文は固定されておらず、人によってはより使いやすく感じるかもしれません。
INIファイル形式は厳密に定義されていないため、多くのパーサーは共通のコアを構成する機能以外にも機能をサポートしています。実装されているサポートは非常に不安定です。できるだけ多くの方言をサポートできるパーサーを作成する試みが行われてきました。[ 15 ]
INI のデータは、キーまたはプロパティと呼ばれるキーと値のペアで保持されます。キーは、キーと値のペア全体を指す場合もあれば、キーのみを指す場合もあります。値はプロパティ名とも呼ばれます。テキスト表現では、キーと値のペアは、値の開始が区切り文字で示される 1 行または複数行で表されます。区切り文字は、多くの場合等号( =、ASCII 0x3D ) ですが、コロン ( :、ASCII 0x3A ) や空白 (GNU 環境ではまれに使用される[ 15 ] ) の場合もあります。キーのキーは区切り文字の左側に表示され、多くの場合空ではなく、区切り文字を含めてはいけません。一部のフレーバーでは、値にエスケープ シーケンスを許可しています。
Windows の実装では、等号とセミコロンは予約文字であり、キーに含めることはできません。キーの周囲の空白はパーサーによって削除されます。値には任意の文字を含めることができます (Windows スタイルでは、区切り文字の周囲に空白はありません: 例: IconFile=Folder.ico)。
キーと値のペアは、テキストでは次のようになります。
key = key=v name = value sem = ; semver = v5822.433.2キーと値のペアは、セクションの下にグループ化できます。INI の方言によっては、すべてのキーと値のペアがセクション内にある必要があるものもあれば、いわゆるグローバル プロパティを許可しているものもあります。[ 16 ]キーと値のペアがグループ化されている場合、セクション名は角括弧( [、ASCII 0x5B、および]、ASCII 0x5D) で囲まれ、行に単独で表示され、別のセクションが宣言されるまで、後続の行のすべてのキーと値のペアに適用されます。明示的な「セクションの終了」区切り文字 (たとえば XML の など) はありません。したがって、セクションは構文的に任意にネストすることはできません。必要な場合は、階層をフラット化して、セクション名 (多くの場合 、ASCII 0x2E) 内にカスタム区切り文字を連結することでネストを実装できます。多くの場合、サブセクションと呼ばれる 1 レベルのネストがサポートされています。</tag>.
ネストされたセクションを使用したINIファイルの例：
[プロジェクト]名前=果樹園レンタルサービス（アプリ付き）対象地域= "ベイエリア" ; TODO: 空席を広告する法務チーム= (空席)[果物「リンゴ」]商標問題＝予見可能味＝既知[果物.日付]味=斬新商標問題= 「本当にありそうもない」[果物「ラズベリー」]予想される問題= 「物流（壊れやすい果物）」商標問題= \ 可能性あり[fruit.raspberry.proponents.fred] date = 2021-11-23, 08:54 +0900 comment = "赤い果物が好きです。" [fruit "Date/proponents/alfred"] comment :なぜですか、 \ \ \ 私はデーツを買います。# folding: "\\\\\nn" は "\\n" または "\n" として解釈されますか? # または "\\\\" は折りたたみを妨げますか? editor =私の名前には \ \ 改行が含まれている可能性があります。一部のパーサーは、ドットをパス区切り文字として使用して、セクションのネストを許可します。
[セクション]ドメイン= example.com[セクション.サブセクション] foo =バー場合によっては相対的なネストもサポートされており、先頭のドットは前のセクションへのネストを表します。[ 15 ]
[セクション]ドメイン= example.com[.subsection] foo = bar歴史的に、ドット以外の方法でネストを表現する方法も存在していました（たとえば、IBM の Microsoft Windows 用ドライバ ファイルdevlist.iniでは、ネスト区切り文字として ; の形式でバックスラッシュ[A\B\C]が使用されていました。また、Microsoft Visual Studio のファイルでは、とAEMANAGR.INIの形式でまったく異なる構文が使用されていました）。一部のパーサーはネストをまったくサポートしておらず、階層構造を認識しませんでしたが、 が一意の識別子であるという事実を利用することで、ネストを部分的にエミュレートすることができました。[A]B,C,P = V[A.B.C]
Windows のセクション名とプロパティ名は大文字小文字を区別しません。[ 17 ]ほとんどの Unix スタイルの INI の解釈では、大文字小文字の区別を完全に禁止していますが、セクション名[ 18 ]またはキー[ 19 ]の大文字小文字の区別は許可される場合があります。
連続する末尾の空白文字の後にセミコロン( ;、ASCII 0x3E )が続く行はコメントを示します。一部の INI 方言では、 Unixシェルのコメントと同様に、コメントを示すために番号記号( #、ASCII 0x23 )を使用することもできます。一部の INI 方言では、キーと値のペアの行またはセクションの行にコメント (インライン コメントと呼ばれます) を記述できますが、すべてではありません。一部の方言では、値またはセクションの閉じ括弧とコメントの間に空白文字が必要です。ただし、一部の方言では、番号記号がキー名に含まれていても、そのように無視される場合があります。コメント行は、パーサーによって無視されるように設計されています。
#! /bin/convert-ini-to-perl | perl | ssh wikipedia.org upload --sanitise=no ; INI 方言に関するさらなる知識がないと曖昧です: ; 値は「live」ですか、それとも「live # dangerously」ですか?私は= live # dangerously が好きです#var = avar = a ; これはインラインコメントですfoo = bar # これは別のインラインコメントですWinAPIのGetPrivateProfileStringの仕様では、コメントは単独の行に記述する必要があります。
セクション内のプロパティの順序と、ファイル内のセクションの順序は関係ありません。
ほとんどの実装では、セクション内に指定された名前のプロパティを1つだけ持つことしかサポートしていません。プロパティ名が2回目に出現すると、処理が中断されるか、無視される（値が破棄される）、または最初の出現が上書きされる（最初の値が破棄される）可能性があります。一部のプログラムでは、重複したプロパティ名を使用して複数値プロパティを実装しています。
同じ名前のセクション宣言が複数ある場合の解釈も様々です。実装によっては、重複するセクションは、あたかも連続して存在するかのように、そのプロパティを単純にマージします。一方、INIファイルの一部の要素を破棄したり無視したりする実装もあります。
実装によっては、値を引用符で囲むことが許可されており、通常は二重引用符やアポストロフィが使用されます。これにより、空白文字を明示的に宣言したり、特殊文字（等号、セミコロンなど）を引用符で囲んだりすることが可能になります。標準のWindows関数GetPrivateProfileStringはこの機能をサポートしており、値を囲む引用符を削除します。
C言語の構文を模倣して、一部の言語では、\行末の文字としてバックスラッシュ（ASCII 0x5C）を使用することで行を折り返すことができます。 [ 20 ]このような行の継続では、バックスラッシュの直後にEOL（行末）が続くと、バックスラッシュと改行が削除され、ドキュメントの行が論理的な行に変換されます。
一部の方言では、文字エスケープのサポートが異なり、通常はメタ文字としてバックスラッシュ文字（\、ASCII 0x5C）を使用し、C構文をエミュレートしています。[ 21 ]
エスケープシーケンスを盲目的に解釈するのは賢明ではありません。仕様によっては、一般的なエスケープシーケンスのメタ文字を明示的にミュートしているものもあるからです。[ 22 ] [ 23 ]
Windowsでは、プロファイルAPIは、従来のWindowsファイルから設定を読み書きするために使用されるプログラミングインターフェイスです.ini。たとえば、GetPrivateProfileString関数は、初期化ファイル内の指定されたセクションから文字列を取得します。（「プライベート」プロファイルは、 WIN.INIGetProfileStringから取得するプロファイルとは対照的です。）
以下のサンプルCプログラムは、上記のサンプルINIファイルからプロパティ値を読み込む方法を示しています（設定ファイルの名前を としますdbsettings.ini）。
#include <windows.h>int main ( int argc , TCHAR * argv []){TCHAR dbserver [ 1000 ];int dbport ;GetPrivateProfileString ( TEXT ( "database" ), TEXT ( "server" ), TEXT ( "127.0.0.1" ), dbserver , sizeof ( dbserver ) / sizeof ( dbserver [ 0 ]), TEXT ( ". \\ dbsettings.ini" ));dbport = GetPrivateProfileInt ( TEXT ( "database" ), TEXT ( "port" ), 143 , TEXT ( ". \\ dbsettings.ini" ));// 注: WritePrivateProfileInt() は存在せず、WritePrivateProfileString() のみ存在します。0を返す;}関数の 3 番目のパラメータはGetPrivateProfileStringデフォルト値であり、上記の 2 つの関数呼び出しではそれぞれ と です"127.0.0.1"。143このパラメータに が指定された場合NULL、デフォルト値は空の文字列 になります""。
Unix環境では、INIファイルにアクセスするためのさまざまな設定ライブラリが存在します。これらは多くの場合、フレームワークやツールキットに既に組み込まれています。Unix用のINIパーサーの例としては、GLib、iniparser、libconfiniなどがあります。
初期化ファイルマッピングは、INI ファイルとWindows レジストリ間のマッピングを作成します。[ 59 ] [ 60 ]これは、従来の.iniファイルでの設定の保存から新しいレジストリへの移行方法として、Windows NT および Windows 95 で導入されました。ファイルマッピングは、プロファイル API 呼び出しを捕捉し、IniFileMappingレジストリセクションの設定を使用して、読み取りと書き込みをレジストリ内の適切な場所に誘導します。
以下の例を使用すると、例えばdbsettings.iniという設定ファイルからownerセクションのnameキーを取得する文字列呼び出しを行うことができます。返される値は文字列 "John Doe": になります。
GetPrivateProfileString ( "owner" , "name" , ... , "c:\\programs\\oldprogram\\dbsettings.ini" );INIマッピングでは、このプロファイルAPI呼び出しを受け取り、指定されたファイル名内のパスを無視し、ディレクトリの下にファイル名に一致するレジストリキーが存在するかどうかを確認します。
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping これが存在する場合、要求されたセクションに一致するエントリ名が検索されます。エントリが見つかった場合、INIマッピングはその値をレジストリの別の部分へのポインタとして使用します。そして、レジストリのその部分で要求されたINI設定を検索します。
一致するエントリ名が見つからず、かつ（デフォルト）エントリ名の下にエントリが存在する場合、INIマッピングはそちらを使用します。したがって、各セクション名ごとに個別のエントリを作成する必要はありません。
この場合、[owner]セクションのプロファイル呼び出しは以下のようにマッピングされます。
ここで、「name」レジストリエントリ名が要求されたINIキーと一致することが確認されます。次に、「John Doe」の値がProfile呼び出しに返されます。この場合、デフォルト値の@プレフィックスにより、ディスク上のdbsettings.iniファイルへの読み取りが防止されます。結果として、レジストリに見つからない設定はINIファイルで検索されません。
「データベース」レジストリエントリの値には「@」プレフィックスが付いていません。そのため、この[database]セクションのみ、レジストリの設定が最初に適用され、次にディスク上のdbsettings.iniファイルの設定が適用されます。
Windows 95以降、MicrosoftはINIファイルよりもWindowsレジストリの使用を強く推奨し始めました。[ 61 ] INIファイルは通常2つのレベル（セクションとプロパティ）に制限されており、バイナリデータをうまく処理できません。しかし、レジストリはモノリシックで不透明かつバイナリであり、ファイルシステムと同期する必要があり、オペレーティングシステムの単一障害点となるため、この決定は批判を免れていません。 [ 62 ]
その後、XMLベースの設定ファイルが、テキストファイルに設定情報をエンコードするための一般的な選択肢となった。XMLは、任意の複雑な階層構造やネスト構造を可能にし、バイナリデータをエンコードするための標準的なメカニズムを備えている。
近年では、JSON、TOML、YAMLなどのデータシリアル化フォーマットが設定フォーマットとして利用されるようになった。これら3つの代替フォーマットは任意にネストできるが、INIとは異なる構文を持つ。中でもTOMLはINIに最もよく似ているが、TOMLをINIの大部分と意図的に互換性を持たせるというアイデアは却下された。[ 63 ]
しかし、最新のINIパーサーは、XML、JSON、TOML、YAMLのように任意の深さのネストも許可し、型付き値とUnicodeの同等のサポートを提供するが、同じことを表現するための複数の構文を許可することでINIファイルの非公式なステータスを維持している。[ 64 ]
php.ini」 a次の例の凡例を参照してください。[セクション] #a=a b=b
java.util.Propertiesparse_ini_file()