構成ファイルに推奨されるXML以外の何かを使用していますか？

ある種の構成ファイルを必要とする小さなツールを設計しています。私の場合、構成ファイルは実際にはデータベースに近いものですが、軽量である必要があり、必要に応じてエンドユーザーが簡単に編集できるようにする必要があります。ただし、その中にも多くのものが含まれます。（特定の要因に応じて、1Mb以上になる場合があります）

SQLiteなどを使用するのではなく、プレーンテキストを使用することにしました。ただし、テキストを使用する場合は、さまざまな形式にも対応する必要があります。これまでのところ、私の選択肢は

• XML
• JSON
• カスタムフォーマット

私のファイルのデータは非常にシンプルで、ほとんどの部分はキーと値のタイプのものです。したがって、カスタム形式はそれほど難しくありません...しかし、サポートの作成について心配する必要はありません。JSONが構成ファイルに使用されるのを見たことがありません。XMLはファイルサイズを大幅に膨らませると思います。（私はまた、一般的にXMLが嫌いです）。

この場合、どうすればよいですか？

考慮すべき要素：

• この構成ファイルはWebサービスにアップロードできます（サイズが重要です）
• ユーザーは必要に応じて手動で編集できる必要があります（編集や読みやすさの問題）
• 自動的に生成および処理できる必要があります（速度はそれほど重要ではありませんが、過度に遅くはなりません）
• 「キー」と「値」はプレーンな文字列ですが、何でも含めることができるためエスケープする必要があります。（ユニコードとエスケープは簡単に機能する必要があります）
• 複数の構成ファイル。基本的に、各設定ファイルは1つの「プロジェクト」に関連付けられています

YAMLはあなたのケースに最適だと思います。私の理解では、YAMLは、手動で編集する必要がある構成ファイルの事実上の標準形式です。多くのプログラミング言語には、YAMLを読み書きするためのライブラリがあります。JSONはYAMLと密接に関連していますが、YAMLよりも書き方が少し簡単で、Webサーバーとクライアントプログラム間の通信により多く使用されます。

JSONを使用すると、構成の一部をコメント化して別のことを試すことができなくなります。私にとって、それは取引ブレーカーです。

また、ユーザーがカスタマイズするためのコメント付きのサンプル構成ファイルを提供できないことも意味します。

XMLは標準であり、スキーマを提供できる場合は、ユーザーに感謝します。

要件を検討し、XMLが嫌いなことに気づいたら、JSONを使用することをお勧めします。私はXMLとJSONしか扱っていないことを認めざるを得ないので、他の一般的な構成フォーマットについて話すことはできません。

JSONは本当に書きやすく、正しくフォーマットされていれば読みやすいです。Googleは、ツールで構成を使用するためにJSONを愛しています。また、JavaScriptはそれをネイティブにオブジェクトに変換できます。

「プロパティ」ファイルは、フォーマット自体がキー/値であるため、キー/値に適しています。キー/値ごとに1行です。行の最初の=記号は、キーと値を分割します。

フォーマットは「=」区切り文字と改行文字だけなので、同等のXMLファイルよりも小さくなります。XMLファイルでは、マークアップはコンテンツ自体と同じだけのスペースを取ることができます。それは文字通り1MBと2MBのアップロードの違いを意味するかもしれません。圧縮は役立ちますが、小さく始めればまだ先です。

既存のライブラリは、プロパティファイルへのアクセスを処理できます。しかし、それはあなたが数分であなた自身のものを作ることができるのでとても簡単です。1時間以内にベルとホイッスル。

IP=11.22.33.44
BuildNumber=5.02.004
MaxFrameRate=50

すでにここでいくつかの良い答えがあります。しかし、私があなたの立場にいる場合、XMLを投入する前に、次の点を検討します。

• XMLは.NETフレームワークとサードパーティツールで非常によくサポートされています。JSONの場合、サードパーティライブラリを選択して、それがすべての要件を満たしているかどうかを確認する必要があります。

• 少数の例外的な場合にのみ手動で編集する必要がある場合、XMLはおそらくあなたのニーズに影響します。多くの編集が必要で、構成オプションのリストに特定の複雑さがある場合、ユーザーはおそらく何らかのダイアログベースのオプション/構成アプリケーションを必要とします。つまり、基になるXML形式が100であるかどうかは問題ではありません。 ％ 使いやすい。そのようなことを書きたくない場合は、少なくとも、何らかのXMLエディターをユーザーに勧めることができます。などのツールXMLのメモ帳やメモ帳++用XMLツール多くの人々のために働きます。

• エンドユーザーが以前にある種のXMLを目にした可能性は、JSONを以前に見た可能性よりも高いと思います。これにより、（本当に必要な場合に）把握しやすくなります。

• JSONはコメントをサポートしていないため、手動での編集は面倒です

