UTF-8與GB2312區別

GB2312是GBK的子集，GBK是GB18030的子集
GBK是包括中日韓字符的大字符集合
如果是中文的網站 推薦GB2312 GBK有時還是有點問題
爲了避免所有亂碼問題，應該採用UTF-8，將來要支持國際化也非常方便
UTF-8可以看作是大字符集，它包含了大部分文字的編碼。
使用UTF-8的一個好處是其他地區的用戶（如香港臺灣）無需安裝簡體中文支持就能正常觀看你的文字而不會出現亂碼。
詞條：UTF8
UTF8並不算是一種電腦編碼，而是一種儲存和傳送的格式，如前所述，每個Unicode/UCS字符都以 2或4個bytes來儲存，看看以下的比較：
　　以"I am Chinese"爲例
　　　用ANSI儲存：12 Bytes
　　　用Unicode/UCS2儲存：24 Bytes + 2 Bytes(header)
　　　用UCS4儲存：48 Bytes + 4 Bytes(header)
　　以"我是中國人"爲例
　　　用ANSI儲存：10 Bytes
　　　用Unicode/UCS2儲存：10 Bytes + 2 Bytes(header)
　　　用UCS4儲存：20 Bytes + 4 Bytes(header)
　　由此可見直接以Unicode/UCS的原始形式來儲存是一種極大的浪費，而且也不利於互聯網的傳輸(中文稍爲合算一點^_^)。
　　有見及此，Unicode/UCS的壓縮形式－－UTF8出現了，套用官方網站的首句話『UTF-8 stands for Unicode Transformation Format-8. It is an octet (8-bit) lossless encoding of Unicode characters.』，由於UTF也適用於編碼UCS，故亦可稱爲『UCS transformation formats (UTF)』
　　UTF8是以8bits即1Bytes爲編碼的最基本單位，當然也可以有基於16bits和32bits的形式，分別稱爲UTF16和UTF32，但目前用得不多，而UTF8則被廣泛應用在文件儲存和網絡傳輸中。

編碼原理
先看這個模板：
UCS-4 range (hex.) UTF-8 octet sequence (binary)
0000 0000-0000 007F 0xxxxxxx
0000 0080-0000 07FF 110xxxxx 10xxxxxx
0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx
編碼步驟：
1) 首先確定需要多少個8bits(octets)
2) 按照上述模板填充每個octets的高位bits
3) 把字符的bits填充至x中，字符順序：低位→高位，UTF8順序：最後一個octet的最末位x→第一個octet最高位x
4) 解碼的原理一樣。
實例：(留意每個bit的顏色，粗體字爲模板內容)
UCS-4 UTF-8
HEX BIN Bytes BIN HEX Bytes
0000 000A 00001010 4 00001010 0A 1
0000 0099 10011001 4 11000010 10011001 C2 99 2
0000 8D99 10001101 10011001 4 11101000 10110110 10011001 E8 B6 99 3
　　不知大家看懂了沒有，其實不懂也無所謂，反正又不用自己算，程式可以完全代勞。
　　以UTF8格式儲存的文件檔首標識爲EF BB BF。

效率
　　從上述編碼原理中得出的結論是：
　　　1.每個英文字母、數字所佔的空間爲1 Byte；
　　　2.泛歐語系、斯拉夫語字母佔2 Bytes；
　　　3.漢字佔3 Bytes。
　　由此可見UTF8對英文來說是個非常誘人的方案，但對中文來說則不太合算，無論用ANSI還是 Unicode/UCS2來編碼都只用2 Bytes，但用UTF8則需要3 Bytes。
　　以下是一些統計資料，顯示用UTF8來儲存文件每個字符所需的平均字節：
　　　1.拉丁語系平均用1.1 Bytes；
　　　2.希臘文、俄文、阿拉伯文和希伯萊文平均用1.7 Bytes；
　　　3.其他大部份文字如中文、日文、韓文、Hindi(北印度語)用約3 Bytes；
　　　4.用超過4 Bytes的都是些非常少用的文字符號。
詞條：GB2312
字符必須編碼後才能被計算機處理。計算機使用的缺省編碼方式就是計算機的內碼。早期的計算機使用7位的ASCII編碼，爲了處理漢字，程序員設計了用於簡體中文的GB2312和用於繁體中文的big5。
GB2312(1980年)一共收錄了7445個字符，包括6763個漢字和682個其它符號。漢字區的內碼範圍高字節從B0-F7，低字節從A1-FE，佔用的碼位是72*94=6768。其中有5個空位是D7FA-D7FE。
GB2312支持的漢字太少。1995年的漢字擴展規範GBK1.0收錄了21886個符號，它分爲漢字區和圖形符號區。漢字區包括21003個字 符。2000年的GB18030是取代GBK1.0的正式國家標準。該標準收錄了27484個漢字，同時還收錄了藏文、蒙文、維吾爾文等主要的少數民族文 字。現在的PC平臺必須支持GB18030，對嵌入式產品暫不作要求。所以手機、MP3一般只支持GB2312。
從ASCII、GB2312、GBK到GB18030，這些編碼方法是向下兼容的，即同一個字符在這些方案中總是有相同的編碼，後面的標準支持更多 的字符。在這些編碼中，英文和中文可以統一地處理。區分中文編碼的方法是高字節的最高位不爲0。按照程序員的稱呼，GB2312、GBK到GB18030 都屬於雙字節字符集 (DBCS)。
有的中文Windows的缺省內碼還是GBK，可以通過GB18030升級包升級到GB18030。不過GB18030相對GBK增加的字符，普通人是很難用到的，通常我們還是用GBK指代中文Windows內碼。
這裏還有一些細節：
GB2312的原文還是區位碼，從區位碼到內碼，需要在高字節和低字節上分別加上A0。
在DBCS中，GB內碼的存儲格式始終是big endian，即高位在前。
GB2312的兩個字節的最高位都是1。但符合這個條件的碼位只有128*128=16384個。所以GBK和GB18030的低字節最高位都可能 不是1。不過這不影響DBCS字符流的解析：在讀取DBCS字符流時，只要遇到高位爲1的字節，就可以將下兩個字節作爲一個雙字節編碼，而不用管低字節的 高位是什麼