引言

　　毫無疑問，我們都看到過像 TCHAR, std::string, BSTR 等各種各樣的字串型別，還有那些以 _tcs 開頭的奇怪的巨集。你也許正在盯著顯示器發愁。本指引將總結引進各種字元型別的目的，展示一些簡單的用法，並告訴您在必要時，如何實現各種字串型別之間的轉換。
　　在第一部分，我們將介紹3種字元編碼型別。瞭解各種編碼模式的工作方式是很重要的事情。即使你已經知道一個字串是一個字元陣列，你也應該閱讀本部分。一旦你瞭解了這些，你將對各種字串型別之間的關係有一個清楚地瞭解。
　　在第二部分，我們將單獨講述string類，怎樣使用它及實現他們相互之間的轉換。

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

 字元在記憶體中是怎樣儲存的

　　單位元組字串：每個字元佔一個位元組按順序依次儲存，最後以單位元組表示的0結束。例如。"Bob"的存貯形式如下：

Unicode的儲存形式，L"Bob"

使用兩個位元組表示的0來做結束標誌。

　　一眼看上去，DBCS 字串很像 SBCS 字串，但是我們一會兒將看到 DBCS 字串的微妙之處，它使得使用字串操作函式和永字元指標遍歷一個字串時會產生預料之外的結果。字串" " ("nihongo")在記憶體中的儲存形式如下（LB和TB分別用來表示 leading byte 和 trail byte）

93 FA	96 7B	8C EA	00
LB TB	LB TB	LB TB	EOS
			EOS

值得注意的是，"ni"的值不能被解釋成WORD型值0xfa93，而應該看作兩個值93和fa以這種順序被作為"ni"的編碼。

 使用字串處理函式

　　我們都已經見過C語言中的字串函式，strcpy(), sprintf(), atoll()等。這些字串只應該用來處理單位元組字元字串。標準庫也提供了僅適用於Unicode型別字串的函式，比如wcscpy(), swprintf(), wtol()等。
　　微軟還在它的CRT(C runtime library)中增加了操作DBCS字串的版本。Str***()函式都有對應名字的DBCS版本_mbs***()。如果你料到可能會遇到DBCS字串（如果你的軟體會被安裝在使用DBCS編碼的國家，如中國，日本等，你就可能會），你應該使用_mbs***()函式，因為他們也可以處理SBCS字串。（一個DBCS字串也可能含有單位元組字元，這就是為什麼_mbs***()函式也能處理SBCS字串的原因）
　　讓我們來看一個典型的字串來闡明為什麼需要不同版本的字串處理函式。我們還是使用前面的Unicode字串 L"Bob"：

　　因為x86CPU是little-endian，值0x0042在記憶體中的儲存形式是42 00。你能看出如果這個字串被傳給strlen()函式會出現什麼問題嗎？它將先看到第一個位元組42，然後是00，而00是字串結束的標誌，於是strlen()將會返回1。如果把"Bob"傳給wcslen()，將會得出更壞的結果。wcslen()將會先看到0x6f42，然後是0x0062，然後一直讀到你的緩衝區的末尾，直到發現00 00結束標誌或者引起了GPF。
　　到目前為止，我們已經討論了str***()和wcs***()的用法及它們之間的區別。Str***()和_mbs**()之間的有區別區別呢？明白他們之間的區別，對於採用正確的方法來遍歷DBCS字串是很重要的。下面，我們將先介紹字串的遍歷，然後回到str***()與_mbs***()之間的區別這個問題上來。

 正確的遍歷和索引字串

　　因為我們中大多數人都是用著SBCS字串成長的，所以我們在遍歷字串時，常常使用指標的++-和-操作。我們也使用陣列下標的表示形式來操作字串中的字元。這兩種方式是用於SBCS和Unicode字串，因為它們中的字元有著相同的寬度，編譯器能正確的返回我們需要的字元。
　　然而，當碰到DBCS字串時，我們必須拋棄這些習慣。這裡有使用指標遍歷DBCS字串時的兩條規則。違背了這兩條規則，你的程式就會存在DBCS有關的bugs。

　　我們先來闡述規則2，因為找到一個違背它的真實的例項程式碼是很容易的。假設你有一個程式在你自己的目錄裡儲存了一個設定檔案，你把安裝目錄儲存在登錄檔中。在執行時，你從登錄檔中讀取安裝目錄，然後合成配置檔名，接著讀取該檔案。假設，你的安裝目錄是C:\Program Files\MyCoolApp，那麼你合成的檔名應該是C:\Program Files\MyCoolApp\config.bin。當你進行測試時，你發現程式執行正常。
　　現在，想象你合成檔名的程式碼可能是這樣的：

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, ''\0'' );
 
    // 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;
        }
} 

43	3A	5C	83 88	83 45	83 52	83 5C	00
LB TB	LB TB	LB TB	LB TB
C	:	\					EOS

　　當使用 GetConfigFileName() 檢查尾部的''\\''時，它尋找安裝目錄名中最後的非0位元組，看它是等於''\\''的，所以沒有重新增加一個''\\''。結果是程式碼返回了錯誤的檔名。
　　哪裡出錯了呢？看看上面兩個被用藍色高量顯示的位元組。斜槓''\\''的值是0x5c。'' ''的值是83 5c。上面的程式碼錯誤的讀取了一個 trail byte，把它當作了一個字元。
　　正確的後向遍歷方法是使用能夠識別DBCS字元的函式，使指標移動正確的位元組數。下面是正確的程式碼。（指標移動的地方用紅色標明）

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, ''\0'' );
 
    // 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;
        }
}

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。

 Win32 API中的MBCS和Unicode

