WinAPI Unicode和ANSI函数

最简单的规则是这样的。 仅在没有Unicode变体的系统上使用ANSI变体。 那是Windows 95,98和ME，它们是实现Win32并且不支持Unicode的Windows版本。

这些日子，你将不可能瞄准这样的版本，所以你应该总是使用Unicode变体。

就像发布的评论/答案（罕见）例外一样…

在预期和支持UTF-8的情况下，可以选择使用ANSI调用。 例如，控制台中的WriteConsoleA'ing UTF-8字符串设置为使用TT字体并在chcp 65001下运行。

另一个古怪的例外是主要以ANSI实现的函数，其中Unicode“W”变体简单地转换为活动代码页中的窄字符串并调用“A”对应字符。 对于这样的功能，当有一个窄的字符串可用时，直接调用“A”变量可以节省冗余的双重转换。 例如OutputDebugString，直到Windows 10才进入这个类别（我刚刚注意到了https://msdn.microsoft.com/en-us/library/windows/desktop/aa363362.aspx ，它提到了WaitForDebugEventEx自Windows 10以来可用 – 为OutputDebugStringW启用真正的Unicode输出）。

然后有API，即使处理字符串，本地ANSI。 例如，GetProcAddress只存在于采用LPCSTR参数的ANSI变体中，因为导出表中的名称是窄字符串。

也就是说，大部分与字符串相关的API都是原生的Unicode，鼓励使用“W”变体。 并非所有较新的API甚至都具有“A”变体（例如CommandLineToArgvW ）。 从马的嘴里https://msdn.microsoft.com/en-us/library/windows/desktop/ff381407.aspx ：

Windows本身支持用于UI元素，文件名等的Unicode字符串。 Unicode是首选的字符编码，因为它支持所有的字符集和语言。 Windows使用UTF-16编码表示Unicode字符，其中每个字符都被编码为16位值。 UTF-16字符被称为宽字符，以区别于8位ANSI字符。

当Microsoft向Windows引入Unicode支持时，通过提供两组平行的API（一组用于ANSI字符串而另一组用于Unicode字符串）缓解了转换。

[…]在内部，ANSI版本将字符串转换为Unicode。 Windows头文件还定义了一个宏，在预定义符号UNICODE被定义时解析为Unicode版本，否则定义为ANSI版本。

[…] Windows中大多数较新的API只有一个Unicode版本，没有相应的ANSI版本。

[注意] 这个帖子被编辑添加最后两段。