1

unicodeファイルとiniファイルに関してはすでに質問がありますが、それらの多くはドメイン固有のものです。ですから、その答えが一般的なケースに当てはまるかどうかはわかりません。

動機：いくつかの数値やいくつかの文字列などの単純なデータを格納するためにiniファイルを使用したいと思います。文字列はユーザ​​ーによって提供されます（GUIを介して入力）。ソフトウェアは世界中のどこでも実行でき、どの言語でも使用できます。ファイルはユーザー間で共有することもできます（したがって、あるシステムでの書き込み、別のシステムでの読み取りなどが可能です）。

私は、iniファイルのUnicodeは、GetPrivateProfileStringWandを使用するときに問題がないはずだと考えましたWritePrivateProfileStringW（私はシステム> = Windows XPをターゲットにしています）。

しかし、それから私はこの質問の答えに出くわしました。

引用：

WritePrivateProfileStringW関数は、レガシーサポート関数であるため、レガシーシステムエンコーディング（たとえば、日本のシステムではShift-JIS）でINIファイルを書き込みます。完全にUnicode対応のINIファイルが必要な場合は、外部ライブラリを使用する必要があります。

今はよくわかりません-心配する必要がありますか？または、先に進んでiniファイルを使用できますか？

編集：

ランダムなエンコードを回避するための鍵は、BOMを含む空のファイルを準備してから、このファイルを使用することであると思われます。誰か（ポジティブ/ネガティブ）これを経験したことがありますか？

4

2 に答える 2

1

問題は、実際にはiniファイルの使用ではなく、それらのファイルの読み取りと書き込みに使用する関数にあります。

お気づきのように、ファイルにデータをWritePrivateProfileStringW()書き込みません。UNICODE代わりに、システムで標準のマルチバイトエンコーディングを使用します。つまりini、日本のシステムで作成されたファイルは、ロシアのシステムでは読み取れません。逆もまた真です。

ファイルが異なるエンコーディングのシステムで共有されることを意図していない場合は、問題ありません。それ以外の場合は、iniファイルを使用するのではなく、XMLなどのより認識されたUNICODEテクノロジを使用する必要があります。XMLUTF-8のエンコーディングは、すべてのプラットフォームでデフォルトになっています。

于 2010-10-20T09:34:44.127 に答える
1

答えは次のとおりです。はい、ファイルがすでに存在するかどうか、および（存在する場合）そのコンテンツがどのようにエンコードされているかによっては、問題が発生する可能性があります。

iniファイルの内容がすでにUnicodeである場合、そのファイルはUnicodeとして扱われます。内部的には、これはIsTextUnicode関数によって決定されるようです。そして、この関数の場合、ファイル内の適切なBOMは、Unicodeに対する大きなヒントとして機能します。したがって、WritePrivateProfileStringWを使用するだけでは、Unicodeをiniファイルに確実に書き込むことはできず、代わりにファイルを準備する必要があります。

出典：MichaelKaplanのブログ

于 2012-02-22T08:40:51.760 に答える