DBCS和UCS編碼相關

ASCII、GB2312、GBK到GB18030都是向下兼容的，其中GB2312、GBK到GB18030都屬于雙字節字符集（DBCS字符集）
Unicode至于ANSI兼容，例如“漢”字的unicode編碼是6C49，而GB編碼是BABA
Unicode學名是“Universal Multiple-Octet Coded Chasracter Set”,簡稱UCS
UCS只是規定如何編碼，并沒有規定如何傳輸、保存這個編碼。例如“漢”字的UCS編碼是6C49，
我可以用4個ascii數字來傳輸、保存這個編碼；也可以用utf-8編碼:3個連續的字節E6 B1 89來表示它。
關鍵在于通信雙方都要認可。UTF-8、UTF-7、UTF-16都是被廣泛接受的方案。


UTF-8就是以8位為單元對UCS進行編碼。從UCS-2到UTF-8的編碼方式如下：
UCS-2編碼(16進制) UTF-8 字節流(二進制) 0000 - 007F 0xxxxxxx 0080 - 07FF 110xxxxx 10xxxxxx 0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx
例如“漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間，所以肯定要用3字節模板了：1110xxxx 10xxxxxx 10xxxxxx。將6C49寫成二進制是：0110 110001 001001，
 用這個比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。
 
 
 UTF-8以字節為編碼單元，沒有字節序的問題。UTF-16以兩個字節為編碼單元，在解釋一個UTF-16文本前，首先要弄清楚每個編碼單元的字節序。例如“奎”的Unicode編碼是594E，“乙”的Unicode編碼是4E59。如果我們收到UTF-16字節流“594E”，那么這是“奎”還是“乙”？
Unicode規范中推薦的標記字節順序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一個有點小聰明的想法：
在UCS編碼中有一個叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的編碼是FEFF。而FFFE在UCS中是不存在的字符，所以不應該出現在實際傳輸中。UCS規范建議我們在傳輸字節流前，先傳輸字符"ZERO WIDTH NO-BREAK SPACE"。
這樣如果接收者收到FEFF，就表明這個字節流是Big-Endian的；如果收到FFFE，就表明這個字節流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被稱作BOM。
UTF-8不需要BOM來表明字節順序，但可以用BOM來表明編碼方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8編碼是EF BB BF（讀者可以用我們前面介紹的編碼方法驗證一下）。所以如果接收者收到以EF BB BF開頭的字節流，就知道這是UTF-8編碼了。
Windows就是使用BOM來標記文本文件的編碼方式的。


所以，“漢”字的gbk,utf8,utf16(小端),utf16(大端)，二進制分別是

BA BA , EF BB BF E6 B1 89 ,FF FE 49 6C , FE FF 6C 49