C++字符串完全指南 - Win32字符编码（一）
前言
字符串的表现形式各异，象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，代表字符"unicode码和ascii码区别ソ"。可是函数把它误认为反斜线了。
正确的方法是用DBCS函数将指针指向恰当的字符位置，如下所示：
bool FixedGetConfigFileName ( char* pszName, size_t nBuffSize )
{
char szConfigFilename[MAX_PATH];
    // 这里从注册表读取文件的安装路径，假设一切正常。
    // 如果路径末尾没有反斜线，就加上反斜线。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。