C++字符串(Unicode/TCHAR/WCHAR/ASCII/LPSTR/LPCSTR等转换)

时间:2021-09-18 23:09:46

C++字符串(Unicode/TCHAR/WCHAR/ASCII/LPSTR/LPCSTR等转换)

分类: C++ 701人阅读 评论(0) 收藏 举报

C++字符串完全指引一

引言

毫无疑问,我们都看到过像 TCHAR, std::string, BSTR 等各种各样的字符串类型,还有那些以 _tcs 开头的奇怪的宏你也许正在盯着显示器发愁本指引将总结引进各种字符类型的目的,展示一些简单的用法,并告诉您在必要时,如何实现各种字符串类型之间的转换2005089632

在第一部分,我们将介绍3种字符编码类型了解各种编码模式的工作方式是很重要的事情即使你已经知道一个字符串是一个字符数组,你也应该阅读本部分一旦你了解了这些,你将对各种字符串类型之间的关系有一个清楚地了解2005089632

在第二部分,我们将单独讲述string类,怎样使用它及实现他们相互之间的转换2005089632

字符基础 -- ASCII, DBCS, Unicode

所有的 string 类都是以C-style字符串为基础的C-style 字符串是字符数组所以我们先介绍字符类型这里有3种编码模式对应3种字符类型2005089632

第一种编码类型是单字节字符集(single-byte character set or SBCS)在这种编码模式下,所有的字符都只用一个字节表示ASCII是SBCS一个字节表示的0用来标志SBCS字符串的结束2005089632

第二种编码模式是多字节字符集(multi-byte character set or MBCS)一个MBCS编码包含一些一个字节长的字符,而另一些字符大于一个字节的长度用在Windows里的MBCS包含两种字符类型,单字节字符(single-byte characters)和双字节字符(double-byte characters)由于Windows里使用的多字节字符绝大部分是两个字节长,所以MBCS常被用DBCS代替2005089632

在DBCS编码模式中,一些特定的值被保留用来表明他们是双字节字符的一部分例如,在Shift-JIS编码中(一个常用的日文编码模式),0x81-0x9f之间和 0xe0-oxfc之间的值表示"这是一个双字节字符,下一个字节是这个字符的一部分"这样的值被称作"leading bytes",他们都大于0x7f跟随在一个leading byte字节后面的字节被称作"trail byte"在DBCS中,trail byte可以是任意非0值像SBCS一样,DBCS字符串的结束标志也是一个单字节表示的02005089632

第三种编码模式是UnicodeUnicode是一种所有的字符都使用两个字节编码的编码模式Unicode字符有时也被称作宽字符,因为它比单字节字符宽(使用了更多的存储空间)注意,Unicode不能被看作MBCSMBCS的独特之处在于它的字符使用不同长度的字节编码Unicode 字符串使用两个字节表示的0作为它的结束标志2005089632

单字节字符包含拉丁文字母表,accented characters及ASCII标准和DOS操作系统定义的图形字符双字节字符被用来表示东亚及中东的语言Unicode被用在COM及Windows NT操作系统内部2005089632

你一定已经很熟悉单字节字符当你使用char时,你处理的是单字节字符双字节字符也用char类型来进行操作(这是我们将会看到的关于双字节字符的很多奇怪的地方之一)Unicode字符用wchar_t来表示Unicode字符和字符串常量用前缀L来表示例如:2005089632

wchar_t wch = L''1''; // 2 bytes, 0x0031 wchar_t* wsz = L"Hello"; // 12 bytes, 6 wide characters

2005089632

字符在内存中是怎样存储的

单字节字符串:每个字符占一个字节按顺序依次存储,最后以单字节表示的0结束例如"Bob"的存贮形式如下:
2005089632

使用两个字节表示的0x0000来做结束标志2005089632

一眼看上去,DBCS 字符串很像 SBCS 字符串,但是我们一会儿将看到 DBCS 字符串的微妙之处,它使得使用字符串操作函数和永字符指针遍历一个字符串时会产生预料之外的结果字符串"日本语 " ("nihongo")在内存中的存储形式如下(LB和TB分别用来表示 leading byte 和 trail byte)
2005089632

值得注意的是,"ni"的值不能被解释成WORD型值0xfa93,而应该看作两个值93和fa以这种顺序被作为"ni"的编码(So on a big-endian CPU, the bytes would still be in the order shown above.)2005089632

使用字符串处理函数

我们都已经见过C语言中的字符串函数,strcpy(), sprintf(), atoll()等这些字符串只应该用来处理单字节字符字符串标准库也提供了仅适用于Unicode类型字符串的函数,比如wcscpy(), swprintf(), wtol()等2005089632

