这些都是正确的吗?
是的,如果您不假设Unicode编码中不存在未编码的字符(对于大多数实际应用程序而言,这种假设是可以的)。
Windows 的"A"函数(例如SetWindowTextA)接受ASCII字符串吗?还是接受"多字节字符串"(下面还有更多问题)?
它们接受字节字符串(即其代码单元为字节的字符串,在Windows上始终是八位字节),这些字符串以当前的"ANSI"/MBCS/legacy编码进行编码。 "ANSI"是这些编码的历史术语,但并不正确。对于西方Windows系统,该编码通常为Windows-1252。
Windows 的"W"函数接受UTF-16字符串还是UCS-2字符串?我认为它们接受UCS-2,但名称让我感到困惑。
自Windows 2000以来,它们大多数支持UTF-16。选择"wide"和Microsoft术语的其余部分(例如,"Unicode"表示"UTF-16"或"UCS")是在现代Unicode标准统一术语之前的。
在WideCharToMultiByte中,Microsoft使用"wide-character string"这个词来表示UTF-16。那么什么被认为是"multi-byte string"? UTF-8?
在这个上下文中,WideCharToMultiByte支持的其他所有编码都是"多字节编码",包括Windows-1251和UTF-8。
LPWSTR是"宽字符字符串"吗?我会这样说,但那不是意味着它是UTF-16吗?那不是意味着它可以用于显示,例如4字节字符吗?如果不是,那么...显示4字节字符是不可能的吗?(Windows似乎没有针对这些的API。)
LPWSTR
是指向wchar_t
的指针,在Windows上wchar_t始终是一个16位无符号整数。可以显示哪些字符与编码无关,只要该编码能够编码所有Unicode字符。Windows通常可以显示非BMP字符,但不是在所有地方(例如控制台不能)。
WideCharToMultiByte的功能是否是wcstombs的超集,并且它们两者都适用于同一类型的字符串?或者其中一个适用于UTF-16,而另一个适用于UCS-2?
不是很确定,但我认为它们之间的区别不大。我想你只需要尝试将一些非BMP字符转换为UTF-8,并查看结果是否正确。
文件路径是UTF-16还是UCS-2?我知道Windows将其视为Microsoft文档中的“不透明字符数组”,但对于类似fwprintf的C标准函数,是否有任何标准化的编码方式?
文件路径确实是不透明的UTF-16字符数组,这意味着Windows在存储或读取文件名时不执行任何形式的转换(类似Linux,不像Mac OS X)。但Windows仍然有其奇怪的主要未定义的不区分大小写行为,这会引起许多麻烦,因为被视为等价的文件名并不一定相等。这打破了很多不变量;例如,在Linux上,如果您在某个目录中成功创建两个文件A和a而没有其他线程干扰,则最终会得到两个不同的文件,而在Windows上只有一个文件(通常是不可预测的文件数量)。
“ANSI”编码是什么?那是正确的术语吗?它与ASCII有何关系?
“ANSI”编码是指使用单字节字符集的编码,例如Windows上的CP1252或ISO-8859-1。但是,这个术语是不正确的,因为它不能明确地描述特定的编码。ASCII是一个较小的字符集,只包含128个字符,其中包括英文字母、数字和一些标点符号。
ANSI是美国标准化组织。在提到编码时使用这个词是一个错误的用法,但却很常见,因此您应该意识到这一点。我更喜欢使用术语“传统的8位编码”,因为我认为这基本上就是它的定义:一种非Unicode编码,仅为了与传统(Windows 9x)应用程序兼容而保留。在西方系统中,通常使用的是Windows-1252编码,它是ASCII的一个适当超集。