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

Question

基于C的Win32 API具有许多功能的双重版本，以支持Unicode(UTF-16)字符串和较旧的8位代码页字符串。该API还定义了通用函数和类型，以对这些函数和类型进行某种程度的抽象，并允许从同一代码库编译两个版本。

Microsoft建议始终使用泛型(请参阅Conventions for Function Prototypes)，以便可以编译两个版本。但是我的问题是-我们讨论通过8位字符串API在此处支持哪些版本的Windows？如果是Windows 95，我的优先级就不再高了:)。如果泛型仅用于支持极端遗留情况，则直接使用UTF-16调用似乎更容易，更清晰。

Answer 1

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

我将从解释Windows支持的三种字符串文本编码开始:

“ANSI” = 8位编码-C中的char。尽管名称为“ANSI”，但它不是ASCII不一定是任何特定的ANSI编码也不是ASCII，但是无论当前的语言环境/代码页是什么。

“MBCS” =多字节字符集编码-C语言中的char(其中每个字节都是char。受支持的代码页列表是有限的，并且至关重要的是，该列表不包括UTF-8。请参阅此QA:Difference between MBCS and UTF-8 on Windows)。 MBCS在现代Windows中已过时，不应在新项目中使用。

“Unicode” = UTF-16(或NT3/NT4中的UCS-2)-C语言中的wchar_t，为16位。

在UCS-2下，只能使用由代码点0x0000-0xFFFF表示的字符。超出此范围的字符不能使用。

在UTF-16(Windows 2000及更高版本)中，0xFFFF之后的代码点由2个或更多wchar_t值(4个或更多字节)表示，称为代理对，这意味着字符串的二进制长度(以字节为单位)不是必须与字符串的元素长度成正比(在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函数被 stub 并在调用时返回失败代码-相同的行为如Windows 95上的“完整” Win32所示。

Windows 95、98，Me:

在Windows 9x(95、98，Me)上实现的Win32不支持UTF-16，仅支持“ANSI”或“MBCS”字符串。

重要说明是，与Win32s一样， "Wide-character" functions do exist on Windows 9x, but they are stubbed out and when called will return failure codes- a handful of Resource, Command-line and MessageBox-related functions除外，它可以处理UCS-2字符串(例如 MessageBoxExW)。

支持非拉丁字符集需要弄乱代码页和不可思议的“多字节”编码选项(记住，不支持UTF-8- MultiByteToWideChar和 WideCharToMultiByte除外-可以用于将UTF-8转换为UTF-16)用于Win32 API)。

2001年，Microsoft发布了Windows 9x附加组件，称为Microsoft Unicode层(MSLU)，该附加组件将 W函数从failing-stubs更改为thunk代理，将字符串转换回8位格式，然后将其称为 A函数，因此明确使用 W函数的程序可以在Windows 9x上运行。

Windows NT

Windows NT从一开始就从NT 3.1(没有3.0版本)附带了 W函数，该函数接受 wchar_t类型的参数。字符串使用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)。