Unicode 碼錶：http://www.nengcha.com/code/unicode/class/
GBK碼錶：
各種字符編碼方式詳解及由來(ANSI,UNICODE,UTF-8,GB2312,GBK) - 日誌 - yunlingzhi
2009-01-29 09:53
一直對字符的各種編碼方式懵懵懂懂，什麼ANSI、UNICODE、UTF-8、GB2312、GBK、DBCS、UCS……是不是看的很暈，假如您細細的閱讀本文你一定可以清晰的理解他們。Let's go!
很久很久以前，有一羣人，他們決定用8個可以開合的晶體管來組合成不同的狀態，以表示世界上的萬物。他們看到8個開關狀態是好的，於是他們把這稱爲"字節"。
再後來，他們又做了一些可以處理這些字節的機器，機器開動了，可以用字節來組合出很多狀態，狀態開始變來變去。他們看到這樣是好的，於是它們就這機器稱爲"計算機"。
開始計算機只在美國用。八位的字節一共可以組合出256(2的8次方)種不同的狀態。
他們把其中的編號從0開始的32種狀態分別規定了特殊的用途，一但終端、打印機遇上約定好的這些字節被傳過來時，就要做一些約定的動作。遇上00x10,
終端就換行，遇上0x07, 終端就向人們嘟嘟叫，例如遇上0x1b,
打印機就打印反白的字，或者終端就用彩色顯示字母。他們看到這樣很好，於是就把這些0x20以下的字節狀態稱爲"控制碼"。
他們又把所有的空格、標點符號、數字、大小寫字母分別用連續的字節狀態表示，一直編到了第127號，這樣計算機就可以用不同字節來存儲英語的文字了。大家
看到這樣，都感覺很好，於是大家都把這個方案叫做 ANSI 的"Ascii"編碼（American Standard Code for
Information Interchange，美國信息互換標準代碼）。當時世界上所有的計算機都用同樣的ASCII方案來保存英文文字。
後來，就像建造巴比倫塔一樣，世界各地的都開始使用計算機，但是很多國家用的不是英文，他們的字母裏有許多是ASCII裏沒有的，爲了可以在計算機保存他
們的文字，他們決定採用127號之後的空位來表示這些新的字母、符號，還加入了很多畫表格時需要用下到的橫線、豎線、交叉等形狀，一直把序號編到了最後一
個狀態255。從128到255這一頁的字符集被稱"擴展字符集"。從此之後，貪婪的人類再沒有新的狀態可以用了，美帝國主義可能沒有想到還有第三世界國
家的人們也希望可以用到計算機吧！
等中國人們得到計算機時，已經沒有可以利用的字節狀態來表示漢字，況且有6000多個常用漢字需要保存呢。但是這難不倒智慧的中國人民，我們不客氣地把那些127號之後的奇異符號們直接取消掉,
規定：一個小於127的字符的意義與原來相同，但兩個大於127的字符連在一起時，就表示一個漢字，前面的一個字節（他稱之爲高字節）從0xA1用到
0xF7，後面一個字節（低字節）從0xA1到0xFE，這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼裏，我們還把數學符號、羅馬希臘的
字母、日文的假名們都編進去了，連在 ASCII
裏本來就有的數字、標點、字母都統統重新編了兩個字節長的編碼，這就是常說的"全角"字符，而原來在127號以下的那些就叫"半角"字符了。
中國人民看到這樣很不錯，於是就把這種漢字方案叫做 "GB2312"。GB2312 是對 ASCII 的中文擴展。
但是中國的漢字太多了，我們很快就就發現有許多人的人名沒有辦法在這裏打出來，特別是某些很會麻煩別人的國家領導人。於是我們不得不繼續把 GB2312 沒有用到的碼位找出來老實不客氣地用上。
後來還是不夠用，於是乾脆不再要求低字節一定是127號之後的內碼，只要第一個字節是大於127就固定表示這是一個漢字的開始，不管後面跟的是不是擴展字
符集裏的內容。結果擴展之後的編碼方案被稱爲 GBK 標準，GBK 包括了 GB2312
的所有內容，同時又增加了近20000個新的漢字（包括繁體字）和符號。
後來少數民族也要用電腦了，於是我們再擴展，又加了幾千個新的少數民族的字，GBK 擴成了GB18030。從此之後，中華民族的文化就可以在計算機時代中傳承了。
中國的程序員們看到這一系列漢字編碼的標準是好的，於是通稱他們叫做 "DBCS"（Double Byte Charecter Set
雙字節字符集）。在DBCS系列標準裏，最大的特點是兩字節長的漢字字符和一字節長的英文字符並存於同一套編碼方案裏，因此他們寫的程序爲了支持中文處
理，必須要注意字串裏的每一個字節的值，如果這個值是大於127的，那麼就認爲一個雙字節字符集裏的字符出現了。那時候凡是受過加持，會編程的計算機僧侶
們都要每天念下面這個咒語數百遍：
"一個漢字算兩個英文字符！一個漢字算兩個英文字符……"
因爲當時各個國家都像中國這樣搞出一套自己的編碼標準，結果互相之間誰也不懂誰的編碼，誰也不支持別人的編碼，連大陸和臺灣這樣只相隔了150海里，使用
着同一種語言的兄弟地區，也分別採用了不同的 DBCS
編碼方案——當時的中國人想讓電腦顯示漢字，就必須裝上一個"漢字系統"，專門用來處理漢字的顯示、輸入的問題，但是那個臺灣的愚昧封建人士寫的算命程序
就必須加裝另一套支持 BIG5
編碼的什麼"倚天漢字系統"纔可以用，裝錯了字符系統，顯示就會亂了套！這怎麼辦？而且世界民族之林中還有那些一時用不上電腦的窮苦人民，他們的文字又怎
麼辦？
真是計算機的巴比倫塔命題啊！
正在這時，大天使加百列及時出現了——一個叫
ISO（國際標誰化組織）的國際組織決定着手解決這個問題。他們採用的方法很簡單：廢了所有的地區性編碼方案，重新搞一個包括了地球上所有文化、所有字母
和符號的編碼！他們打算叫它"Universal Multiple-Octet Coded Character Set"，簡稱 UCS, 俗稱
"UNICODE"。
UNICODE 開始制訂時，計算機的存儲器容量極大地發展了，空間再也不成爲問題了。於是 ISO
就直接規定必須用兩個字節，也就是16位來統一表示所有的字符，對於ascii裏的那些“半角”字符，UNICODE
包持其原編碼不變，只是將其長度由原來的8位擴展爲16位，而其他文化和語言的字符則全部重新統一編碼。由於"半角"英文符號只需要用到低8位，所以其高
8位永遠是0，因此這種大氣的方案在保存英文文本時會多浪費一倍的空間。
這時候，從舊社會裏走過來的程序員開始發現一個奇怪的現象：他們的strlen函數靠不住了，一個漢字不再是相當於兩個字符了，而是一個！是的，從
UNICODE
開始，無論是半角的英文字母，還是全角的漢字，它們都是統一的"一個字符"！同時，也都是統一的"兩個字節"，請注意"字符"和"字節"兩個術語的不
同，“字節”是一個8位的物理存貯單元，而“字符”則是一個文化相關的符號。在UNICODE
中，一個字符就是兩個字節。一個漢字算兩個英文字符的時代已經快過去了。
從前多種字符集存在時，那些做多語言軟件的公司遇上過很大麻煩，他們爲了在不同的國家銷售同一套軟件，就不得不在區域化軟件時也加持那個雙字節字符集咒
語，不僅要處處小心不要搞錯，還要把軟件中的文字在不同的字符集中轉來轉去。UNICODE 對於他們來說是一個很好的一攬子解決方案，於是從
Windows NT 開始，MS 趁機把它們的操作系統改了一遍，把所有的核心代碼都改成了用 UNICODE
方式工作的版本，從這時開始，WINDOWS 系統終於無需要加裝各種本土語言系統，就可以顯示全世界上所有文化的字符了。
但是，UNICODE 在制訂時沒有考慮與任何一種現有的編碼方案保持兼容，這使得 GBK 與UNICODE 在漢字的內碼編排上完全是不一樣的，沒有一種簡單的算術方法可以把文本內容從UNICODE編碼和另一種編碼進行轉換，這種轉換必須通過查表來進行。
如前所述，UNICODE
是用兩個字節來表示爲一個字符，他總共可以組合出65535不同的字符，這大概已經可以覆蓋世界上所有文化的符號。如果還不夠也沒有關係，ISO已經準備
了UCS-4方案，說簡單了就是四個字節來表示一個字符，這樣我們就可以組合出21億個不同的字符出來（最高位有其他用途），這大概可以用到銀河聯邦成立
那一天吧！
UNICODE 來到時，一起到來的還有計算機網絡的興起，UNICODE
如何在網絡上傳輸也是一個必須考慮的問題，於是面向傳輸的衆多 UTF（UCS Transfer
Format）標準出現了，顧名思義，UTF8就是每次8個位傳輸數據，而UTF16就是每次16個位，只不過爲了傳輸時的可靠性，從UNICODE到
UTF時並不是直接的對應，而是要過一些算法和規則來轉換。
受到過網絡編程加持的計算機僧侶們都知道，在網絡裏傳遞信息時有一個很重要的問題，就是對於數據高低位的解讀方式，一些計算機是採用低位先發送的方法，例
如我們PC機採用的 INTEL
架構，而另一些是採用高位先發送的方式，在網絡中交換數據時，爲了覈對雙方對於高低位的認識是否是一致的，採用了一種很簡便的方法，就是在文本流的開始時
向對方發送一個標誌符——如果之後的文本是高位在位，那就發送"FEFF"，反之，則發送"FFFE"。不信你可以用二進制方式打開一個UTF-X格式的
文件，看看開頭兩個字節是不是這兩個字節？
講到這裏，我們再順便說說一個很著名的奇怪現象：當你在 windows 的記事本里新建一個文件，輸入"聯通"兩個字之後，保存，關閉，然後再次打開，你會發現這兩個字已經消失了，代之的是幾個亂碼！呵呵，有人說這就是聯通之所以拼不過移動的原因。
其實這是因爲GB2312編碼與UTF8編碼產生了編碼衝撞的原因。
從網上引來一段從UNICODE到UTF8的轉換規則：
Unicode
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 1100 0100 1001，將這個比特流按三字節模板的分段方法分爲0110 110001
001001，依次代替模板中的x，得到：1110-0110 10-110001 10-001001，即E6 B1
89，這就是其UTF8的編碼。
而當你新建一個文本文件時，記事本的編碼默認是ANSI,如果你在ANSI的編碼輸入漢字，那麼他實際就是GB系列的編碼方式，在這種編碼下，"聯通"的內碼是：
c1 1100 0001
aa 1010 1010
cd 1100 1101
a8 1010 1000
注意到了嗎？第一二個字節、第三四個字節的起始部分的都是"110"和"10"，正好與UTF8規則裏的兩字節模板是一致的，於是再次打開記事本時，記事
本就誤認爲這是一個UTF8編碼的文件，讓我們把第一個字節的110和第二個字節的10去掉，我們就得到了"00001
101010"，再把各位對齊，補上前導的0，就得到了"0000 0000 0110
1010"，不好意思，這是UNICODE的006A，也就是小寫的字母"j"，而之後的兩字節用UTF8解碼之後是0368，這個字符什麼也不是。這就
是隻有"聯通"兩個字的文件沒有辦法在記事本里正常顯示的原因。
而如果你在"聯通"之後多輸入幾個字，其他的字的編碼不見得又恰好是110和10開始的字節，這樣再次打開時，記事本就不會堅持這是一個utf8編碼的文件，而會用ANSI的方式解讀之，這時亂碼又不出現了。
好了，終於可以回答NICO的問題了，在數據庫裏，有n前綴的字串類型就是UNICODE類型，這種類型中，固定用兩個字節來表示一個字符，無論這個字符是漢字還是英文字母，或是別的什麼。
如果你要測試"abc漢字"這個串的長度，在沒有n前綴的數據類型裏，這個字串是7個字符的長度，因爲一個漢字相當於兩個字符。而在有n前綴的數據類型裏，同樣的測試串長度的函數將會告訴你是5個字符，因爲一個漢字就是一個字符。
- 類定義
- class CChineseCode
- {
- public:
- static void UTF_ 8 ToUnicode(wchar_t* pOut,char *pText); // 把UTF -8 轉換成Unicode
- static void UnicodeToUTF_ 8 (char* pOut,wchar_t* pText); //Unicode 轉換成UTF -8
- static void UnicodeToGB 2312 (char* pOut,wchar_t uData); // 把Unicode 轉換成 GB 2312
- static void Gb 2312 ToUnicode(wchar_t* pOut,char *gbBuffer);// GB 2312 轉換成 Unicode
- static void GB 2312 ToUTF_ 8 (string& pOut,char *pText, int pLen);//GB 2312 轉爲 UTF -8
- static void UTF_ 8 ToGB 2312 (string &pOut, char *pText, int pLen);//UTF -8 轉爲 GB 2312
- };
- 類實現
- void CChineseCode::UTF_8 ToUnicode(wchar_t* pOut,char *pText)
- {
- char* uchar = (char *)pOut;
- uchar[1 ] = ((pText[ 0 ] & 0x0 F) << 4 ) + ((pText[ 1 ] >> 2 ) & 0x0 F);
- uchar[0 ] = ((pText[ 1 ] & 0x03 ) << 6 ) + (pText[ 2 ] & 0x3 F);
- return;
- }
- void CChineseCode::UnicodeToUTF_8 (char* pOut,wchar_t* pText)
- {
- // 注意 WCHAR高低字的順序,低字節在前，高字節在後
- char* pchar = (char *)pText;
- pOut[0 ] = ( 0 xE 0 | ((pchar[ 1 ] & 0 xF 0 ) >> 4 ));
- pOut[1 ] = ( 0x80 | ((pchar[ 1 ] & 0x0 F) << 2 )) + ((pchar[ 0 ] & 0 xC 0 ) >> 6 );
- pOut[2 ] = ( 0x80 | (pchar[ 0 ] & 0x3 F));
- return;
- }
- void CChineseCode::UnicodeToGB2312 (char* pOut,wchar_t uData)
- {
- WideCharToMultiByte(CP_ACP,NULL,&uData,1 ,pOut,sizeof(wchar_t),NULL,NULL);
- return;
- }
- void CChineseCode::Gb2312 ToUnicode(wchar_t* pOut,char *gbBuffer)
- {
- ::MultiByteToWideChar(CP_ACP,MB_PRECOMPOSED,gbBuffer,2 ,pOut, 1 );
- return ;
- }
- void CChineseCode::GB2312 ToUTF_ 8 (string& pOut,char *pText, int pLen)
- {
- char buf[4 ];
- int nLength = pLen* 3 ;
- char* rst = new char[nLength];
- memset(buf,0,4 );
- memset(rst,0 ,nLength);
- int i = 0 ;
- int j = 0 ;
- while(i < pLen)
- {
- //如果是英文直接複製就可以
- if( *(pText + i) >= 0 )
- {
- rst[j++] = pText[i++];
- }
- else
- {
- wchar_t pbuffer;
- Gb2312 ToUnicode(&pbuffer,pText+i);
- UnicodeToUTF_8 (buf,&pbuffer);
- unsigned short int tmp = 0 ;
- tmp = rst[j] = buf[0 ];
- tmp = rst[j+1 ] = buf[ 1 ];
- tmp = rst[j+2 ] = buf[ 2 ];
- j += 3 ;
- i += 2 ;
- }
- }
- rst[j] = '' ;
- //返回結果
- pOut = rst;
- delete []rst;
- return;
- }
- void CChineseCode::UTF_8 ToGB 2312 (string &pOut, char *pText, int pLen)
- {
- char * newBuf = new char[pLen];
- char Ctemp[4 ];
- memset(Ctemp,0,4 );
- int i =0 ;
- int j = 0 ;
- while(i < pLen)
- {
- if(pText[i] > 0 )
- {
- newBuf[j++] = pText[i++];
- }
- else
- {
- WCHAR Wtemp;
- UTF_8 ToUnicode(&Wtemp,pText + i);
- UnicodeToGB2312 (Ctemp,Wtemp);
- newBuf[j] = Ctemp[0 ];
- newBuf[j + 1 ] = Ctemp[ 1 ];
- i += 3 ;
- j += 2 ;
- }
- }
- newBuf[j] = '' ;
- pOut = newBuf;
- delete []newBuf;
- return;
- }
