已经存在有关 unicode 和 ini 文件的问题，但其中许多问题都是特定于域的。所以我不确定这个答案是否可以应用于一般情况。
动机：我想使用 ini 文件来存储简单的数据，例如一些数字和一些字符串。字符串由用户提供（通过 GUI 输入）。该软件可以在世界任何地方运行，可以使用任何语言。这些文件还可以在用户之间共享（因此可以在一个系统上写入它们，在另一个系统上读取等等）。
我认为ini文件中的unicode在使用时应该没有问题GetPrivateProfileStringW and WritePrivateProfileStringW（我的目标系统>= Windows XP）。
但后来我偶然发现了一个答案这个问题 https://stackoverflow.com/questions/204241/how-to-read-write-chinese-japanese-characters-from-to-ini-files.
Quote:
WritePrivateProfileStringW 函数将以旧系统编码（例如日语系统上的 Shift-JIS）写入 INI 文件，因为它是旧支持函数。如果您想要拥有完全支持 Unicode 的 INI 文件，则需要使用外部库。
我现在不确定——我需要担心吗？或者我可以继续使用 ini 文件吗？
Edit:
看来避免随机编码的关键可能是准备一个包含 BOM 的空文件，然后使用该文件。有没有人（积极/消极）有过这样的经历？
问题并不在于使用ini文件，但具有您将用来读取和写入这些文件的功能。
正如你所注意到的，WritePrivateProfileStringW()不会写UNICODE数据到文件。相反，它将使用系统上标准的任何多字节编码。这意味着ini在日语系统上创建的文件在俄语系统上无法读取。反之亦然。
如果文件不打算由具有不同编码的系统共享，那就没问题。否则，也许你不应该使用ini文件，但更多UNICODE- 感知技术，例如XML http://en.wikipedia.org/wiki/XML，其编码默认为UTF-8在所有平台上。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
