gbk就是在儲存你的帖子的時候，乙個漢字占用兩個位元組。。外國人看會出現亂碼，此為我中華為自己漢字編碼而形成之解決方案。
utf8就是在儲存你的帖子的時候，乙個漢字占用3個位元組。。但是外國人看的話不會亂碼，此為西人為了解決多位元組字元而形成之解決方案。
ascii(iso-8859-1)是鼻祖，最簡單的方式，位元組高位為0
gb2312、gbk、gb18030，這幾個是中文編碼方式，並向下相容。gb2312包含7000多個漢字和字元，gbk包含21000多個，gb18030更厲害，到了27000多個。他們都是用2個位元組來表示乙個漢字。跟ascii是怎麼區分的呢？如果高位元組的高位為1（也就是高位元組大於127），就表示是漢字，低位元組並無明顯特徵。
unicode是統一編碼，它建立了乙個全世界統一的碼表。世界上的所有文字，在這張碼表中都是唯一的。
utf－8是unicode的一種儲存、傳輸方式。它將整個unicode碼表分為3部分。
0000 - 007f 這部分是最初的ascii部分，按原始的儲存方式，即0******x。
0080 - 07ff 這部分儲存為110***xx 10******
0800 - ffff 這部分儲存為1110***x 10****** 10******
因此，乙個漢字究竟被儲存為什麼，就需要：先查unicode碼表，然後根據在碼表的位置進行計算。例如：「電」字，在碼表中是3575，計算成utf8就是e794b5，而在gb2312的碼表中為b5e7
utf－8的好處：相容ascii，儲存英文檔案都是單位元組，檔案小。當然，當以存中文為主時就變成了3位元組編碼了，比gb系列還大！如何標明乙個檔案是utf8格式呢？這個標記是可選的：ef bb bf。比如，用windows自帶的記事本建立乙個utf8格式的檔案，就會加上這個標記。但是，如果用ultraedit建立utf8檔案，並不會加上這個標記。這個標記有個術語，叫做bom（byte order mark）。不帶bom的utf8檔案和gb2312檔案怎麼區分呢？我也不知道。唯一能想到的辦法就是：先用一種試，如果出現亂碼，就用另一種再試
utf－16是雙位元組儲存，這就帶來乙個問題，即高低位元組的順序。兩個位元組有兩種順序，它們也用bom來標明。分為大尾碼和小尾碼兩種。大尾碼的bom是feff，小尾碼的bom是fffe
gbk的中文編碼是雙位元組來表示的，英文編碼是用asc||碼表示的，既用單位元組表示。但gbk編碼表中也有英文本元的雙位元組表示形式，所以英文本母可以有2中gbk表示方式。為區分中文，將其最高位都定成1。英文單位元組最高位都為0。當用gbk解碼時，若高位元組最高位為0，則用asc||碼表解碼；若高位元組最高位為1，則用gbk編碼表解碼
至於utf－8編碼則是用以解決國際上字元的一種多位元組編。碼，它對英文使用8位（即乙個位元組），中文使用24位（三個位元組）來編碼。對於英文本元較多的論壇則用utf－8節省空間。
gbk包含全部中文字元，
utf-8則包含全世界所有國家需要用到的字元。
gbk是在國家標準gb2312基礎上擴容後相容gb2312的標準（好像還不是國家標準）
所以，對於英文比較多的論壇 ，使用gbk則每個字元占用2個位元組，而使用utf－8英文卻只佔乙個位元組。
但是如果utf8中出現中文那就是3個位元組～～具體的自己權衡。
各種編碼詳解
ascii
ascii碼是7位編碼，編碼範圍是0x00-0x7f。ascii字符集包括英文本母、阿拉伯數字和標點符號等字元。其中0x00-0x20和0x7f共33個控制字元。
只支援ascii碼的系統會忽略每個位元組的最高位，只認為低7位是有效位。hz字元編碼就是早期為了在只支援7位ascii系統中傳輸中文而設計的編碼。早期很多郵件系統也只支援ascii編碼，為了傳輸中文郵件必須使用base64或者其他編碼方式。
gb2312
gb2312是基於區位碼設計的，區位碼把編碼表分為94個區，每個區對應94個位，每個字元的區號和位號組合起來就是該漢字的區位碼。區位碼一般 用10進製數來表示，如1601就表示16區1位，對應的字元是「啊」。在區位碼的區號和位號上分別加上0xa0就得到了gb2312編碼。
區位碼中01-09區是符號、數字區，16-87區是漢字區，10-15和88-94是未定義的空白區。它將收錄的漢字分成兩級：第一級是常用漢字計3755個，置於16-55區，按漢語拼音字母/筆形順序排列；第二級漢字是次常用漢字計3008個，置於56-87區，按部首/筆畫順序排列。一級漢字是按照拼音排序的，這個就可以得到某個拼音在一級漢字區位中的範圍，很多根據漢字可以得到拼音的程式就是根據這個原理編寫的。
gb2312字符集中除常用簡體漢字字元外還包括希臘字母、日文平假名及片假名字母、俄語西里爾字母等字元，未收錄正體中文漢字和一些生僻字。可以用繁體漢字測試某些系統是不是只支援gb2312編碼。
gb2312的編碼範圍是0xa1a1-0x7e7e，去掉未定義的區域之後可以理解為實際編碼範圍是0xa1a1-0xf7fe。
euc-cn可以理解為gb2312的別名，和gb2312完全相同。
區位碼更應該認為是字符集的定義，定義了所收錄的字元和字元位置，而gb2312及euc-cn是實際計算機環境中支援這種字符集的編碼。hz和iso-2022-cn是對應區位碼字符集的另外兩種編碼，都是用7位編碼空間來支援漢字。區位碼和gb2312編碼的關係有點像 unicode和utf-8。
gbk
gbk編碼是gb2312編碼的超集，向下完全相容gb2312，同時gbk收錄了unicode基本多文種平面中的所有cjk漢字。同 gb2312一樣，gbk也支援希臘字母、日文假名字母、俄語字母等字元，但不支援韓語中的表音字元（非漢字字元）。gbk還收錄了gb2312不包含的漢字部首符號、豎排標點符號等字元。
gbk的整體編碼範圍是為0x8140-0xfefe，不包括低位元組是0×7f的組合。高位元組範圍是0×81-0xfe，低位元組範圍是0x40-7e和0x80-0xfe。
低位元組是0x40-0x7e的gbk字元有一定特殊性，因為這些字元占用了ascii碼的位置，這樣會給一些系統帶來麻煩。
有些系統中用0x40-0x7e中的字元（如「|」）做特殊符號，在定位這些符號時又沒有判斷這些符號是不是屬於某個 gbk字元的低位元組，這樣就會造成錯誤判斷。在支援gb2312的環境下就不存在這個問題。需要注意的是支援gbk的環境中小於0x80的某個位元組未必就是ascii符號；另外就是最好選用小於0×40的ascii符號做一些特殊符號，這樣就可以快速定位，且不用擔心是某個漢字的另一半。big5編碼中也存在相應問題。
cp936和gbk的有些許差別，絕大多數情況下可以把cp936當作gbk的別名。
gb18030
gb18030編碼向下相容gbk和gb2312，相容的含義是不僅字元相容，而且相同字元的編碼也相同。gb18030收錄了所有unicode3.1中的字元，包括中國少數民族字元，gbk不支援的韓文本元等等，也可以說是世界大多民族的文字元號都被收錄在內。
gbk和gb2312都是雙位元組等寬編碼，如果算上和ascii相容所支援的單位元組，也可以理解為是單位元組和雙位元組混合的變長編碼。gb18030編碼是變長編碼，有單位元組、雙位元組和四位元組三種方式。
gb18030的單位元組編碼範圍是0x00-0x7f，完全等同與ascii；雙位元組編碼的範圍和gbk相同，高位元組是0x81-0xfe，低位元組的編碼範圍是0x40-0x7e和0x80-fe；四位元組編碼中第
一、三位元組的編碼範圍是0x81-0xfe，二、四位元組是0x30-0x39。
gbk,gb2312以及unicode都既是字符集，也是編碼方式，而utf-8只是編碼方式，並不是字符集
gbk編碼中英文本元只佔乙個位元組
字串編碼轉換 GBK utf8
pagedata 如果網頁編碼是utf 8的，可以這麼轉換為字串 pagesource alloc initwithdata pagedata encoding nsutf8stringencoding 如果網頁是gbk 或者gb2312 用utf8轉換的話，pagesource返回nil。這時需要...
Python字元編碼轉碼之GBK,UTF8互轉
1 須知 在pythonwww.cppcns.com 2中預設編碼是 ascii，而在python 3中預設編碼是 unicode unicode 分為utf 32 佔4個位元組 utf 16 佔兩個位元組 utf 8 佔1 4個位元組 所以utf 16 是最常用的unicode版本，但是在檔案裡存...
PHP 編碼轉化 GBK utf 8
iconv 字串按要求的字元編碼來轉換 iconv有bug 碰到一些生僻字就會無法轉換，當然了配置第二個引數時，可以稍微彌補一下預設缺陷，不至於無法轉換是截斷，用法如下 iconv utf 8 gb2312 ignore data 這樣碰到生僻字轉換失敗時，它就會忽略失敗，繼續轉換下面的內容。ico...