Unicode化

为了程序编写方便，根除乱码问题等等需求，很多新项目都采用了Unicode编码。
同时，不少使用MBCS多字节编码的旧项目为了升级，也有了转向Unicode编码的意向。
不过，从MBCS升级到Unicode并不是无缝的，该问题的复杂程度，取决于代码总量和
代码的编写质量。

本文是作者在一个C/C++项目中的一些经验之谈，希望对有此需求的读者带来帮助。

 

1. 工程属性切换在VC6.0中，切换到Unicode没有直接的选项可以选，需要在宏定义中添加UNICODE和_UNICODE，
同时需要去除MBCS宏定义。另外，如果生成的是exe的程序的话，还需要定义入口函数名wWinMainCRTStartup。
在VC2003以及之后的IDE环境中，有直接选者使用UNICODE还是MBCS的选项，无需添加宏定义。

【设定场所】
VC6.0: 主菜单 - 工程 - 设定 - C/C++标签(共通) - 宏定义
       主菜单 - 工程 - 设定 - 链接标签(输出) - 入口符号
VC2003: 主菜单 - 工程 - 属性 - 共通 - 字符集

 

 

2. 字符串定义

MBCS	Unicode	兼容MBCS和Unicode
char	WCHAR	TCHAR
char*	LPWSTR	LPTSTR
LPSTR	LPWSTR	LPTSTR
const char*	LPCWSTR	LPCTSTR
LPCSTR	LPCWSTR	LPCTSTR

※兼容MBCS和Unicode: 根据第一步的工程属性切换来决定采用MBCS还是Unicode
是一种比较好的，切换后无需修改代码的类型定义。不过也会带来一定的麻烦(稍后17点会针对这点进行讨论)。

 

 

3. 字符串常量定义需要在字符串两端加上L...，兼容模式的话则是_T(...)或者TEXT(...)，比如:

MBCS	Unicode	兼容MBCS和Unicode
"Clannad"	L"Clannad"	_T("Clannad")或者TEXT("Clannad")

※对于宏定义__FILE__，如果要使得这个宏定义变成Unicode的话，必须使用TEXT(...)
采用_T(...)会产生编译错误。

 

 

4. 字符串文字数计算在MBCS中，我们采用strlen来计算一个字符串的长度，其实结果是字节数，而非文字数(纯英文数字除外)。
而在Unicode中，我们可以采用lstrlen来计算一个字符串的长度，其结果是文字数，恰好是字节数的一半。

但有时候我们需要获得变量可以容纳文字数的长度，比如LoadString()，其中最后一个参数需要我们传入
可容纳最大的文字数长度，在MBCS中，我们常常这么写sizeof(buffer)，不过在Unicode中，
这样写的话就有可能会导致内存溢出，所以更好的写法是sizeof(buffer) / sizeof(TCHAR)或者
sizeof(buffer) / sizeof(buffer[0])

个人推荐后者，理由是仍然在Unicode环境下，如果buffer因为某些原因从TCHAR变回了char，
那么后者能正常工作，前者会因为错误的字符串变量文字数而导致字符串截断。

※另外需要注意的是，在Windows API中如果是针对内存操作的函数，比如memcpy, memset等等，
那么sizeof(buffer)是正确的，因为函数需要传入字节数，而不是文字数
只有在API函数需要的文字数的时候才需要作此更改，对于参数的详细信息，可以参考MSDN后再做判断

 

 

5. 字符串函数的替换最早的一些字符串处理函数，比如: strcpy, strlen等等因为都是针对ANSI的(strstr这类搜索函数
在处理MBCS字符串时可能会产生错误，所以这些函数本身并不是MBCS向的)，在更换成Unicode后，
这些常用函数也多了许多新版本，不单单是针对Unicode，而且增加安全性等方面也作了改进。
在这里列出来的话可能会占用不少篇幅，而且也很难整理全，所以在此直接提供MSDN的地址。
String Manipulation (CRT)

 

 

6. Windows API函数对于Windows API函数来说，通常涉及字符串的函数都有A和W两个版本，比如: CreateFileA和CreateFileW。
这两个虽然对我们来说是可引用的，但由于Windows头文件的屏蔽，我们经常使用CreateFile来进行编程。
而根据第一步的工程属性切换，代码中会自动替换成A版本或者W版本。因此对于这点我们无须操心太多，
唯一需要操心的就是，无法对应的Unicode的地方，我们必须采用A版本来处理某些操作，这就需要我们
显式指定A版本了，因为工程属性的关系，CreateFile总是被映射到CreateFileW上。

 

 

7. 推荐使用 wsprintf对于格式化字符串，这个函数提供了很好的Unicode和MBCS的兼容性。
此函数在Unicode和MBCS下都能正常工作，因为它的两个参数为LPTSTR和LPCTSTR。
其次，在MBCS下%s表示MBCS，%S表示Unicode，
在Unicode下%S表示MBCS，%s表示Unicode。
因此，采用这个函数进行字符串格式化的话，基本上是不需要修正就能使用的。
相关的资料请参见MSDN: 
wsprintf

 

 

