C++字符串完全指引之一Win32 字符编码.docx
《C++字符串完全指引之一Win32 字符编码.docx》由会员分享，可在线阅读，更多相关《C++字符串完全指引之一Win32 字符编码.docx（13页珍藏版）》请在冰点文库上搜索。
C++字符串完全指引之一Win32字符编码
C++字符串完全指引之一——Win32字符编码
原著：
MichaelDunn
翻译：
ChengjieSun
原文出处：
CodeProject：
TheCompleteGuidetoC++Strings,PartI
引言
毫无疑问，我们都看到过像TCHAR,std:
:
string,BSTR等各种各样的字符串类型，还有那些以_tcs开头的奇怪的宏。
你也许正在盯着显示器发愁。
本指引将总结引进各种字符类型的目的，展示一些简单的用法，并告诉您在必要时，如何实现各种字符串类型之间的转换。
在第一部分，我们将介绍3种字符编码类型。
了解各种编码模式的工作方式是很重要的事情。
即使你已经知道一个字符串是一个字符数组，你也应该阅读本部分。
一旦你了解了这些，你将对各种字符串类型之间的关系有一个清楚地了解。
在第二部分，我们将单独讲述string类，怎样使用它及实现他们相互之间的转换。
字符基础--ASCII,DBCS,Unicode
所有的string类都是以C-style字符串为基础的。
C-style字符串是字符数组。
所以我们先介绍字符类型。
这里有3种编码模式对应3种字符类型。
第一种编码类型是单子节字符集（single-bytecharactersetorSBCS）。
在这种编码模式下，所有的字符都只用一个字节表示。
ASCII是SBCS。
一个字节表示的0用来标志SBCS字符串的结束。
第二种编码模式是多字节字符集（multi-bytecharactersetorMBCS）。
一个MBCS编码包含一些一个字节长的字符，而另一些字符大于一个字节的长度。
用在Windows里的MBCS包含两种字符类型，单字节字符（single-bytecharacters）和双字节字符（double-bytecharacters）。
由于Windows里使用的多字节字符绝大部分是两个字节长，所以MBCS常被用DBCS代替。
在DBCS编码模式中，一些特定的值被保留用来表明他们是双字节字符的一部分。
例如，在Shift-JIS编码中（一个常用的日文编码模式），0x81-0x9f之间和0xe0-oxfc之间的值表示"这是一个双字节字符，下一个子节是这个字符的一部分。
"这样的值被称作"leadingbytes",他们都大于0x7f。
跟随在一个leadingbyte子节后面的字节被称作"trailbyte"。
在DBCS中，trailbyte可以是任意非0值。
像SBCS一样，DBCS字符串的结束标志也是一个单字节表示的0。
第三种编码模式是Unicode。
Unicode是一种所有的字符都使用两个字节编码的编码模式。
Unicode字符有时也被称作宽字符，因为它比单子节字符宽（使用了更多的存储空间）。
注意，Unicode不能被看作MBCS。
MBCS的独特之处在于它的字符使用不同长度的字节编码。
Unicode字符串使用两个字节表示的0作为它的结束标志。
单字节字符包含拉丁文字母表，accentedcharacters及ASCII标准和DOS操作系统定义的图形字符。
双字节字符被用来表示东亚及中东的语言。
Unicode被用在COM及WindowsNT操作系统内部。
你一定已经很熟悉单字节字符。
当你使用char时，你处理的是单字节字符。
双字节字符也用char类型来进行操作（这是我们将会看到的关于双子节字符的很多奇怪的地方之一）。
Unicode字符用wchar_t来表示。
Unicode字符和字符串常量用前缀L来表示。
例如：
wchar_twch=L''1'';//2bytes,0x0031
wchar_t*wsz=L"Hello";//12bytes,6widecharacters
字符在内存中是怎样存储的
单字节字符串：
每个字符占一个字节按顺序依次存储，最后以单字节表示的0结束。
例如。
"Bob"的存贮形式如下：
42
6F
62
00
B
o
b
BOS
Unicode的存储形式，L"Bob"
4200
6F00
6200
0000
B
o
b
BOS
使用两个字节表示的0来做结束标志。
一眼看上去，DBCS字符串很像SBCS字符串，但是我们一会儿将看到DBCS字符串的微妙之处，它使得使用字符串操作函数和永字符指针遍历一个字符串时会产生预料之外的结果。
字符串""（"nihongo"）在内存中的存储形式如下（LB和TB分别用来表示leadingbyte和trailbyte）
93FA
967B
8CEA
00
LBTB
LBTB
LBTB
EOS
EOS
值得注意的是，"ni"的值不能被解释成WORD型值0xfa93，而应该看作两个值93和fa以这种顺序被作为"ni"的编码。
使用字符串处理函数
我们都已经见过C语言中的字符串函数，strcpy（）,sprintf（）,atoll（）等。
这些字符串只应该用来处理单字节字符字符串。
标准库也提供了仅适用于Unicode类型字符串的函数，比如wcscpy（）,swprintf（）,wtol（）等。
微软还在它的CRT（Cruntimelibrary）中增加了操作DBCS字符串的版本。
Str***（）函数都有对应名字的DBCS版本_mbs***（）。
如果你料到可能会遇到DBCS字符串（如果你的软件会被安装在使用DBCS编码的国家，如中国，日本等，你就可能会），你应该使用_mbs***（）函数，因为他们也可以处理SBCS字符串。
（一个DBCS字符串也可能含有单字节字符，这就是为什么_mbs***（）函数也能处理SBCS字符串的原因）
让我们来看一个典型的字符串来阐明为什么需要不同版本的字符串处理函数。
我们还是使用前面的Unicode字符串L"Bob"：
4200
6F00
6200
0000
B
o
b
BOS
因为x86CPU是little-endian，值0x0042在内存中的存储形式是4200。
你能看出如果这个字符串被传给strlen（）函数会出现什么问题吗？
它将先看到第一个字节42，然后是00，而00是字符串结束的标志，于是strlen（）将会返回1。
如果把"Bob"传给wcslen（），将会得出更坏的结果。
wcslen（）将会先看到0x6f42，然后是0x0062，然后一直读到你的缓冲区的末尾，直到发现0000结束标志或者引起了GPF。
到目前为止，我们已经讨论了str***（）和wcs***（）的用法及它们之间的区别。
Str***（）和_mbs**（）之间的有区别区别呢？
明白他们之间的区别，对于采用正确的方法来遍历DBCS字符串是很重要的。
下面，我们将先介绍字符串的遍历，然后回到str***（）与_mbs***（）之间的区别这个问题上来。
正确的遍历和索引字符串
因为我们中大多数人都是用着SBCS字符串成长的，所以我们在遍历字符串时，常常使用指针的++-和-操作。
我们也使用数组下标的表示形式来操作字符串中的字符。
这两种方式是用于SBCS和Unicode字符串，因为它们中的字符有着相同的宽度，编译器能正确的返回我们需要的字符。
然而，当碰到DBCS字符串时，我们必须抛弃这些习惯。
这里有使用指针遍历DBCS字符串时的两条规则。
违背了这两条规则，你的程序就会存在DBCS有关的bugs。
1．在前向遍历时，不要使用++操作，除非你每次都检查leadbyte；
2．永远不要使用-操作进行后向遍历。
我们先来阐述规则2，因为找到一个违背它的真实的实例代码是很容易的。
假设你有一个程序在你自己的目录里保存了一个设置文件，你把安装目录保存在注册表中。
在运行时，你从注册表中读取安装目录，然后合成配置文件名，接着读取该文件。
假设，你的安装目录是C:
\ProgramFiles\MyCoolApp，那么你合成的文件名应该是C:
\ProgramFiles\MyCoolApp\config.bin。
当你进行测试时，你发现程序运行正常。
现在，想象你合成文件名的代码可能是这样的：
boolGetConfigFileName（char*pszName,size_tnBuffSize）
{
charszConfigFilename[MAX_PATH];
//Readinstalldirfromregistry...we''llassumeitsucceeds.
//Addonabackslashifitwasn''tpresentintheregistryvalue.
//First,getapointertotheterminatingzero.
char*pLastChar=strchr（szConfigFilename,''\0''）;
//Nowmoveitbackonecharacter.
pLastChar--;
if（*pLastChar!
=''\\''）
strcat（szConfigFilename,"\\"）;
//Addonthenameoftheconfigfile.
strcat（szConfigFilename,"config.bin"）;
//Ifthecaller''sbufferisbigenough,returnthefilename.
if（strlen（szConfigFilename）>=nBuffSize）
returnfalse;
else
{
strcpy（pszName,szConfigFilename）;
returntrue;
}
}
这是一段很健壮的代码，然而在遇到DBCS字符时它将会出错。
让我们来看看为什么。
假设一个日本用户使用了你的程序，把它安装在C:
\
。
下面是这个名字在内存中的存储形式：
43
3A
5C
8388
8345
8352
835C
00
LBTB
LBTB
LBTB
LBTB
C
:
\
EOS
当使用GetConfigFileName（）检查尾部的''\\''时，它寻找安装目录名中最后的非0字节，看它是等于''\\''的，所以没有重新增加一个''\\''。
结果是代码返回了错误的文件名。
哪里出错了呢？
看看上面两个被用蓝色高量显示的字节。
斜杠''\\''的值是0x5c。
''''的值是835c。
上面的代码错误的读取了一个trailbyte，把它当作了一个字符。
正确的后向遍历方法是使用能够识别DBCS字符的函数，使指针移动正确的字节数。
下面是正确的代码。
（指针移动的地方用红色标明）
boolFixedGetConfigFileName（char*pszName,size_tnBuffSize）
{
charszConfigFilename[MAX_PATH];
//Readinstalldirfromregistry...we''llassumeitsucceeds.
//Addonabackslashifitwasn''tpresentintheregistryvalue.
//First,getapointertotheterminatingzero.
char*pLastChar=_mbschr（szConfigFilename,''\0''）;
//Nowmoveitbackonedouble-bytecharacter.
pLastChar=CharPrev（szConfigFilename,pLastChar）;
if（*pLastChar!
=''\\''）
_mbscat（szConfigFilename,"\\"）;
//Addonthenameoftheconfigfile.
_mbscat（szConfigFilename,"config.bin"）;
//Ifthecaller''sbufferisbigenough,returnthefilename.
if（_mbslen（szInstallDir）>=nBuffSize）
returnfalse;
else
{
_mbscpy（pszName,szConfigFilename）;
returntrue;
}
}
上面的函数使用CharPrev（）API使pLastChar向后移动一个字符，这个字符可能是两个字节长。
在这个版本里，if条件正常工作，因为leadbyte永远不会等于0x5c。
让我们来想象一个违背规则1的场合。
例如，你可能要检测一个用户输入的文件名是否多次出现了'':
''。
如果，你使用++操作来遍历字符串，而不是使用CharNext（），你可能会发出不正确的错误警告如果恰巧有一个trailbyte它的值的等于'':
''的值。
与规则2相关的关于字符串索引的规则：
2a.永远不要使用减法去得到一个字符串的索引。
违背这条规则的代码和违背规则2的代码很相似。
例如，
char*pLastChar=&szConfigFilename[strlen（szConfigFilename）-1];
这和向后移动一个指针是同样的效果。
回到关于str***（）和_mbs***（）的区别
现在，我们应该很清楚为什么_mbs***（）函数是必需的。
Str***（）函数根本不考虑DBCS字符，而_mbs***（）考虑。
如果，你调用strrchr（"C:
\\",''\\''），返回结果可能是错误的，然而_mbsrchr（）将会认出最后的双字节字符，返回一个指向真的''\\''的指针。
关于字符串函数的最后一点：
str***（）和_mbs***（）函数认为字符串的长度都是以char来计算的。
所以，如果一个字符串包含3个双字节字符，_mbslen（）将会返回6。
Unicode函数返回的长度是按wchar_t来计算的。
例如，wcslen（L"Bob"）返回3。
Win32API中的MBCS和Unicode
两组APIs：
尽管你也许从来没有注意过，Win32中的每个与字符串相关的API和message都有两个版本。
一个版本接受MBCS字符串，另一个接受Unicode字符串。
例如，根本没有SetWindowText（）这个API，相反，有SetWindowTextA（）和SetWindowTextW（）。
后缀A表明这是MBCS函数，后缀W表示这是Unicode版本的函数。
当你build一个Windows程序，你可以选择是用MBCS或者UnicodeAPIs。
如果，你曾经用过VC向导并且没有改过预处理的设置，那表明你用的是MBCS版本。
那么，既然没有SetWindowText（）API，我们为什么可以使用它呢？
winuser.h头文件包含了一些宏，例如：
BOOLWINAPISetWindowTextA（HWNDhWnd,LPCSTRlpString）;
BOOLWINAPISetWindowTextW（HWNDhWnd,LPCWSTRlpString）;
#ifdefUNICODE
#defineSetWindowTextSetWindowTextW
#else
#defineSetWindowTextSetWindowTextA
#endif
当使用MBCSAPIs来build程序时，UNICODE没有被定义，所以预处理器看到：
#defineSetWindowTextSetWindowTextA
这个宏定义把所有对SetWindowText的调用都转换成真正的API函数SetWindowTextA。
（当然，你可以直接调用SetWindowTextA（）或者SetWindowTextW（），虽然你不必那么做。
）
所以，如果你想把默认使用的API函数变成Unicode版的，你可以在预处理器设置中，把_MBCS从预定义的宏列表中删除，然后添加UNICODE和_UNICODE。
（你需要两个都定义，因为不同的头文件可能使用不同的宏。
）然而，如果你用char来定义你的字符串，你将会陷入一个尴尬的境地。
考虑下面的代码：
HWNDhwnd=GetSomeWindowHandle（）;
charszNewText[]="weloveBob!
";
SetWindowText（hwnd,szNewText）;
在预处理器把SetWindowText用SetWindowTextW来替换后，代码变成：
HWNDhwnd=GetSomeWindowHandle（）;
charszNewText[]="weloveBob!
";
SetWindowTextW（hwnd,szNewText）;
看到问题了吗？
我们把单字节字符串传给了一个以Unicode字符串做参数的函数。
解决这个问题的第一个方案是使用#ifdef来包含字符串变量的定义：
HWNDhwnd=GetSomeWindowHandle（）;
#ifdefUNICODE
wchar_tszNewText[]=L"weloveBob!
";
#else
charszNewText[]="weloveBob!
";
#endif
SetWindowText（hwnd,szNewText）;
你可能已经感受到了这样做将会使你多么的头疼。
完美的解决方案是使用TCHAR.
使用TCHAR
TCHAR是一种字符串类型，它让你在以MBCS和UNNICODE来build程序时可以使用同样的代码，不需要使用繁琐的宏定义来包含你的代码。
TCHAR的定义如下：
#ifdefUNICODE
typedefwchar_tTCHAR;
#else
typedefcharTCHAR;
#endif
所以用MBCS来build时，TCHAR是char，使用UNICODE时，TCHAR是wchar_t。
还有一个宏来处理定义Unicode字符串常量时所需的L前缀。
#ifdefUNICODE
#define_T（x）L##x
#else
#define_T（x）x
#endif
##是一个预处理操作符，它可以把两个参数连在一起。
如果你的代码中需要字符串常量，在它前面加上_T宏。
如果你使用Unicode来build，它会在字符串常量前加上L前缀。
TCHARszNewText[]=_T（"weloveBob!
"）;
像是用宏来隐藏SetWindowTextA/W的细节一样，还有很多可以供你使用的宏来实现str***（）和_mbs***（）等字符串函数。
例如，你可以使用_tcsrchr宏来替换strrchr（）、_mbsrchr（）和wcsrchr（）。
_tcsrchr根据你预定义的宏是_MBCS还是UNICODE来扩展成正确的函数，就像SetWindowText所作的一样。
不仅str***（）函数有TCHAR宏。
其他的函数如，_stprintf（代替sprinft（）和swprintf（））,_tfopen（代替fopen（）和_wfopen（））。
MSDN中"Generic-TextRoutineMappings."标题下有完整的宏列表。
字符串和TCHARtypedefs
由于Win32API文档的函数列表使用函数的常用名字（例如，"SetWindowText"），所有的字符串都是用TCHAR来定义的。
（除了XP中引入的只适用于Unicode的API）。
下面列出一些常用的typedefs，你可以在msdn中看到他们。
type
MeaninginMBCSbuilds
MeaninginUnicodebuilds
WCHAR
wchar_t
wchar_t
LPSTR
zero-terminatedstringofchar（char*）
zero-terminatedstringofchar（char*）
LPCSTR
constantzero-terminatedstringofchar（constchar*）
constantzero-terminatedstringofchar（constchar*）
LPWSTR
zero-terminatedUnicodestring（wchar_t*）
zero-terminatedUnicodestring（wchar_t*）
LPCWSTR
constantzero-terminatedUnicodestring（constwchar_t*）
constantzero-terminatedUnicodestring（constwchar_t*）
TCHAR
char
wchar_t
LPTSTR
zero-terminatedstringofTCHAR（TCHAR*）
zero-terminatedstringofTCHAR（TCHAR*）
LPCTSTR
constantzero-terminatedstringofTCHAR（constTCHAR*）
constantzero-terminatedstringofTCHAR（constTCHAR*）
何时使用TCHAR和Unicode
到现在，你可能会问，我们为什么要使用Unicode。
我已经用了很多年的char。
下列3种情况下，使用Unicode将会使你受益：
1．你的程序只运行在WindowsNT系统中。
2．你的程序需要处理超过MAX_PATH个字符长的文件名。
3．你的程序需要使用XP中引入的只有Unicode版本的API.
Windows9x中大多数的API没有实现Unicode版本。
所以，如果你的程序要在windows9x中运行，你必须使用MBCSAPIs。
然而，由于NT系统内部都使用Unicode，所以使用UnicodeAPIs将会加快你的程序的运行速度。
每次，你传递一个字符串调用MBCSAPI，操作系统会把这个字符串转换成Unicode字符串，然后调用对应的
升级会员 