C++字符串完全指南 - Win32字符编码（一）

C++字符串完全指南 - Win32字符编码（一）

作者: 翻译：连波 类别: VC/VC.NET 日期: 2003-1-6 14:35:46

C++字符串完全指南 - Win32字符编码（一） http://www.zdnet.com.cn/developer/tech/story/0,2000081602,39098124-1,00.htm 前言 字符串的表现形式各异，象TCHAR，std::string，BSTR等等，有时还会见到怪怪的用_tcs起头的宏。这个指南的目的就是说明各种字符串类型及其用途，并说明如何在必要时进行类型的相互转换。 在指南的第一部分，介绍三种字符编码格式。理解编码的工作原理是致为重要的。即使你已经知道字符串是一个字符的数组这样的概念，也请阅读本文，它会让你明白各种字符串类之间的关系。 指南的第二部分，将阐述各个字符串类，什么时候使用哪种字符串类，及其相互转换。 字符串基础 - ASCII, DBCS, Unicode 所有的字符串类都起源于C语言的字符串，而C语言字符串则是字符的数组。首先了解一下字符类型。有三种编码方式和三种字符类型。 第一种编码方式是单字节字符集，称之为SBCS，它的所有字符都只有一个字节的长度。ASCII码就是SBCS。SBCS字符串由一个零字节结尾。 第二种编码方式是多字节字符集，称之为MBCS，它包含的字符中有单字节长的字符，也有多字节长的字符。Windows用到的MBCS只有二种字符类型，单字节字符和双字节字符。因此Windows中用得最多的字符是双字节字符集，即DBCS，通常用它来代替MBCS。 在DBCS编码中，用一些保留值来指明该字符属于双字节字符。例如，Shift-JIS(通用日语)编码中，值0x81-0x9F 和 0xE0-0xFC 的意思是：“这是一个双字节字符，下一个字节是这个字符的一部分”。这样的值通常称为前导字节(lead byte)，总是大于0x7F。前导字节后面是跟随字节(trail byte)。DBCS的跟随字节可以是任何非零值。与SBCS一样，DBCS字符串也由一个零字节结尾。 第三种编码方式是Unicode。Unicode编码标准中的所有字符都是双字节长。有时也将Unicode称为宽字符集(wide characters)，因为它的字符比单字节字符更宽(使用更多内存)。注意，Unicode不是MBCS - 区别在于MBCS编码中的字符长度是不同的。Unicode字符串用二个零字节字符结尾(一个宽字符的零值编码)。 单字节字符集是拉丁字母，重音文字，用ASCII标准定义，用于DOS操作系统。双字节字符集用于东亚和中东语言。Unicode用于COM和Windows NT内部。 读者都很熟悉单字节字符集，它的数据类型是char。双字节字符集也使用char数据类型(双字节字符集中的许多古怪处之一)。Unicode字符集用wchar_t数据类型。Unicode字符串用L前缀起头，如： wchar_t wch = L'1'; // 2 个字节, 0x0031 wchar_t* wsz = L"Hello"; // 12 个字节, 6 个宽字符 字符串的存储 单字节字符串顺序存放各个字符，并用零字节表示字符串结尾。例如，字符串"Bob"的存储格式为： Unicode编码中，L"Bob"的存储格式为： 用0x0000 (Unicode的零编码)结束字符串。 DBCS 看上去有点象SBCS。以后我们会看到在串处理和指针使用上是有微妙差别的。字符串"日本语" (nihongo) 的存储格式如下(用LB和TB分别表示前导字节和跟随字节)： 注意，"ni"的值不是WORD值0xFA93。值93和FA顺序组合编码为字符"ni"。(在高位优先CPU中，存放顺序正如上所述)。 字符串处理函数 C语言字符串处理函数，如strcpy(), sprintf(), atol()等只能用于单字节字符串。在标准库中有只用于Unicode字符串的函数，如wcscpy(), swprintf(), _wtol()。 微软在C运行库(CRT)中加入了对DBCS字符串的支持。对应于strxxx()函数，DBCS使用_mbsxxx()函数。在处理DBCS字符串(如日语，中文，或其它DBCS)时，就要用_mbsxxx()函数。这些函数也能用于处理SBCS字符串(因为DBCS字符串可能就只含有单字节字符)。 现在用一个示例来说明字符串处理函数的不同。如有Unicode字符串L"Bob"： x86 CPU的排列顺序是低位优先(little-endian)的，值0x0042的存储顺序为42 00。这时如用strlen()函数求字符串的长度就发生问题。函数找到第一个字节42，然后是00，意味着字符串结尾，于是返回1。反之，用wcslen()函数求"Bob"的长度更糟糕。wcslen()首先找到0x6F42，然后是0x0062，以后就在内存缓冲内不断地寻找00 00直至发生一般性保护错(GPF)。 strxxx()及其对应的_mbsxxx()究竟是如何运作的？二者之间的不同是非常重要的，直接影响到正确遍历DBCS字符串的方法。下面先介绍字符串遍历，然后再回来讨论strxxx()和 _mbsxxx()。 我们中的大多数人都是从SBCS成长过来的，都习惯于用指针的 ++ 和 -- 操作符来遍历字符串，有时也使用数组来处理字符串中的字符。这二种方法对于SBCS 和 Unicode 字符串的操作都是正确无误的，因为二者的字符都是等长的，编译器能够的正确返回我们寻求的字符位置。 但对于DBCS字符串就不能这样了。用指针访问DBCS字符串有二个原则，打破这二个原则就会造成错误。 1. 不可使用 ++ 算子，除非每次都检查是否为前导字节。 2. 绝不可使用 -- 算子来向后遍历。 先说明原则2，因为很容易找到一个非人为的示例。假设，有一个配制文件，程序启动时要从安装路径读取该文件，如：C:/Program Files/MyCoolApp/config.bin。文件本身是正常的。 假设用以下代码来配制文件名： bool GetConfigFileName ( char* pszName, size_t nBuffSize ) { char szConfigFilename[MAX_PATH]; // 这里从注册表读取文件的安装路径，假设一切正常。 // 如果路径末尾没有反斜线，就加上反斜线。 // 首先，用指针指向结尾零： char* pLastChar = strchr ( szConfigFilename, '/0' ); // 然后向后退一个字符： pLastChar--; if ( *pLastChar != '//' ) strcat ( szConfigFilename, "//" ); // 加上文件名： strcat ( szConfigFilename, "config.bin" ); // 如果字符串长度足够，返回文件名： if ( strlen ( szConfigFilename ) >= nBuffSize ) return false; else { strcpy ( pszName, szConfigFilename ); return true; } } 这段代码的保护性是很强的，但用到DBCS字符串还是会出错。假如文件的安装路径用日语表达：C:/ヨウユソ，该字符串的内存表达为： 这时用上面的GetConfigFileName()函数来检查文件路径末尾是否含有反斜线就会出错，得到错误的文件名。 错在哪里？注意上面的二个十六进制值0x5C(蓝色)。前面的0x5C是字符"/"，后面则是字符值83 5C，代表字符"ソ"。可是函数把它误认为反斜线了。 正确的方法是用DBCS函数将指针指向恰当的字符位置，如下所示： bool FixedGetConfigFileName ( char* pszName, size_t nBuffSize ) { char szConfigFilename[MAX_PATH]; // 这里从注册表读取文件的安装路径，假设一切正常。 // 如果路径末尾没有反斜线，就加上反斜线。 // 首先，用指针指向结尾零： char* pLastChar = _mbschr ( szConfigFilename, '/0' ); // 然后向后退一个双字节字符： pLastChar = CharPrev ( szConfigFilename, pLastChar ); if ( *pLastChar != '//' ) _mbscat ( szConfigFilename, "//" ); // 加上文件名： _mbscat ( szConfigFilename, "config.bin" ); // 如果字符串长度足够，返回文件名： if ( _mbslen ( szInstallDir ) >= nBuffSize ) return false; else { _mbscpy ( pszName, szConfigFilename ); return true; } } 这个改进的函数用CharPrev() API 函数将指针pLastChar向后移动一个字符。如果字符串末尾的字符是双字节字符，就向后移动2个字节。这时返回的结果是正确的，因为不会将字符误判为反斜线。 现在可以想像到第一原则了。例如，要遍历字符串寻找字符":"，如果不使用CharNext()函数而使用++算子，当跟随字节值恰好也是":"时就会出错。 与原则2相关的是数组下标的使用： 　2a. 绝不可在字符串数组中使用递减下标。 出错原因与原则2相同。例如，设置指针pLastChar为： char* pLastChar = &szConfigFilename [strlen(szConfigFilename) - 1]; 结果与原则2的出错一样。下标减1就是指针向后移动一个字节，不符原则2。 再谈strxxx() 与_mbsxxx() 现在可以清楚为什么要用 _mbsxxx() 函数了。strxxx() 函数不认识DBCS字符而 _mbsxxx()认识。如果调用strrchr("C://", '//')函数可能会出错，但 _mbsrchr()认识双字节字符，所以能返回指向最后出现反斜线字符的指针位置。 最后提一下strxxx() 和 _mbsxxx() 函数族中的字符串长度测量函数，它们都返回字符串的字节数。如果字符串含有3个双字节字符，_mbslen()将返回6。而Unicode的函数返回的是wchar_ts的数量，如wcslen(L"Bob") 返回3(本文开头示例的出错原因 - 译注)。 下一篇重我们将要讲述Win32 API中的MBCS 和 Unicode。