目前已经有关于unicode和ini文件的问题，但是其中很多是针对特定领域的。 所以我不确定这个答案是否适用于一般情况。
动机 ：我想使用ini文件来存储简单的数据，如一些数字和一些string。 string由用户提供（通过GUIinput）。 该软件可以运行在世界任何地方，任何语言都可以使用。 这些文件也可以在用户之间共享（这样他们可以写在一个系统上，在另一个系统上阅读等等）。
我认为在使用GetPrivateProfileStringW和WritePrivateProfileStringW （我的目标系统> = 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文件中，而是必须准备文件。
来源： 迈克尔·卡普兰的博客