Meh*_*dad 31 unicode winapi ascii multibyte-functions widechar
我不太喜欢编码,但这是我认为我知道的(虽然它可能是错的):
这些都是正确的吗？
现在,对于问题:
SetWindowTextA)是否采用ASCII字符串？或"多字节字符串"(下面有更多问题)？LPWSTR一个"宽字符串"？我会说它是,但那么,这不意味着它是UTF-16吗？并不意味着它可以用于显示4字节字符？如果没有,那么...显示4字节字符是不可能的？(Windows似乎没有那些API.)WideCharToMultiByte超集的功能,wcstombs它们是否都在相同类型的字符串上工作？或者说,其中一个工作在UTF-16上,而另一个工作在UCS-2上？fwprintf,是否有任何标准化编码？这些是很多问题,所以任何关于所有这些连接的解释的链接(除了阅读Unicode标准,无论如何都不会帮助Windows API)也将非常感激.
谢谢!
Phi*_*ipp 27
这些都是正确的吗？
是的,如果你不假设存在未用Unicode编码的字符(对于大多数实际应用,这个假设很好).
Windows"A"函数(如SetWindowTextA)是否采用ASCII字符串？或"多字节字符串"(下面有更多问题)？
它们采用当前"ANSI"/ MBCS/legacy编码编码的字节字符串(即,代码单元为字节的字符串,在Windows上始终为八位字节)."ANSI"是这些编码的历史术语,但不正确.对于Western Windows系统,此编码通常是Windows-1252.
Windows"W"函数是否采用UTF-16字符串或UCS-2字符串？我认为他们接受了UCS-2,但名字让我感到困惑.
从Windows 2000开始,大多数都支持UTF-16.在现代Unicode标准统一术语之前,选择名称"wide"和Microsoft术语的其余部分(例如,"Unicode"表示"UTF-16"或"UCS").
在WideCharToMultiByte中,Microsoft使用"宽字符串"一词表示UTF-16.在那种情况下,那么什么被认为是"多字节字符串"？UTF-8？
WideCharToMultiByte支持的每个其他编码在此上下文中都是"多字节编码",包括Windows-1251和UTF-8.
LPWSTR是"宽字符串"吗？我会说它是,但那么,这不意味着它是UTF-16吗？并不意味着它可以用于显示4字节字符？如果没有,那么...显示4字节字符是不可能的？(Windows似乎没有那些API.)
LPWSTR是一个指针,wchar_t在Windows上始终是一个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是美国的标准化组织.在提到编码时使用这个词是用词不当,但是经常使用,所以你应该知道它.我更喜欢传统的8位编码,因为我认为它本质上是这样的:非Unicode编码只保留与传统(Windows 9x)应用程序的兼容性.在Western系统上,这通常是Windows-1252,它是ASCII的正确超集.