8. WideCharToMultiByte和MultiByteToWideChar为了在MBCS和Unicode之间转换，Windows API提供了这两个函数。
基本上工程一大，总会遇到不能彻底Unicode化的情况，这个时候就用借用这两个函数的力量了。
MultiByteToWideChar
WideCharToMultiByte

使用例: 
WideCharToMultiByte(CP_OEMCP,NULL,szSrc,-1,szDest,dwLen,NULL,NULL);
※建议：可以先以dwLen = WideCharToMultiByte(CP_OEMCP,NULL,szSrc,-1,NULL,0,NULL,NULL)
的形式获得szSrc转换后的字节数(包含/0)，然后分配内存后再做字符集转换。

MultiByteToWideChar(CP_ACP,0,szSrc,-1,szDest,dwLen);
同样建议先获得szDest所需内存大小(包含/0)后分配内存再做转换。

 

 

9. MBCS专用函数在MBCS的程序中，因为str*系的函数只对应ANSI，对MBCS使用后往往会产生错误的结果，
所以往往采用几个MBCS专用函数来进行纠正。不过由于这些函数的引入，往往导致Unicode化繁琐化。
IsDBCSLeadByte和IsDBCSLeadByteEx这两个函数用来判断当前字节是不是MBCS的前导字节，
常常在截断字符串时，不知道截断点是不是一个双字节MBCS的正中间的时候使用。
对于Unicode来说，正常的操作永远不会截到一个双字节的Unicode字符的正中间，
而且这两个函数指针对MBCS字符，对于Unicode字符使用的话，后果是无法估计的。
所以，在Unicode化时，需要把这些函数剔除，然后重新整理处理逻辑。
与此内容相关的几个资料: 
Unicode and Character Set Functions
Character Classification
Strings

 

 

 

10. Unicode非对应函数出于某些原因，有些函数并没有提供Unicode的版本。
如果无法避免使用到的话，那就需要使用WideCharToMultiByte和MultiByteToWideChar来进行字符集转换。
这里列举几个已知常用函数: 

GetProcAddress	因为DLL的输出函数名都是ANSI形式保存的，所以没有提供Unicode版
WinSock系列 例: gethostname	TCP/IP协议诞生比较早，而且只对应ANSI， 所以提供的函数库自然没有Unicode版了

 

 

 

11. Unicode非对应DLL有时候在程序中调用了第三方的模块，但许多公司的模块只提供了MBCS或者ANSI的接口，
对于这种模块，和前一点一样，不得不使用WideCharToMultiByte和MultiByteToWideChar来进行字符集转换。
同时要注意，Unicode化修正代码的时候，不要盲目把第三方的头文件一起改掉了。
虽然编译会通过，但是链接的时候由于在lib库中找不到完全对应的函数声明，所以最终还是徒劳。

 

 

12. CString&的陷阱在使用MFC的时候，经常会使用CString来保存字符串。MFC中提供的CString并没有显式提供A版本和W版本，
当工程环境是MBCS的时候，CString保存的是LPSTR，而Unicode的时候，CString保存的是LPWSTR。
其实，两种环境下CString类的结构，大小，甚至代码都不是完全一样的。

如果把CString&作为一个DLL输出函数的变量类型来声明的话，在Unicode化中会碰到一点小麻烦。
当然如果可执行文件和DLL都是MBCS，或者都是Unicode的话没有任何问题，唯一要保证MFC的版本是一样就行了。
而如果DLL是MBCS，而可执行文件是Unicode的话，编译能正常通过，但是程序一跑就会出运行时错误。
原因就是，可执行文件和DLL的CString是对两种字符集做处理的，两边都认为里面放着自己能处理的字符集字符串。

对于这种问题，没有什么特别好的解决方案，唯一可行的方案就是再做一个中间层转换的DLL(MBCS版)，
接受可执行文件的Unicode字符串(注意不是CString&)，转换成MBCS的后放入CString中，再继续调用DLL。

 

 

13. 动态调用的陷阱在没有lib库文件，只有dll的情况下，我们往往会采用动态调用，动态调用的函数声明我们会采用typedef来声明。
但是typedef的掌控权在自己手里，如果在修正代码的时候，不小心把char改成了TCHAR的话，
编译器是不会抛出任何怨言的。因为在进行动态调用的时候，只要有了函数的入口地址就能被调用，
编译器只有在静态调用的时候才会检查参数个数和各自的类型，动态调用的时候只管typedef的声明
是不是和程序中调用的一致，被调用的DLL中函数的实际类型编译器是管不了，也管不到的。
※代码二进制化后，函数的声明信息就被抹除了

 

 

14. 指针相减的陷阱两个指针相减，结果并不是两个指针数值上的差，而是把这个差除以指针指向类型的大小的结果。
比如: WCHAR pA = 0x00400000, pB = 0x00401000, pB - pA的结果是0x1000 / sizeof(WCHAR) = 0x0800
有时候，为了计算字符串的字节数，会采用这种手段。然后在MBCS编码时并没有刻意去考虑指针相减的问题，
所以得出的结果不会去除以sizeof(TCHAR)。但是到了Unicode，这种编码显然就是有问题的，
弄得不好就是内存泄漏。更何况这种错误因为不会在编译阶段报错，所以要发现变得极其困难。

