将unicodestring存储在ini文件中时是否会出现与编码相关的问题?

目前已经有关于unicode和ini文件的问题,但是其中很多是针对特定领域的。 所以我不确定这个答案是否适用于一般情况。

动机 :我想使用ini文件来存储简单的数据,如一些数字和一些string。 string由用户提供(通过GUIinput)。 该软件可以运行在世界任何地方,任何语言都可以使用。 这些文件也可以在用户之间共享(这样他们可以写在一个系统上,在另一个系统上阅读等等)。

我认为在使用GetPrivateProfileStringWWritePrivateProfileStringW (我的目标系统> = Windows XP)时,ini文件中的unicode应该没有问题。

但后来我偶然发现了这个问题的答案。

引用:

WritePrivateProfileStringW函数将使用传统系统编码(例如,日文系统上的Shift-JIS)编写INI文件,因为它是传统的支持function。 如果你想有一个完全支持Unicode的INI文件,你将需要使用一个外部库。

我现在不确定 – 我必须担心吗? 或者我可以继续使用ini文件?

编辑:

似乎避免随机编码的关键可能是准备一个包含BOM的空文件,然后使用这个文件。 有没有人(正面/负面)的经验呢?

问题不在于使用ini文件,而是使用读取和写入这些文件的函数。

如您注意到的, WritePrivateProfileStringW()不会将UNICODE数据写入文件。 相反,它将使用系统上标准的任何多字节编码。 这意味着在日文系统上创建的ini文件在俄文系统上不可读。 反过来也是如此。

如果这些文件不打算由不同编码的系统共享,那么你会没事的。 否则,也许你不应该使用ini文件,而应该使用更多的UNICODE技术,比如XML ,其编码在所有平台上默认为UTF-8

答案是:是的,根据文件是否已经存在以及(如果存在)内容是如何编码的,可能会有问题。

如果一个ini文件的内容已经是Unicode,那么这个文件将被视为Unicode。 在内部,这似乎是由IsTextUnicode函数确定的。 而对于这个功能来说,文件中正确的BOM就是对Unicode的一个很大的暗示。 所以只需使用WritePrivateProfileStringW就不能确保将Unicode编码到ini文件中,而是必须准备文件。

来源: 迈克尔·卡普兰的博客