• データをWebサービスにアップロードする際にサイズが本当に問題になる場合は、データ圧縮の使用を検討してください

実際、この点について考えて、とにかくXMLを使用したくない場合は、代わりにJSONを使用してください。XMLまたはJSONを使用すると、文字列をエスケープする標準的な方法、後で構成構造を拡張する標準的な方法、およびこれらの形式を読み書きするための既成のライブラリが提供されます。「カスタム形式」でホイールを作り直す必要はありません。

設定ファイルに関する限り、「1Mb以上」は確かに大きな側面であり、文字列をエスケープして多くの一致する引用符を維持する必要性は、人間にはうまく機能しません。そのため、人間が管理する必要のある大きな構成ファイルの場合は、カスタム形式の定義とカスタムパーサーの構築を検討する必要があります。人間がXMLを書かなければならないというテーマに関する記事は次のとおりです。人間はXMLを理解する必要はありません。

パーサーとパーサージェネレーターがまだ初期の段階にあった場合、カスタム言語の作成は複雑すぎると言うことで、カスタムパーサーを作成しないことを正当化できます。今優秀で、非常に単純なパーサジェネレータが成熟していること、言い訳はありません：あなたはそれがXMLベースの言語のパーサを構築するためにあなたを取るでしょう、時間と同等に、数時間のうちにカスタムパーサーを構築することができます^*。

これは、ANTLRを使用してカスタムパーサーを構築するプロセスを説明する小さなチュートリアルです。これはJavaですが、ANTLRはC＃もサポートしています。

JSONは、その柔軟性、プログラム外での読み取りと編集の容易さ、JSONをサポートするための解析ライブラリーの幅広い可用性のための良い選択です。それは階層をサポートし、単純にデータを順番に保存するファイルがしない単純な前方/後方互換性に役立ちます。また、Javaクラスとファイルデータとの間で変換し、その逆を行う簡単な手法もあると思います。多くの人がこのフォーマットを知ってコーディングしています。このフォーマットは、将来使用する可能性のある他のプログラムにとって重要です。

多くのシステムは.ini形式に基づいており、パーサーを最初から作成した場合は、簡単に解析できます。

csvはコーディングが迅速で、オーバーヘッドはほとんどありませんが、柔軟性、前方/後方互換性に問題があります。

レジストリの使用は、Windowsでは一般的な慣習でした。

Cookieの使用はWeb開発では一般的です。

ユーティリティ関数の場合、コマンドラインオプションと一致する自由形式のテキストを使用し、それを読み込んで、そこからargv文字列配列を作成します。

XMLを使用しないでください。

XMLはマークアップ言語です。シリアライゼーションまたは構成言語に使用する場合、XMLには基本的な問題があります。つまり、要素の属性とテキストコンテンツが同じものを記述できるということです。属性とテキストコンテンツのどちらかを決定する必要があります。さらに、XMLは不必要に冗長であり、たとえば要素名を2回指定する（開く、閉じる）必要があります。

マークアップ言語として、XMLの意味するところを使用してください。構成ファイルにはマークアップ言語は必要ありません。

JSONも使用しないでください。

JSONはデータのシリアル化形式として素晴らしいです。ただし、JSONにはコメントがありません。それは、私にとって、取引ブレーカーです。さらに、出現するすべての"文字をエスケープする必要があります。

INIは使用しないでください。

INIファイルには根本的な問題があります。ネストされたデータ構造が欠如しています。ネストの唯一の概念は、タグがいくつかの属性を持つことができるということです。これはネストの1レベルにすぎません。実際の使用例では、この制限が非常に迷惑であることがわかりました。私は、構成がINIファイルにあるプロジェクトの一部として働いていました。

可能であれば、カスタム言語を使用してください。

LexやYaccなどのパーサージェネレーターツールにアクセスできる場合は、カスタム言語を使用してください。.NETのパーサージェネレーターの状態がどうなるかわかりませんが、Cコードの場合は、Lex＆Yaccを選択します。最初の学習曲線は少し急かもしれません（LexとYaccは使いやすいツールではありません）が、学習に費やされた時間はそれだけの価値があります。

カスタム言語を使用できない場合は、YAMLを使用してください。

Y AMLは、名前のように、言うA in't メートル ARKUP リットルの anguageを。これは、コメントをサポートしているため、構成ファイルで許容されるプロパティが原因で発生するシリアル化言語です。YAMLはXMLのように不必要に冗長ではありません。要素名を2回指定する必要はありません（open、close）。YAMLには、XMLの属性とテキストコンテンツの問題はありません。

pro.per.ty = valueも検討してください。

入れ子がサポートされているINIのような構成が必要な場合は、pro.per.ty=valueペア（キーと値のペア）で構成される形式を検討してください。キーは.、区切り文字として文字を使用して、いくつかの入れ子のレベルを持つことができます。