哪些版本的Windows不支持unicode API调用？

Question

基于C的Win32 API具有许多函数的双重版本,以支持unicode(UTF-16)字符串和较旧的8位代码页字符串.API还定义了泛型函数和类型,以便稍微抽象出来并允许从同一代码库中编译这两个版本.

Microsoft建议始终使用泛型(请参阅函数原型的约定),以便您可以编译这两个版本.但我的问题是 - 通过8位字符串API,我们在这里讨论支持哪些版本的Windows？如果它是Windows 95,那么我的优先级就不再高了:).如果泛型仅用于支持极端遗留情况,那么直接使用UTF-16调用似乎更容易和更清晰.

Answer 1

维基百科有一篇详细的文章:https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows

我将首先解释Windows支持的三种类型的字符串文本编码:

1. "ANSI"= 8位编码 - char在C中.尽管名称为"ANSI",但这不是ASCII不一定是任何特定的ANSI编码,也不是ASCII,但无论当前的语言环境/代码页是什么.
2. "MBCS"=多字节字符集编码 - char在C中(每个字节是a char.支持的代​​码页列表是有限的,关键是这不包括UTF-8.请参阅此QA:Windows上MBCS和UTF-8之间的差异).MBCS在现代Windows中已弃用,不应在新项目中使用.
3. "Unicode"= UTF-16(或NT3/NT4中的UCS-2) - wchar_t在C中,为16位.
   • 下UCS-2只能由码点表示的字符0x0000- 0xFFFF都可以使用.不能使用此范围之外的字符.
   • 在UTF-16(Windows 2000及更高版本)中,后面的代码点0xFFFF由2个或更多wchar_t值(4个或更多字节)表示,称为代理对,这意味着字符串的二进制长度(以字节为单位)不一定是成正比的字符串的元素长度(in size_t),也不一定是打印字符的数量.
   • 还要考虑连字和变音符号之类的东西也会破坏编程代码经常产生的字节/元素/打印字符计数等价假设.
   • 作为示例,请考虑此代码点字符串: U+0061, U+0928, U+093F, U+4E9C, U+10083
     • 在UTF-16 Big-Endian字节中,这是 00 61 09 28 09 3F 4E 9C D8 00 DC 83
     • 这是12个字节
     • ......这是6个wchar_t元素
     • ...但代表5个字符
     • ...被渲染为4个打印字符(由于第2个和第3个字符之间的连接).

Windows 3.x.

Windows 3.x实现了严格为8位的16位Windows API.如果不运行en-US版本,它将使用当前的默认语言环境和代码页设置.它不支持宽字符,但可能支持某种MBCS.

Windows 3.x的"Win32子集"("Win32s")附加组件为Windows 3.x添加了一些Win32功能,包括A和W函数,但是这些W函数是存根的,并在调用时返回失败代码 - 与上面看到的行为相同Windows 95上的"完整"Win32.

Windows 95,98,Me:

Win32,在Windows 9x(95,98,Me)上实现,不支持UTF-16,仅支持"ANSI"或"MBCS"字符串.

一个重要的注意的是,与Win32s中,"宽字符"的功能就存在于Windows 9x中,但他们掐灭,并呼吁将返回故障代码时 -与外资源,命令行和MessageBox-一小撮处理UCS-2字符串的相关函数(例如MessageBoxExW).

支持非拉丁字符集需要乱用代码页和神秘的"多字节"编码选项(记住,不支持UTF-8 - 除了MultiByteToWideChar和WideCharToMultiByte- 可用于将UTF-8转换为UTF-16以供使用使用Win32 API).

2001年,微软发布了一个名为Microsoft Layer for Unicode(MSLU)的Windows 9x附加组件,它将W函数从失败的存根转换为thunking代理,后者将字符串转换回8位格式然后调用A函数,所以明确使用W函数的程序可以在Windows 9x上运行.

Windows NT

Windows NT,从一开始就使用NT 3.1(没有3.0版本)附带了W接受wchar_t-typed参数的函数.字符串用UCS-2(NT3,NT4)或UTF-16(NT5和更高版本)编码.Microsoft产品和文档通常使用"Unicode"作为UTF-16或UCS-2的简写.Win32不支持UTF-8(除了MultiByteToWideChar和WideCharToMultiByte),因此模糊性几乎无法通过.

Windows CE

Windows CE 1.0从一开始就支持UTF-16,考虑它的支持级别相当于Windows NT系列.我不知道CE或者是否支持UCS-2而不是UTF-16,或者从一开始就支持UTF-16.

简而言之:

OS                          ANSI | MBCS | UTF-16 ("Unicode")
-----------------------------------------------------------------------------
Windows 3.x (Stock)         Yes  |   ?  | No
Windows 3.x (Win32s)        Yes  |   ?  | Stubbed, always fails (a)
Windows 95, 98, ME          Yes  | Yes  | Limited support (b) otherwise fails
Windows 95, 98, ME (MSLU)   Yes  | Yes  | Yes, runtime thunked to ANSI (c)

Windows NT 3.x, NT 4.x      Yes  | Yes  | As UCS-2 instead of UTF-16 (d)
Windows 2000 and later      Yes  | Yes  | Yes

Windows CE 1.0 and later    Yes  |   ?  | Yes (e)

(a):https://msdn.microsoft.com/en-us/library/cc194796.aspx
(b):https://support.microsoft.com/en-us/kb/210341 (c):https: //en.wikipedia.org/wiki/Microsoft_Layer_for_Unicode
(d):https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows
(E):http://www.hpcfactor.com/support/windowsce/wce1.asp

结论:只使用"Unicode":即使您正在编写面向Windows 9x的软件,您也可以使用Unicode层,但它仍然可以运行(尽管像Unicode文件名和窗口标题这样的东西可能会很糟糕).您的代码也可以移植到Windows CE(我很惊讶地看到Windows CE从一开始就支持UTF-16).