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