只要你和計算機打交道，這些問題可以說是天天會遇到，但是很多人是似懂非懂， 能真正完全理解的人卻不多， 下面是個人的一些理解，有錯歡迎指正.
最早的計算機只支持ASCII碼， 具體來說就是用1個字節(最高位為0， 沒有用)表示0到127，總共128個字符， 這樣就可以完全滿足英語應用的要求了。
后來擴展到歐洲語系，理論上一個字節可以表示256個字符， 歐洲人就把剩余的128個字符(最高位為1)按照自己語言(法語,德語...)的要求擴充應用了起來， 好像也能滿足需要。
然后又到了亞洲國家，比如中國，中文漢字有十多萬，這剩余的128個字符根本不夠我用啊， 怎么辦？ 于是就有了兩個字節的編碼，如中文的GBK， GB2312， BIG5等，當然日語，韓語等其他亞洲國家也有自己編碼方式。
這就是所謂的多字節編碼(MBCS)方式, Win95/98時代只支持這種方式， 那時候處理字符串非常痛苦， 因為它里面有些字符是一個字節表示的，也有一些是多個字節表示的， 比如字符串"你好abc", 里面明明是5個字符，strlen返回長度卻是7, 你要正確識別字符個數，可以使用類似_mbslen的API， 但是實際上該API內部會綁定當前的字符集， 不然神仙也識別不了。
要統一解決上面的問題， 需要有一個世界通用的統一編碼格式， 那就是UNICODE。
UNICODE個人感覺分廣義和狹義， 廣義的UNICODE包括UTF8， UCS2， UCS4， 而狹義的UNICODE（主要是Windows平臺）就是指UCS2。
先說UCS2， Windows平臺上常說的UNICODE實際上就是指UCS2， 簡單來說就是統一用2個字節的編碼，表示實際上所有語言的常用字符。
再說UTF8， 有了上面的UCS2，為甚么還有要UTF8？ UCS2把任何字符全都編碼成2個字節（包括我們常用的英文字符）， 這樣極大地增加了網絡傳輸和數據存儲的開銷，于是就有了UTF8。UTF8對英文字符還是1個字節存儲，只對其他語言字符用多個字節存儲（2-6個字節）。UTF8和UNICODE可以完全對應的相互轉換， 具體可以參考這里
為什么還要有 UCS4？ UCS2用2個字節，最多也只能表示0xFFFF+1 = 65536個字符， 但是我們僅漢字就有十多萬，所以UCS2/UTF8收錄的也只是我們一些常用的漢字， 所以我們需要UCS4， 用4個字節表示一個字符，可以表示0xFFFFFFFF+1=4294967296個字符， 它才是我們以后的終極解決方案。
在Windows上不同編碼方式的相互轉換可以通過WideCharToMultiByte和MutiByteToWideChar進行， 它里面WideChar就是指UCS2， 可以看到它這里把UTF8也命名成MultiByte, 是不是有點誤導...
下面再談小大小端(little-endian， big-endian).
計算機是以字節為尋址單位的，這就涉及到字(2個字節), 雙字(4個字節)及其他多字節單位 在計算機內如何排布的問題， 這里無非就是2種：低字節在低地址的little-endian和高字節在低地址的big-endian.
如何區分當前系統是哪種類型的大小端？ 曾經看到有經驗的程序員也以當前的操作系統類型來判斷， 實際上系統的大小端和你的CPU架構體系相關聯， 比如說X86是小端， PowPC是大端，ARM則是可控制（默認也是小端）。
要判斷當前環境是大小端實際上很簡單: bool IsLittleEndian() { int i=1; return (*(char *)&i == 1); }
曾經看到公司跨平臺的代碼沒有通過大小端轉換，直接通過memcpy某個表示長度的int在客戶端之間傳送，卻沒有發生問題， 感覺很奇怪, 最后發現原來當前公司的所有客戶端（Win, Mac, ios, Android,BlackBerry,Linux)全都是小端。感覺現在大端的應用主要是網絡字節序， Java內部全都是大端。
上面的UCS2和UCS4因為都是用多字節表示一個字符， 所以實際上都有大小端的問題，比如分別對應UCS2-LE和UCS2-BE，Windows上的UNICODE實際上是UCS2-LE， UTF8因為是字節流，所以沒有大小端的問題。
下面再說一下BOM (Byte Order Mark), 上面說了各種編碼方式以及大小端的問題， 那么我們怎么知道某個文本或者數據流是何種編碼方式？
一般來說有3種方法：一種是分本顯示指定， 比如web里html頭一般會有這么一段"content="text/html;charset=utf-8"； 要不就是大家默認約定，比如自定義的網絡數據流內的字符串一般都會用UTF8編碼； 還有一種就是用BOM，通過在文件頭里填入BOM規定的字節，從而區分文件是何種編碼類型:
| UTF-8 | 0xEF 0xBB 0xBF |
| UTF-16 BE | 0xFE 0xFF |
| UTF-16 LE | 0xFF 0xFE |
| UTF-32 BE | 0x00 0x00 0xFE 0xFF |
| UTF-32 LE | 0xFF 0xFE 0x00 0x00 |
有興趣的同學可以用notepad保存，試下各種效果， 然后用UltraEdit的16進制方式查看驗證。
最后討論下C++編程中常見的關于字符編碼方式相關的問題。
在C++編程中， 我們常打交道的無非是編輯器和編譯器， 對編輯器起來說，我們常遇到就是亂碼問題， 比如中文注釋顯示或是保存不了等， 解決辦法就是把你的文件保存成Unicode（UTF8）。
對于編譯器來說， 編碼方式取決于它對C++標準的支持程度， 比如C++ 11以前，字符串我們只能指定成2種：一種是MBCS，如char* p="abc哈哈"； 還有一種是UCS2， 比如wchar_t*p = L"abc哈哈"， 這樣編譯器就知道你要表示的字符串類型。C++11之后，標準增加了UTF8和UCS4的支持， 比如char* p=u8"abc哈哈"表示UTF8，wchar_t* p=u"abc哈哈"表示UCS2(實際上和L"xxxx"一樣), char32_t* p=U"abc哈哈"表示UCS4。這里要區分編譯期和運行期， 盡管C++11之前我們沒法告訴編譯器我們這個常量串是UTF8格式的，但是程序期我們還是可以使用所有的編碼式(MBCS/UTF8/UCS2/UCS4)， 因為這些最終在內存里都是二進制流。
另外C++11還增加了UTF8， UCS2， UCS4相互轉碼的支持：
| std::codecvt_utf8 | 封裝了UTF8相關的編碼轉換 |
| std::codecvt_utf16 | 封裝了UCS2相關的編碼轉換 |
| std::codecvt_utf8_utf16 | 封裝了UTF8與UCS2的編碼轉換 |
對于C++跨平臺開發， 我們經常遇到的就是默認用那種編碼方式的問題，我們會發現Windows 的UCS2解決方案對其他平臺來說是個異類， 一般來說有2種解決方法：
一種是統一用UTF8 ， 但是這樣對Windows來說有點麻煩， 因為Windows的API都是UCS2的，所以這種方式意味著任何字符串在傳給Windows API 之前都要從UTF8轉成UCS2; 還有一種就是用#define宏了， Windows上將字符串相關宏全都定義成UCS2, 其他平臺則全都定義成UTF8， 該方式要求就你在寫代碼時頭腦要比較清醒，因為同樣的代碼在不同平臺上的編碼格式是不一樣的。
一直很好奇，誰知道Windows為什么不用UTF8，非要搞得和其他平臺不一樣？
浙公網安備 33010602011771號