兩組 APIs： 
　　儘管你也許從來沒有注意過，Win32中的每個與字串相關的API和message都有兩個版本。一個版本接受MBCS字串，另一個接受Unicode字串。例如，根本沒有SetWindowText()這個API，相反，有SetWindowTextA()和SetWindowTextW()。字尾A表明這是MBCS函式，字尾W表示這是Unicode版本的函式。
　　當你 build 一個 Windows 程式，你可以選擇是用 MBCS 或者 Unicode APIs。如果，你曾經用過VC嚮導並且沒有改過預處理的設定，那表明你用的是MBCS版本。那麼，既然沒有 SetWindowText() API，我們為什麼可以使用它呢？winuser.h標頭檔案包含了一些巨集，例如：

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

#define SetWindowText SetWindowTextA

　　這個巨集定義把所有對SetWindowText的呼叫都轉換成真正的API函式SetWindowTextA。（當然，你可以直接呼叫SetWindowTextA() 或者 SetWindowTextW()，雖然你不必那麼做。）
　　所以，如果你想把預設使用的API函式變成Unicode版的，你可以在前處理器設定中，把_MBCS從預定義的巨集列表中刪除，然後新增UNICODE和_UNICODE。(你需要兩個都定義，因為不同的標頭檔案可能使用不同的巨集。) 然而，如果你用char來定義你的字串，你將會陷入一個尷尬的境地。考慮下面的程式碼：

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

在前處理器把SetWindowText用SetWindowTextW來替換後，程式碼變成：

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

　　看到問題了嗎？我們把單位元組字串傳給了一個以Unicode字串做引數的函式。解決這個問題的第一個方案是使用 #ifdef 來包含字串變數的定義：

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

你可能已經感受到了這樣做將會使你多麼的頭疼。完美的解決方案是使用TCHAR.

 使用TCHAR

　　TCHAR是一種字串型別，它讓你在以MBCS和UNNICODE來build程式時可以使用同樣的程式碼，不需要使用繁瑣的巨集定義來包含你的程式碼。TCHAR的定義如下：

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

所以用MBCS來build時，TCHAR是char，使用UNICODE時，TCHAR是wchar_t。還有一個巨集來處理定義Unicode字串常量時所需的L字首。

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

　　##是一個預處理操作符，它可以把兩個引數連在一起。如果你的程式碼中需要字串常量，在它前面加上_T巨集。如果你使用Unicode來build，它會在字串常量前加上L字首。

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

　　像是用巨集來隱藏SetWindowTextA/W的細節一樣，還有很多可以供你使用的巨集來實現str***()和_mbs***()等字串函式。例如，你可以使用_tcsrchr巨集來替換strrchr()、_mbsrchr()和wcsrchr()。_tcsrchr根據你預定義的巨集是_MBCS還是UNICODE來擴充套件成正確的函式，就像SetWindowText所作的一樣。
　　不僅str***()函式有TCHAR巨集。其他的函式如， _stprintf（代替sprinft()和swprintf()）,_tfopen（代替fopen()和_wfopen()）。 MSDN中"Generic-Text Routine Mappings."標題下有完整的巨集列表。

 字串和TCHAR typedefs

　　由於Win32 API文件的函式列表使用函式的常用名字（例如，"SetWindowText"），所有的字串都是用TCHAR來定義的。（除了XP中引入的只適用於Unicode的API）。下面列出一些常用的typedefs，你可以在msdn中看到他們。

 何時使用 TCHAR 和 Unicode

　　到現在，你可能會問，我們為什麼要使用Unicode。我已經用了很多年的char。下列3種情況下，使用Unicode將會使你受益：

　　Windows 9x 中大多數的 API 沒有實現 Unicode 版本。所以，如果你的程式要在windows 9x中執行，你必須使用MBCS APIs。然而，由於NT系統內部都使用Unicode，所以使用Unicode APIs將會加快你的程式的執行速度。每次，你傳遞一個字串呼叫MBCS API，作業系統會把這個字串轉換成Unicode字串，然後呼叫對應的Unicode API。如果一個字串被返回，作業系統還要把它轉變回去。儘管這個轉換過程被高度優化了，但它對速度造成的損失是無法避免的。
　　只要你使用Unicode API，NT系統允許使用非常長的檔名（突破了MAX_PATH的限制，MAX_PATH=260）。使用Unicode API的另一個優點是你的程式會自動處理使用者輸入的各種語言。所以一個使用者可以輸入英文，中文或者日文，而你不需要額外編寫程式碼去處理它們。
　　最後，隨著windows 9x產品的淡出，微軟似乎正在拋棄MBCS APIs。例如，包含兩個字串引數的SetWindowTheme() API只有Unicode版本的。使用Unicode來build你的程式將會簡化字串的處理，你不必在MBCS和Unicdoe之間相互轉換。
　　即使你現在不使用Unicode來build你的程式，你也應該使用TCHAR及其相關的巨集。這樣做不僅可以的程式碼可以很好地處理DBCS，而且如果將來你想用Unicode來build你的程式，你只需要改變一下前處理器中的設定就可以實現了。