原文地址：tsoukw.cnblogs.com/archive/2006/07/13/449588.html
很久沒有寫blog了﹐今天下午工作剛好告一段落﹐有點時間﹐就把上週花了很多時間總結出來的一些計算機字符相關的心得寫出來﹐希望能夠幫助當初和我一樣迷茫的人能夠容易理解﹐也希望能夠引出玉來(這麼多廢話﹐還不快開始...)
由於公司使用的是繁體操作系統﹐而我有時習慣在自己家裏的簡體計算機上寫一些程序﹐但是當我用U盤把代碼在兩者之間copy時﹐經常發現文件中文的地方成了亂碼﹐所以就花了些時間到網上查了一下﹐發現有很多關於亂碼問題的討論﹐按自己的方法總結了一下(有不對的地方﹐還希望各位指出):
1.文件分爲文本文件和二進制文件﹐不過本質都一樣﹐都是些01。
2.計算機存儲設備存儲的0或1﹐稱爲計算機的一個二進制位(bit)。
3.二進制文件的0和1有專門的應用程序來讀﹐所以它們沒有什麼亂不亂碼的問題﹐只要該程序認得就行。(像doc,xls,exe,dll等)
4.文本文件就不一樣了﹐notepad要認識它﹐vs.net要認識它,UE也要認識它...所以它們就要有一個標準。這個標準的原理其實很簡單﹐就是把所有的字符都給它一個序號﹐然後根據這個序號來找字符就可以了。這個東東就是編碼表,也叫字符集(charset)。
5.文本文件存的都是字符﹐如﹕A,?,@,x。很明顯一個bit不能表示﹐剛好計算機的存儲單位--字節(byte)就是多個字節(1個byte=8個bit),因此用byte來表示字符就理所當然了。
6.第一個編碼表--ASCII碼很快產生﹐很簡單﹐就是用一個byte來表示一個字符(最高位置0),總共能存儲128(2^8)個字符。如A用65表示﹐存在計算機中就是01000001(65)﹐爲了書寫方便﹐我們一般記作0x41(16進制),97則表示小寫的a,存在計算機中就是01100001(97)﹐記作0x61。?用63表示,記作0x3F。
7.英語國家的大小寫字母加起來才52個字符﹐再加上數字﹐符號和一些特殊字符﹐已經足夠使用。所以ASCII剛開始非常流行(誰叫計算機不是咱中國發明的... )
8.隨着計算機的普及﹐當非英語系的國家開始使用時﹐ASCII已經明顯不能滿足了(總不成天天使用xiao sheng來表示"小生"吧),所以這些國家(地區)就開始制訂自己的標準。
9.中國大陸制訂了簡體漢字的字符集(GB2312)。和英語國家不同﹐我們的漢字遠遠不止128個﹐所以一個byte肯定不能表示完﹐那就多加個byte,16位(65536)總可以了吧。不過這樣雖解決了位數不夠的問題﹐但是原來的英文文件怎麼辦?總不成又全部拿出來改成雙字節吧。幸好﹐居然發現原來的ASCII的第一位居然是0﹐那我們把第1位改成1不就OK了嗎?以後凡看到0開頭的就讀1個字節﹐1開頭的就讀2個字節。(而且128*128表示所有的簡體字也足夠了)
10.因此在GB2312標準中,"小"的序號是0xD0A1,表示成11010000 10100001,而A還是表示成01000001,這就是爲什麼簡體操作系統讀ASCII文件不會亂碼﹐而反之則不然的原因。
11.目前來說﹐情況還比較好﹐中國大陸的計算機運行正常。
12.看到中國大陸制訂了一個標準﹐其它國家和地區也不甘示弱﹐紛紛亮出自己的字符集,於是乎什麼BIG5(中國臺灣),shift_jis(日本),ks_c_5601-1987(韓國)都閃亮登場﹐一時間百鳥爭鳴,百花齊放。
13.每個國家都想與ASCII保持兼容﹐理所當然﹐後面的字符就完全不一樣了﹐因此﹐同樣的0xD0A1,在GB2312中是"小"字﹐而在BIG5中卻是"苤"字。你想想﹐這樣不亂纔怪。
14.到了這時候﹐總有人會想到﹐再這樣繼續下去是肯定不行的﹐於是它們就想到了﹐如果有一個標準﹐能包括所有字符那不就OK了嗎?
15.於是"大哥大"標準就出來了﹐這就是unicode,爲了能夠足夠表示世界上的所有字符這樣光榮而又偉大的任務﹐這傢伙用了四個字節來表示(2的32次方到底是多少﹐我也懶得算了),這下好了﹐天下太平了﹐再也不會有麻煩了﹐耳根清靜了...(打住﹐你小子這麼這麼羅嗦呀)
15.不過unicode好是好﹐但是畢竟四個字節表示一個字符"浪費"太大了(我那破貓上網容易嗎﹐電信黑呀﹐說好是2M﹐就給我200K...)﹐而且大家"驚奇"地發現﹐居然世界上一些"較強大"的國家的字符剛好集中在前65536位前﹐呵呵﹐結果unicode也分成了unicode-16和unicode-32了﹐自然﹐前者只用兩個字節表示(所以只能表示前65536位嘍,歐亞國家大部分字符都OK了﹐什麼﹐你們那個@$Y$%字符沒有﹐呵呵﹐不管我什麼事,找標準協會﹐都是那幫傢伙弄的...)
16.雖然標準出來了﹐可是好歹ASCII也用了這麼久﹐那些英語國家也在那裏嚷嚷﹐這倒好﹐搞個什麼破標準﹐我們又沒有得到什麼好處﹐反而讓我們原來的程序都運行不了了(爲什麼呀﹐你想想﹐原來我們的程序字符都是一個字節一個字節認﹐現在倒好﹐全改成2個一起認﹐這還怎麼跑呀?)﹐況且我們憑白無故了用了這麼多0﹐真彆扭(unicode中的前128位還是ASCII標準﹐只不過在前面加了8個0)﹐由於那些國家"勢力"比較大﹐所以這個問題不容忽視
17.這個世界上的牛人總是這麼多﹐這個問題很容易就被小意思地解決了。
18.想想GB2312怎麼解決與ASCII兼容的問題的(1開頭的就讀2個字節﹐0開頭的就讀1個字節)﹐同樣﹐UTF也這樣﹐0開頭的讀1個字節(ASCII碼)﹐110開頭的讀2個字節﹐1110開頭的讀3個字節﹐這就是偉大的UTF-8(當然還有UTF-16,原理一樣﹐xx開頭的讀4個字節﹐xx開頭的讀5個字節﹐xx開頭的讀6個字節)
19.當然UTF-8沒GB2312這麼簡單﹐讀完之後不能直接查編碼表﹐多加一個步驟﹐按照模板提取一下字符再查就OK了
以下就是UTF-8的模板
0x0000 - 0x007F用一個字節表示 0xxxxxxx
0x0080 - 0x07FF用兩個字節表示 110xxxxx 10xxxxxx
0x0800 - 0xFFFF用三個字節表示 1110xxxx 10xxxxxx 10xxxxxx
舉個例子吧,
如果你遇到了11100110 10110001 10001001 01000001 這樣的字節流﹐首先你看第一個字節以1110開頭﹐即讀3個字節並按模板提取得到 0110 110001 001001(去除模板標誌﹐再四字節四字節讀即0x6c49),查unicode編碼表就是"漢"字,而最後一個以0開頭就一定是一個字節了﹐0x0041,也就是"A"。
20.好了﹐上面是原理﹐再來談談簡繁體操作系統轉換時的亂碼問題吧
21.按照我的想法﹐windows操作系統應該有一個默認的系統字符集﹐如簡體操作系統應該是GB碼﹐繁體操作系統則是BIG5,英文操作系統是ASCII。系統內的軟件(notepad)默認都是使用這個字符集。
22.所以我在繁體操作系統默認存儲的文本文件就是BIG5了﹐當這個文件到了簡體系統裏﹐它的notepad程序則使用自己的默認編碼(GB)來讀取﹐這樣就亂了。
23.因此如果在保存時就使用utf-8來保存﹐應該在兩系統切換時就不會有問題了。
24.而要解決這個問題其實也很簡單﹐只要知道這個文本文件原來的編碼就可以了﹐使用它讀出來﹐再轉成unicode即可。
上面的東東都是我用自己的理解來解釋的﹐當然有些東西我避開了﹐主要是想讓大家更容易理解原理﹐想要更正式的內容大家到網上隨便一搜就出來了。