在发现并修正后，唯一能做的也就是吸取教训，以后编码的时候多多注意这类问题了

 

 

15. 类型char的滥用这个问题涉及面和影响性也是非常庞大的。
在Windows API中，内存指针往往声明成void*，这个类型表示一个泛型，能够接受其他所有类型，
也因此很多人习惯性的把内存声明成char*后传入。

对于这个看似不严重的的错误声明，在Unicode化的过程中，给编程人员带来极大的麻烦。
如果这个地址指向字符串，那当然修改成TCHAR*是正确的，但是如果指向一块结构体内存，
那么TCHAR就会把内存扩大成2倍，如果不巧这块内存体的下方有着重要数据的话，
一旦发生内存覆盖后，错误会隐藏几分钟，甚至几小时几天后才会暴露，而且无法跟踪。

在VC6.0中，有着BYTE这样一个宏定义，窥探一下就会发现其实是unsigned char，虽然和char相差只有一个前缀词，
但是足以让维护人员知道这个是表示内存的一个字节，而不是一个ANSI字符。

 

 

16. 既存文件的影响文件中的字符和内存中的一样，基于一种字符集后才能被解释。
Unicode化的过程中，我们修改了代码，使得运行时数据得到正确运行的同时，
也必须注意配置文件，数据文件中的字符集是不是也被一并修改掉了。
当然*.ini，注册表以及数据库也有这样的问题，不过因为Windows API，或者数据库链接提供商
都已经对字符集做了相应的处理，我们也只需要调用Unicode版本的函数就能迎刃而解。
需要得到注意只有那些受到你直接操控的数据文件。

 

 

17. LPTSTR的泛滥我们在写程序的时候，经常处于一种免责心理，别人怎么写我就怎么写。别人定义字符串用了LPTSTR，
那么我也用这个一定没错！但是呢，程序世界是严谨的，声明如果不恰当的话，必定会引起一些麻烦。
如果你正在写一段只能处理MBCS的代码(比如底层第三方的接口只提供了非Unicode版本)，
那么使用LPTSTR来定义就显得不够准确，虽然在MBCS下编译不会存在任何问题，但一旦这个项目
要进行Unicode化的话，LPTSTR就变成了LPWSTR，在接口调用的地方会因为类型不匹配而出现编译错误，
实施修改的程序员就不得不对这个糟糕的定义进行重新调整。但这个不是最可怕的，因为至少编译器
还能够发现这个错误。最可怕的就是那个底层dll的编写人员也在滥用LPTSTR，那么编译器就会被蒙骗，
运气好的话，静态调用在链接过程中发现了不匹配，运气不好的话，动态调用编译阶段不会报任何问题，
等到跑起来就有的你够受的。所以，如果你不是在为自己写代码，那么给别人的头文件请一定要选择恰当的类型声明。

 

 

18. 其他在实际Unicode化实施过程中，因为项目大小，难度不同还会遇到一些其他零零碎碎的问题。
有些可能是可以忽略的，但有些可能是难以追踪并且致命的。
对于有经验的人可能会在修改过程中注意到一些问题，但是对于没有经验的人，
就要通过调试，查错，参考资料来一步一步解决问题。

Unicode化可以说本身就是一种高难度的开发作业，希望通过阅读本文给那些
即将要实行Unicode化的程序员一些经验和建议，能在开发过程中尽早发现问题，解决困难。
最后对能看完本文的读者说声谢谢～

 

 

 

附个人见解:

	修正难度	修正范围	编译能发现
1. 工程属性切换	★☆☆☆☆	★☆☆☆☆	-
2. 字符串定义	★☆☆☆☆	★★★★★	○
3. 字符串常量定义	★☆☆☆☆	★★★★★	○
4. 字符串文字数计算	★★☆☆☆	★★★☆☆	×
5. 字符串函数的替换	★★☆☆☆	★★★★★	○
6. Windows API函数	☆☆☆☆☆	☆☆☆☆☆	-
7. 推荐使用 wsprintf	☆☆☆☆☆	☆☆☆☆☆	-
8. WideCharToMultiByte和MultiByteToWideChar	★★★☆☆	★★☆☆☆	○
9. MBCS专用函数	★★★★☆	★☆☆☆☆	×
10. Unicode非对应函数	★★☆☆☆	★☆☆☆☆	○
11. Unicode非对应DLL	★★☆☆☆	★★☆☆☆	○
12. CString&的陷阱	★★★★★	★☆☆☆☆	×
13. 动态调用的陷阱	★★★☆☆	★★☆☆☆	×
14. 指针相减的陷阱	★★☆☆☆	★★★☆☆	×
15. 类型char的滥用	★★☆☆☆	★★★☆☆	×
16. 既存文件的影响	★★☆☆☆	★☆☆☆☆	×
17. LPTSTR的泛滥	★★★★★	★★★☆☆	○
18. 其他	★★★★★	★★★☆☆	-