WinAPI Unicode和ANSI函数

大多数WinAPI调用都有UnicodeANSI函数调用

考试:

 function MessageBoxA(hWnd: HWND; lpText, lpCaption: LPCSTR; uType: UINT): Integer; stdcall;external user32; function MessageBoxW(hWnd: HWND; lpText, lpCaption: LPCWSTR; uType: UINT): Integer; stdcall; external user32; 

什么时候应该使用ANSI函数而不是调用Unicode函数?

Solutions Collecting From Web of "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版本。

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