微软还在它的CRT(C runtime library)中增加了操作DBCS字符串的版本Str***()函数都有对应名字的DBCS版本_mbs***()如果你料到可能会遇到DBCS 字符串(如果你的软件会被安装在使用DBCS编码的国家,如中国,日本等,你就可能会),你应该使用_mbs***()函数,因为他们也可以处理SBCS 字符串(一个DBCS字符串也可能含有单字节字符,这就是为什么_mbs***()函数也能处理SBCS字符串的原因)2005089632

让我们来看一个典型的字符串来阐明为什么需要不同版本的字符串处理函数我们还是使用前面的Unicode字符串 L"Bob":
2005089632


2005089632

因为x86CPU是little-endian,值0x0042在内存中的存储形式是42 00你能看出如果这个字符串被传给strlen()函数会出现什么问题吗?它将先看到第一个字节42,然后是00,而00是字符串结束的标志,于是 strlen()将会返回1如果把"Bob"传给wcslen(),将会得出更坏的结果wcslen()将会先看到0x6f42,然后是 0x0062,然后一直读到你的缓冲区的末尾,直到发现00 00结束标志或者引起了GPF2005089632

到目前为止,我们已经讨论了str***()和wcs***()的用法及它们之间的区别Str***()和_mbs**()之间的有区别区别呢?明白他们之间的区别,对于采用正确的方法来遍历DBCS字符串是很重要的下面,我们将先介绍字符串的遍历,然后回到str***()与_mbs***() 之间的区别这个问题上来
2005089632

正确的遍历和索引字符串

因为我们中大多数人都是用着SBCS字符串成长的,所以我们在遍历字符串时,常常使用指针的++-和-操作我们也使用数组下标的表示形式来操作字符串中的字符这两种方式是用于SBCS和Unicode字符串,因为它们中的字符有着相同的宽度,编译器能正确的返回我们需要的字符2005089632

然而,当碰到DBCS字符串时,我们必须抛弃这些习惯这里有使用指针遍历DBCS字符串时的两条规则违背了这两条规则,你的程序就会存在DBCS有关的bugs2005089632

# 1.在前向遍历时,不要使用++操作,除非你每次都检查lead byte;# 2.永远不要使用-操作进行后向遍历

我们先来阐述规则2,因为找到一个违背它的真实的实例代码是很容易的假设你有一个程序在你自己的目录里保存了一个设置文件,你把安装目录保存在注册表中在运行时,你从注册表中读取安装目录,然后合成配置文件名,接着读取该文件假设,你的安装目录是C:Program FilesMyCoolApp,那么你合成的文件名应该是C:Program FilesMyCoolAppconfig.bin当你进行测试时,你发现程序运行正常2005089632

现在,想象你合成文件名的代码可能是这样的:2005089632

