ASCII; UNICODE, UCS-2, UTF-16, UTF-16-LE, UTF-16-BE, UTF-8; Code Page; Locale; ...
一堆纠缠不清的东西……
尤其是 UNICODE 和 UTF-8。
有标准，有解决方案。嗯，很多……
历史遗留问题不是那么容易搞定的，对于微软更是如此。不过扔掉包袱的想法，想一想还是挺爽的：
正如文中提到的：一个函数调用就有 3 个问题，其中 2 个还是发生在微软内部。
有多少代码会检查返回值？尤其是 ERROR_CALL_NOT_IMPLEMENTED？
微软内部还存在问题，何况外部使用？
"Unicode"逐渐成为默认值，比如 Visual Studio 2005 的 C++ 编译选项。
但是，C# 中 DllImport 默认的字符集仍是 CharSet.Ansi。
OS 内核可以只支持 "Unicode"，自家的东西也可以用宏来隐藏A/W。
不过也没有这么简单：不光要考虑核心态、用户态，还有 OLE……
标准还得遵循，至少 printf 得有吧，于是外边还是得 _*t*/w。
当然，标准的接口也有麻烦……
正如 Raymond 对 Michael 的 Blog 标题的更名建议：
而 Michael 的 Blog 的一大特点就是，自己来回地标注、引用，甚至比其他人的评论还多……
我也有过这样的尝试和疑问：
01. 控制面板的区域和语言设置中，试图设置非 Unicode 程序的默认语言为 UTF-8：好吧，UTF-8 确实不是一种语言。
02. "chcp 65001"：UTF-8 好歹也是 Code Page 中的一个啊……
但是，这个仅影响输出，UTF-8 和 GB18030 都不是 ACP (ANSI Code Page)。
马上查 MB_LEN_MAX：MSDN 上是 2，头文件中是 5……
不过，从头文件看来，wchar_t 不光是 2 个字节不够，4 个字节也不够啊。
其实，我也喜欢定长更多一些——简单。
没有感受到 2000 问题，2038 也还远着呢，超出 2 字节的 UTF-16 字符估计也不会碰上了。但愿……
当英文采用 UTF-8 以外的 Unicode 编码时，要膨胀 1 倍。
而中文采用 UTF-8 相对其他编码不过膨胀 50% 而已。
当文件保存和网页浏览开始统一到 UTF-8 时，为何 OS 还要坚持 UCS-2 呢？
折腾这一圈，也只是刚好解决手头的问题而已。
下次碰到其他 Unicode 的问题，难保不再折腾一次……
No comments:
Post a Comment