最近在做嵌入式開發(fā)，這個(gè)嵌入式平臺(tái)上，支持標(biāo)準(zhǔn)c庫(kù)，但不支持mbcs，也不支持unicode。里面的wchar_t被直接定義為char（typedef char wchar_t;），可見這個(gè)wchar_t是假的，只是為了讓含有wchar_t的程序能通過編譯，并不是支持unicode，當(dāng)然也就沒有對(duì)應(yīng)的wcs函數(shù)族。現(xiàn)在要讓這個(gè)系統(tǒng)上的程序支持中文，有下面幾種想法。
首先要弄清支持中文的含義，先分析一下需求，這個(gè)程序?qū)ψ址牟僮髦饕侨缦铝鞒蹋瑥奈募凶x進(jìn)字符串（文件編碼可自己定義），對(duì)字符串進(jìn)行查找、截取、拼接操作，最后把完成的字符串作為參數(shù)傳到另一個(gè)庫(kù)里（暫且叫它libn吧）。需要說明的是，libn由公司別的小組實(shí)現(xiàn)，它不關(guān)注字符集，里面不再處理（截取、拼接）字符串，只是把輸入的字符串輸出到文件或屏幕，目前已經(jīng)有一個(gè)比較穩(wěn)定的跨平臺(tái)版本。
需求確定以后，接下來要確定中文在程序中的存儲(chǔ)編碼。對(duì)中文來說，通常有三種編碼方案可供選擇：
1. 用mbcs編碼存儲(chǔ)（gb2312/gbk/gb18030）。
2. 用unicode編碼存儲(chǔ)。
3. 用utf-8編碼存儲(chǔ)。
這個(gè)系統(tǒng)里針對(duì)這三種編碼的字符串函數(shù)都沒有，不管采用哪種方案，字符串函數(shù)都得自己寫，從這點(diǎn)來說，三種方案的工作量都差不多。
先來看看mbcs，這個(gè)方案純粹是為了中文而支持中文，如果將來要兼容其他語言，mbcs函數(shù)都得重寫，而且mbcs跟unicode的轉(zhuǎn)換沒有固定的公式，必須依賴于一張大表。用mbcs沒有什么特別的好處，這個(gè)方案只能早早的就否決了。
再來看看unicode和utf-8。一般說來，unicode是國(guó)際化的終極解決方案，大部分c編譯器支持wchar_t數(shù)據(jù)類型，如果編譯器不支持wchar_t，可以自己使用unsigned short或unsigned int來模擬。不管什么語言，每個(gè)字符都被放到2字節(jié)的wchar_t類型里（linux下是4字節(jié)），通常對(duì)于新的程序，都推薦使用unicode。而utf-8是unicode的一種存儲(chǔ)方案。
下面我們從不同方面來比較一下unicode和utf-8各自的優(yōu)勢(shì)：
1. 內(nèi)存空間。unicode對(duì)于每個(gè)字符都是2個(gè)字節(jié)，utf-8對(duì)英文是一個(gè)字節(jié)，對(duì)漢字是2個(gè)或3個(gè)字節(jié)。對(duì)于英文來說，utf-8占優(yōu)，但在漢字占多數(shù)的情況下，unicode占優(yōu)勢(shì)。當(dāng)然，如果字符串的數(shù)量不是很大的話，這個(gè)問題不是很突出。這里列出來，對(duì)文件存儲(chǔ)也可以起到一個(gè)參考作用。
2. 程序編寫難度。unicode是定長(zhǎng)類型，而utf-8是變長(zhǎng)的，每操作一個(gè)字符的時(shí)候，都要考慮這個(gè)字符的長(zhǎng)度，毫無疑問unicode的字符串函數(shù)編寫起來應(yīng)該更簡(jiǎn)單。目前，這兩種字符串函數(shù)都有大量的實(shí)現(xiàn)可供參考，對(duì)于寫程序來說，問題不大。
3. 程序執(zhí)行效率。unicode定長(zhǎng)，utf-8變長(zhǎng)。對(duì)于strlen，substr之類的操作，unicode很方便，utf-8卻要從頭到尾掃描，而且需要邊掃描邊判斷字符長(zhǎng)度。因此unicode比utf-8要快很多，但如果這種操作不是很多，效率影響也不會(huì)特別明顯。
4. 現(xiàn)有程序的數(shù)量。unicode程序我們見得多了，但采用utf-8的程序也不少，gtk+就是。它們都運(yùn)行得很好。
5. 兼容性。英文的utf-8編碼跟ascii完全一樣，因此也兼容標(biāo)準(zhǔn)c庫(kù)的字符串函數(shù)，如果不需要操作字符，完全不用關(guān)心語言。對(duì)于unicode，標(biāo)準(zhǔn)c庫(kù)的字符串函數(shù)不能工作，字符串函數(shù)都得重寫，常常用一個(gè)宏來控制在unicode和ascii直接切換（比如windows下的TCHAR）。
從上面幾點(diǎn)來看，跟utf-8相比，unicode占據(jù)絕對(duì)優(yōu)勢(shì)。只有unicode的世界真美好...
但事實(shí)上，libn因?yàn)樗⒉魂P(guān)心字符集，所以它把接口的字符串類型全部聲明成char*了，如果libn也用unicode實(shí)現(xiàn)，那就完美了，可惜，這不在我的控制范圍之內(nèi)。
另外還有一種方案，在我的程序內(nèi)部使用unicode，在調(diào)用libn的接口處，轉(zhuǎn)換成utf-8，傳給libn，從libn返回的utf-8字符串，先轉(zhuǎn)成unicode再使用。這個(gè)方法聽起來也不錯(cuò)，但是很多對(duì)象并不是調(diào)用接口時(shí)才生成，也不是調(diào)用完就銷毀，這樣會(huì)導(dǎo)致我的程序內(nèi)會(huì)長(zhǎng)期存在字符串的unicode和utf-8兩種拷貝，浪費(fèi)大量?jī)?nèi)存，對(duì)于嵌入式系統(tǒng)來說，這很難容忍。
最終，我決定在我的程序內(nèi)部使用utf-8編碼，作出這個(gè)決定的最主要原因是因?yàn)槲乙褂胠ibn，雖然這樣我的程序會(huì)消耗更多的內(nèi)存、需要編寫冗長(zhǎng)難懂的字符串函數(shù)、效率也會(huì)下降，但不得不這樣。gtk+沒有使用unicode而采用utf-8，恐怕也是這樣妥協(xié)的結(jié)果吧。
后記：utf-8函數(shù)參考了glib中的實(shí)現(xiàn)。