在windows下面編程，我們通常都知道unicode這個概念，如果一個程序是unicode的，那么他將調用
unicode的api。這個時候，所有傳遞給api的字符串參數都要是unicode的.如果使用C的風格，是很簡單的
，字符串全部由char* str 轉變成TCHAR* str,使用的crt函數(其實也是api)時調用_tcslen類的函數族就
可以了。
在討論其它問題前要先明確一個概念:unicode 與 utf-8編碼,utf-16編碼是兩個不同類別的術語。
unicode對一個字符提供了一個唯一的編碼(參看下面的資料，關于UCS-2與UCS-4)
假設"中"這個字符的編碼是0x34 0x34(我亂寫的),utf-8對其編碼，得到的是 0xE3 0x90 0xB6 需要3byte
的空間進行存儲。不同的unicode碼經過utf-8編碼后會得到變長的結果.比如說'a'經過utf-8編碼后得到
的是和ascii碼相同,只占1個byte.對unicode使用不同的方法編碼,可以有效的節(jié)約存儲空間(如果選擇了
錯誤的編碼,會浪費空間).
中的unicode(UCS-2)值和編碼后的結果
unicode???????????????????????????? utf-8??????????
00110100 00110100????? 11100011? 10010000 10110110
a的unicode值和編碼后的結果
unicode???????????????????????????? utf-8
00000000 01100001????? 01100001
這里得出的結論是utf-8,utf-16編碼是在存儲字符串信息前的一個選擇,而不是處理字符串的選擇.
OK,問題回到字符串編程上來。第一個問題，就是要選擇內存中的字符串格式，包括自己所有需要傳遞字
符串參數的函數的參數定義。我們這里有3個選擇，char*(ASCII string),unsigned short*(UCS2
string,windows下的unicode),unsigned long*(UCS4 string,真正的unicode支持)。windows下的api是不
支持UCS4的，所以在windows平臺下最好只做前2個的選擇。類似于windows的TCHAR定義，我們可以做這樣
的定義
#ifdef _UCS2
#define TCHAR unsigned short
#else
#ifdef _UCS4
#define TCHAR unsigned long
#else
#define TCHAR char
#endif
#endif
然后有一個問題，如果在程序中需要使用一個預定義的字符串，比如說
TCHAR* str = "中國";
那么,str指向的常量字符串的編碼是ACSII string,還是UCS2 unicode string,還是UCS4 unicode
string,是取決于編譯器的。這樣就容易造成許多不易發(fā)現的錯誤。這里要推薦一個string table的概念
，用如下代碼替換。
const TCHAR* str = StringTable::LoadStr(ID_HOMELOAD_NAME);
StringTable類解析一個指定編碼的本地字符串表XML文件(可以用各種編碼存儲)，這個文件可以使用自定
義的工具或則是各種XML編輯工具來生成。使用StringTable::SetOutPutType(enum MemStrType)來使之在
LoadStr的時候轉成各種字符串編碼。當然，這個類中定義了一系列的編碼轉換函數，比如說
UTF8TOASCII,UTF8TOUCS2,UTF8TOUCS4,UCS4TOUCS2,UCS4TOASCII,UCS4TOXXX,StringTalbe內部使用UCS4作
為讀取后的字符串存儲格式，然后再根據StringTable::SetOutPutType指定的輸出類型生成相應編碼的
Table.這樣做的好處就是把這個編碼的問題重視化，即時出現編碼不一致的錯誤，也能立刻修正。
在linux下,系統(tǒng)對UCS4的支持比較好，#include<wchar.h>，里面的函數的接口都是ucs4 string.所以如果寫跨平臺程序，肯定是要用ucs2的(UCS4windows不支持，而且可以節(jié)約內存，但是你的程序就不是真正的UNICODE3.1 Support了，而且也不能支持國家標準GB18030).然后再調用linux的相關函數時，轉化為UCS4.參考文章http://www0.ccidnet.com/tech/os/2001/07/31/58_2811.html。我懶得寫了。
Unicode 的定義
Unicode 通常用作涉及雙字節(jié)字符編碼方案的通用術語。Unicode CCS 3.1 的官方稱謂是 ISO10646-1 通
用多八字節(jié)編碼字符集（Universal Multiple Octet Coded Character Set，UCS）。Unicode 3.1 版本
添加了 44,946 個新的編碼字符。算上 Unicode 3.0 版本已經存在的 49,194 個字符，共計 94,140 個
。
Unicode 編碼字符集利用了一個由 128 個三維的組構成的四維編碼空間。其中每個組包含 256 個二維平
面。每個平面由 256 個一維的行組成，并且每個行有 256 個單元。每個單元在這個編碼空間內對一個字
符編碼，或者被聲明為未經使用。這種編碼概念被稱為 UCS-4；四個八位元用來表示指定組、平面、行和
單元的每個字符。
第一個平面（第 00 組的第 00 平面）是基本多語言平面（Basic Multilingual Plane，BMP）。BMP 按
字母、音節(jié)、表意符號和各種符號及數字定義了常規(guī)使用的字符。后續(xù)的平面用于附加字符或其它還沒有
發(fā)明的編碼實體。我們需要這完整的范圍去處理世界上的所有語言；特別是擁有將近 64,000 個字符的一
些東亞語言。
BMP 被用作雙字節(jié)的編碼字符集，這種編碼字符集確定為 ISO 10646 UCS-2 格式。ISO 10646 UCS-2 就
是指 Unicode（并且兩者相同）。BMP，像所有 UCS 平面那樣，包含了 256 行，其中每行包含 256 個單
元，字符僅僅按照 BMP 中的行和單元的八位元在單元中被編碼。 這就允許 16 位編碼字符能夠被用來書
寫大多數商業(yè)上最重要的語言。UCS-2 不需要代碼頁切換、代碼擴展或代碼狀態(tài)。UCS-2 是一種將
Unicode 結合到軟件中的簡單方法，但它只限于支持 Unicode BMP。
若要用 8 位字節(jié)表示一個多于 2^8 =256 個字符的字符編碼系統(tǒng)（character coding system，CCS），
就需要一種字符編碼方案(character-encoding scheme，CES）。
UTF-8
UTF-8 轉換格式正逐步成為一種占主導地位的交換國際文本信息的方法，因為它可以支持世界上所有的語
言，而且它還與 ASCII 兼容。UTF-8 使用變長編碼。從 0 到 0x7f（127）的字符把自身編碼成單字節(jié)，
而將值更大的字符編碼成 2 到 6 個字節(jié)。
表 1. UTF-8 編碼
0x00000000 - 0x0000007F:? 0 xxxxxxx?
0x00000080 - 0x000007FF:? 110 xxxxx10 xxxxxx?
0x00000800 - 0x0000FFFF:? 1110 xxxx10 xxxxxx10 xxxxxx?
0x00010000 - 0x001FFFFF:? 11110 xxx10 xxxxxx10 xxxxxx 10 xxxxxx?
0x00200000 - 0x03FFFFFF:? 111110 xx10 xxxxxx10 xxxxxx10 xxxxxx 10 xxxxxx?
0x04000000 - 0x7FFFFFFF:? 1111110 x10 xxxxxx10 xxxxxx10 xxxxxx 10 xxxxxx10 xxxxxx?