bool GetConfigFileName ( char* pszName, size_t nBuffSize ) { char szConfigFilename[MAX_PATH]; // Read install dir from registry... we''ll assume it succeeds. // Add on a backslash if it wasn''t present in the registry value. // First, get a pointer to the terminating zero. char* pLastChar = strchr ( szConfigFilename, '''' ); // Now move it back one character. pLastChar--; if ( *pLastChar != ''\'' ) strcat ( szConfigFilename, "\" ); // Add on the name of the config file. strcat ( szConfigFilename, "config.bin" ); // If the caller''s buffer is big enough, return the filename. if ( strlen ( szConfigFilename ) >= nBuffSize ) return false; else { strcpy ( pszName, szConfigFilename ); return true; } }

这是一段很健壮的代码,然而在遇到 DBCS 字符时它将会出错让我们来看看为什么假设一个中国用户使用了你的程序,把它安装在 C:伟大祖国下面是这个名字在内存中的存储形式:

2005089632


2005089632

当使用 GetConfigFileName() 检查尾部的''\''时,它寻找安装目录名中最后的非0字节,看它是等于''\''的,所以没有重新增加一个''\''结果是代码返回了错误的文件名2005089632

哪里出错了呢?看看上面两个被用蓝色高量显示的字节斜杠''\''的值是0x5c''国 ''的值是83 5c上面的代码错误的读取了一个 trail byte,把它当作了一个字符2005089632

正确的后向遍历方法是使用能够识别DBCS字符的函数,使指针移动正确的字节数下面是正确的代码(指针移动的地方用红色标明)2005089632

bool FixedGetConfigFileName ( char* pszName, size_t nBuffSize ) { char szConfigFilename[MAX_PATH]; // Read install dir from registry... we''ll assume it succeeds. // Add on a backslash if it wasn''t present in the registry value. // First, get a pointer to the terminating zero. char* pLastChar = _mbschr ( szConfigFilename, '''' ); // Now move it back one double-byte character. pLastChar = CharPrev ( szConfigFilename, pLastChar ); if ( *pLastChar != ''\'' ) _mbscat ( szConfigFilename, "\" ); // Add on the name of the config file. _mbscat ( szConfigFilename, "config.bin" ); // If the caller''s buffer is big enough, return the filename. if ( _mbslen ( szInstallDir ) >= nBuffSize ) return false; else { _mbscpy ( pszName, szConfigFilename ); return true; } }

上面的函数使用CharPrev() API使pLastChar向后移动一个字符,这个字符可能是两个字节长在这个版本里,if条件正常工作,因为lead byte永远不会等于0x5c2005089632

让我们来想象一个违背规则1的场合例如,你可能要检测一个用户输入的文件名是否多次出现了'':''如果,你使用++操作来遍历字符串,而不是使用CharNext(),你可能会发出不正确的错误警告如果恰巧有一个trail byte它的值的等于'':''的值2005089632

与规则2相关的关于字符串索引的规则:2005089632

2a. 永远不要使用减法去得到一个字符串的索引

违背这条规则的代码和违背规则2的代码很相似例如,2005089632

char* pLastChar = &szConfigFilename [strlen(szConfigFilename) - 1];

这和向后移动一个指针是同样的效果2005089632

回到关于str***()和_mbs***()的区别2005089632

现在,我们应该很清楚为什么_mbs***()函数是必需的Str***()函数根本不考虑DBCS字符,而_mbs***()考虑如果,你调用strrchr("C:\ ", ''\''),返回结果可能是错误的,然而_mbsrchr()将会认出最后的双字节字符,返回一个指向真的''\''的指针2005089632

关于字符串函数的最后一点:str***()和_mbs***()函数认为字符串的长度都是以char来计算的所以,如果一个字符串包含3个双字节字符,_mbslen()将会返回6Unicode函数返回的长度是按wchar_t来计算的例如,wcslen(L"Bob")返回32005089632

Win32 API中的MBCS和Unicode两组 APIs:

尽管你也许从来没有注意过,Win32中的每个与字符串相关的API和message都有两个版本一个版本接受MBCS字符串,另一个接受 Unicode字符串例如,根本没有SetWindowText()这个API,相反,有SetWindowTextA()和 SetWindowTextW()后缀A表明这是MBCS函数,后缀W表示这是Unicode版本的函数2005089632

当你 build 一个 Windows 程序,你可以选择是用 MBCS 或者 Unicode APIs如果,你曾经用过VC向导并且没有改过预处理的设置,那表明你用的是MBCS版本那么,既然没有 SetWindowText() API,我们为什么可以使用它呢?winuser.h头文件包含了一些宏,例如:2005089632

BOOL WINAPI SetWindowTextA ( HWND hWnd, LPCSTR lpString ); BOOL WINAPI SetWindowTextW ( HWND hWnd, LPCWSTR lpString ); #ifdef UNICODE #define SetWindowText SetWindowTextW #else #define SetWindowText SetWindowTextA #endif

当使用MBCS APIs来build程序时,UNICODE没有被定义,所以预处理器看到:2005089632

#define SetWindowText SetWindowTextA

这个宏定义把所有对SetWindowText的调用都转换成真正的API函数SetWindowTextA(当然,你可以直接调用SetWindowTextA() 或者 SetWindowTextW(),虽然你不必那么做)2005089632

所以,如果你想把默认使用的API函数变成Unicode版的,你可以在预处理器设置中,把_MBCS从预定义的宏列表中删除,然后添加UNICODE和_UNICODE(你需要两个都定义,因为不同的头文件可能使用不同的宏) 然而,如果你用char来定义你的字符串,你将会陷入一个尴尬的境地考虑下面的代码:2005089632

HWND hwnd = GetSomeWindowHandle(); char szNewText[] = "we love Bob!"; SetWindowText ( hwnd, szNewText );

在预处理器把SetWindowText用SetWindowTextW来替换后,代码变成:2005089632

HWND hwnd = GetSomeWindowHandle(); char szNewText[] = "we love Bob!"; SetWindowTextW ( hwnd, szNewText );

看到问题了吗?我们把单字节字符串传给了一个以Unicode字符串做参数的函数解决这个问题的第一个方案是使用 #ifdef 来包含字符串变量的定义:2005089632

HWND hwnd = GetSomeWindowHandle(); #ifdef UNICODE wchar_t szNewText[] = L"we love Bob!"; #else char szNewText[] = "we love Bob!"; #endif SetWindowText ( hwnd, szNewText );

你可能已经感受到了这样做将会使你多么的头疼完美的解决方案是使用TCHAR.2005089632

使用TCHAR

TCHAR是一种字符串类型,它让你在以MBCS和UNNICODE来build程序时可以使用同样的代码,不需要使用繁琐的宏定义来包含你的代码TCHAR的定义如下:2005089632

#ifdef UNICODE typedef wchar_t TCHAR; #else typedef char TCHAR; #endif

所以用MBCS来build时,TCHAR是char,使用UNICODE时,TCHAR是wchar_t还有一个宏来处理定义Unicode字符串常量时所需的L前缀2005089632

#ifdef UNICODE #define _T(x) L##x #else #define _T(x) x #endif

##是一个预处理操作符,它可以把两个参数连在一起如果你的代码中需要字符串常量,在它前面加上_T宏如果你使用Unicode来build,它会在字符串常量前加上L前缀2005089632

TCHAR szNewText[] = _T("we love Bob!");

像是用宏来隐藏SetWindowTextA/W的细节一样,还有很多可以供你使用的宏来实现str***()和_mbs***()等字符串函数例如,你可以使用_tcsrchr宏来替换strrchr()_mbsrchr()和wcsrchr()_tcsrchr根据你预定义的宏是_MBCS 还是UNICODE来扩展成正确的函数,就像SetWindowText所作的一样2005089632

不仅str***()函数有TCHAR宏其他的函数如, _stprintf(代替sprinft()和swprintf()),_tfopen(代替fopen()和_wfopen()) MSDN中"Generic-Text Routine Mappings."标题下有完整的宏列表2005089632

字符串和TCHAR typedefs

由于Win32 API文档的函数列表使用函数的常用名字(例如,"SetWindowText"),所有的字符串都是用TCHAR来定义的(除了XP中引入的只适用于 Unicode的API)下面列出一些常用的typedefs,你可以在msdn中看到他们2005089632

type Meaning in MBCS builds Meaning in Unicode buildsLPSTR zero-terminated string of char (char*)zero-terminated string of char (char*)LPCSTR constant zero-terminated string of char (const char*)constant zero-terminated string of char (const char*)LPWSTRzero-terminated Unicode string (wchar_t*) zero-terminated Unicode string (wchar_t*)LPCWSTRconstant zero-terminated Unicode string (const wchar_t*)constant zero-terminated Unicode string (const wchar_t*) LPTSTRzero-terminated string of TCHAR (TCHAR*) zero-terminated string of TCHAR (TCHAR*)LPCTSTR constant zero-terminated string of TCHAR (const TCHAR*)constant zero-terminated string of TCHAR (const TCHAR*)

2005089632

何时使用 TCHAR 和 Unicode

到现在,你可能会问,我们为什么要使用Unicode我已经用了很多年的char下列3种情况下,使用Unicode将会使你受益:2005089632

# 1.你的程序只运行在Windows NT系统中
# 2. 你的程序需要处理超过MAX_PATH个字符长的文件名
# 3. 你的程序需要使用XP中引入的只有Unicode版本的API.2005089632

Windows 9x 中大多数的 API 没有实现 Unicode 版本所以,如果你的程序要在windows 9x中运行,你必须使用MBCS APIs然而,由于NT系统内部都使用Unicode,所以使用Unicode APIs将会加快你的程序的运行速度每次,你传递一个字符串调用MBCS API,操作系统会把这个字符串转换成Unicode字符串,然后调用对应的Unicode API如果一个字符串被返回,操作系统还要把它转变回去尽管这个转换过程被高度优化了,但它对速度造成的损失是无法避免的2005089632

只要你使用Unicode API,NT系统允许使用非常长的文件名(突破了MAX_PATH的限制,MAX_PATH=260)使用Unicode API的另一个优点是你的程序会自动处理用户输入的各种语言所以一个用户可以输入英文,中文或者日文,而你不需要额外编写代码去处理它们2005089632

最后,随着windows 9x产品的淡出,微软似乎正在抛弃MBCS APIs例如,包含两个字符串参数的SetWindowTheme() API只有Unicode版本的使用Unicode来build你的程序将会简化字符串的处理,你不必在MBCS和Unicdoe之间相互转换2005089632

即使你现在不使用Unicode来build你的程序,你也应该使用TCHAR及其相关的宏这样做不仅可以的代码可以很好地处理DBCS,而且如果将来你想用Unicode来build你的程序,你只需要改变一下预处理器中的设置就可以实现了