ご回答ありがとうございます。この質問は、一見すると素朴に見えるかもしれませんが、それほど素朴ではありませんでした:)
個人的には、構成ファイルにXMLが嫌いです。人々が読んだり変更したりするのは難しいと思います。汎用的で強力なため、コンピューターが解析するのは難しいと思います。
INIファイルまたはJava適切なファイルは、ネストを必要とする最も基本的なアプリケーションにのみ適しています。これらの形式にネストを追加する一般的なソリューションは次のようになります。
level1.key1=value
level1.key2=value
level2.key1=value
見た目が良くなく、冗長性が多く、ノード間で物事を移動するのが難しい。
JSONは悪い言語ではありませんが、コンピューターが解析しやすいように設計されているため（有効なJavaScript）、構成ファイルにはあまり使用されていません。
[〜＃〜] json [〜＃〜] は次のようになります。
{"menu": {
"id": "file",
"value": "File",
"popup": {
"menuitem": [
{"value": "New", "onclick": "CreateNewDoc()"},
{"value": "Open", "onclick": "OpenDoc()"},
{"value": "Close", "onclick": "CloseDoc()"}
]
}
}}
私の意見では、コンマと引用符であまりにも雑然としている。
[〜＃〜] yaml [〜＃〜] は設定ファイルに適しています。サンプルを次に示します。
invoice: 34843
date : 2001-01-23
bill-to: &id001
given : Chris
family : Dumars
ただし、その構文はあまり好きではなく、空白を使用してスコープを定義すると、少し壊れやすくなります（ブロックを別のネストレベルに貼り付けることを考えてください）。
数日前、構成ファイル用に自分の言語を書き始めました。それを Swush と名付けました。
簡単なキーと値のペアとしてのサンプルを次に示します。
key:value
key:value2
key1:value3
またはより複雑でコメント付きとして
server{
connector{
protocol : http // HTTP or BlahTP
port : 8080 # server port
Host : localhost /* server Host name*/
}
log{
output{
file : /var/log/server.log
format : %t%s
}
}
}
Swushは、上記の単純な形式の文字列または引用符で囲まれた文字列をサポートします。これにより、文字列内に空白や改行を含めることができます。次のような配列をすぐに追加します。
name [1 2 b c "Delta force"]
Java実装がありますが、他の実装も歓迎します。:)。詳細については、サイトを確認してください（そのほとんどを取り上げましたが、Java APIはセレクターなどの興味深い機能を提供します）
これは重要な質問です。
ほとんどの代替手段（JSON、YAML、INIファイル））は、XMLよりも解析するのがeasierです。
また、Python-すべてがソースである場合-などの言語では、明確にラベル付けされたPythonモジュールに設定を置く方が簡単です。
それでも、XMLにはJSONやPythonよりも利点があると言う人もいます。
XMLについて重要なことは、アプリケーションに固有の構成ファイルを作成するときに、XML構文の「普遍性」が実際にはあまり適用されないことです。設定ファイルの移植性は重要ではないため、一部のPython人々はPythonで設定ファイルを記述します。
編集
構成ファイルのセキュリティは重要ではありません。 「PythonプログラムのPythonはセキュリティリスクです]」引数の設定では、Pythonは既にソースをインストールして実行しているのに、ソースを手に入れたときに設定ファイルで複雑なハックを処理するのはなぜですか？ソースをハックするだけです。
「誰か」が設定ファイルを介してあなたのアプリをハッキングできると言う人がいるのを聞いたことがあります。この「誰か」は誰ですか？ sysadmin？ DBA？開発者？構成ファイルにアクセスできる謎の「誰か」はあまりいません。
そして、悪意のある目的でPython構成ファイルをハッキングできる人は誰でも、キーロガー、偽の証明書、またはその他のより深刻な脅威をインストールする可能性があります。
- XMLは簡単に解析できます。ほとんどの言語で利用可能な、人気のある軽量で機能的な、および/または無料のXML解析ライブラリがいくつかあります。
- XMLは読みやすいです。それは非常に人間が読めるマークアップ言語であるため、人間が書くこともコンピュータが書くことも簡単です。
- XMLは適切に指定されています。皆と彼の犬はまともなXMLの書き方を知っているので、構文について混乱はありません。
- XMLが一般的です。その途中のどこかで、Important People™がXMLが「未来」であるという考えを推進し始め、多くの人々がXMLを購入しました。
- XMLは双方向形式です。つまり、空白、コメント、順序は保持されます。書式設定を保持したまま、プログラムでプログラムをロード、変更、および保存できます。これは、ユーザーがアプリケーションの構成に使用できるツールにとって重要です。これがXMLが最初に離陸した理由の1つです（世界はより技術的になったため、これは必要性が少なくなりました）。
- XMLには、オプションのスキーマ検証があります。ツールおよび複雑な構成形式にとって重要です。
- XMLには名前空間があります。これにより、解析に影響を与えることなく、他の構成または注釈を埋め込むことができます。他の構成形式では、これは通常、ハックの特別なコメントまたはプロパティ名のマングリングで行われます。
補足として、私はXMLを守るつもりはありません。それには用途があり、私はそれに戻るたびにプロジェクトでそれを使用します。しかし、多くの場合、特に構成ファイルには、標準化された形式であるという唯一の利点があり、これには多くの欠点（つまり冗長すぎる）がはるかに多いと思います。しかし、私の個人的な好みは重要ではありません-構成ファイル形式としてXMLを使用することを選択する人がいる理由に単に答えていました。私は個人的には決してしません。
XMLはクールでエンタープライズに聞こえるからです。
編集：コメントがenterpriseyの定義を要求するまで、私の答えがそれほど曖昧だとは思いませんでした。 引用ウィキペディア ：
[...]「エンタープライズ」という用語は、「小規模組織の過剰」という懸念を超えて、大規模組織でもソフトウェアが過度に複雑であり、よりシンプルで実績のあるソリューションが利用可能であることを意味します。
私のポイントは、XMLが流行語であり、それ自体が使い古されているということです。他の意見にも関わらず、XMLの解析は簡単ではありません（gzip圧縮されたソースパッケージが現在3MBを超えているlibxml2を見てください）。冗長性のため、手で書くことも面倒です。たとえば、他の実装を支持してjabberdの人気が低下した理由の1つとして、 WikipediaはXML構成をリストしています です。
XMLはよく開発され採用された標準であり、独自の構成形式よりも読みやすく、理解しやすくなっています。
また、XMLシリアル化は、ほとんどの言語で使用可能な一般的なツールであり、開発者がオブジェクトデータを非常に簡単に保存できることを理解する価値があります。他の誰かが既にあなたのために仕事をしているのに、なぜ複雑なデータの階層を保存する独自の方法を構築するのですか？
.NET： http://msdn.Microsoft.com/en-us/library/system.xml.serialization.aspx
PHP： http://us.php.net/serialize
Python： http://docs.python.org/library/pickle.html
Java： http://Java.Sun.com/developer/technicalArticles/Programming/serialization/
もう1つのポイントは、構成ファイルを記述するXSD（スキーマファイル）がある場合、アプリケーションが構成ファイルを検証することは簡単です。
XMLの解析は比較的簡単で、スキーマが明確に指定されていれば、どのユーティリティでも情報を簡単に読み書きできます。
まあ..、XMLは、記述、ネストされた情報、何かに関するデータを保持できる汎用仕様です。そして、それを解析して読むことができる多くのAPIとソフトウェアがあります。
そのため、クロスプラットフォームおよびアプリケーションで知られている形式的な方法で何かを記述するのは非常に簡単です。
他の回答で指定されなかった理由の1つは、Unicode /テキストエンコーディング/それに名前を付けることです。ファイルに中国語の文字列が必要ですか？問題ない。これは些細に聞こえるかもしれませんが、XMLが導入されたときにはそうではありませんでした。明らかにINIファイルにはありません。
もう1つ-リスト、辞書、または必要なものを備えた構造化データを作成できる可能性を最初に与えたのは、同時に機械処理可能で人間が編集できることです。
欠点もありますが、他に何を使用できますか？ Yamlは素晴らしく見えますが、ホワイトスペースを間違った場所に置いたり、気にしないツールをマージしたりすることで生じる問題をすべて想像しているので、作業中のプロジェクトに導入するのが怖いです。
XMLの主な利点とその人気の理由は、Java worldで人気があり、したがって、Javaまた、WebサービスとSOAPはxmlに基づいており、エンタープライズアプリケーションで多く使用されているためです。
そしてこれまでのところ、Ajaxアプリケーションを除いて、JSONおよびその他のすべての形式は業界でそれほどサポートされていません。また、JSONにはスキーマ言語やXMLのような定義された解析APIはありません。
大雑把に言っても、JSONは、少なくとも同じ方法ではなく、xmlが持っているもののトンを必要としません。
その理由は、XMLを使用すると、基本的に独自のセマンティックマークアップを作成できるためです。これは、事実上すべての言語で構築されたパーサーによって読み取ることができます。追加の利点は、XMLで記述された構成ファイルを、2つ以上の言語を使用しているプロジェクトで使用できることです。すべてが特定の言語の変数として定義されている構成ファイルを作成する場合、明らかにその言語でのみ機能します。