正式解釋;:http://m.shnenglu.com/mzty/archive/2005/12/06/1565.html

???????? ;:http://m.shnenglu.com/mzty/archive/2005/12/06/1564.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即可。

上面的東東都是我用自己的理解來解釋的﹐當然有些東西我避開了﹐主要是想讓大家更容易理解原理﹐想要更正式的內容大家到網上隨便一搜就出來了。

在證明那些東東之前﹐首先把.net中關于處理encoding,二進制,16進制,byte等相關類別和方法羅列一下。

1.byte與string(那些255以內的整數)的相互轉換(各種進制之間的相互轉換)
使用System.Convert類別
string to byte
Convert.ToByte(string,base)
base:2表示二進制,8表示八進制,10表示十進制,16表示十六進制(你要輸入33,呵呵﹐異常)
這樣可以把字符串的(0--255)轉成一個byte
Convert.ToByte("01000001",2)轉成 65
Convert.ToByte("255",10)轉成255
Convert.ToByte("42",16)轉成66

同理﹐byte to string也是Convert類
Convert.ToString(byte,base)
同樣可以轉成相應的進制表示的字符串

通過這兩個方法﹐我們要進行2,8,10,16進制的相互轉換就容易了

2.char,int,long,boolean等與byte[]之間的相互轉換(這些數據在內存中的存儲狀況)
使用System.BitConverter類別
我們都知道char,int,long等基本類型是以字節形式存在內存中的﹐所以要查看其內存存儲方式則直接使用BitConverter.GetBytes()就可以了
然后再使用BitConverter.ToString(byte[])就可以以string方式查看了(如:f9-03表示2個字節)

string是由char組成的﹐只要foreach(char in string)就可以看到string的存儲方式了(實驗表明﹐string在內存中是以unicode編碼存在的,下有示例)

3.各種Encoding之間的轉換
使用System.Text中的Encoding相關的類別就可以了
包括Encoding,ASCIIEncoding,UTF8Encoding等,當然也可以通過Encoding.GetEncoding()來獲取不同的編碼。
然后再通過GetBytes(string)方法﹐就可以獲取string的不同編碼的byte數組了
通過GetString(byte[])方法﹐就可以把某種編碼的byte數組轉成字符串.
如"I am 小生,hello world!"的各種bytes編碼測試

using?System;
using?System.Collections;
using?System.Text;

public?class?MyClass
{
?public?static?void?Main()
?{
??string?tmp?=?"I?am?小生,hello?world!";
??WL("內存中存儲的字節數組﹕");
??
??foreach(char?c?in?tmp)
??{
???byte[]?b?=?BitConverter.GetBytes(c);
???Console.Write(BitConverter.ToString(b)?+?"-");
??}
??WL("");
??WL("unicode字節數組﹕");
??byte[]?bs1?=?Encoding.Unicode.GetBytes(tmp);
??WL(BitConverter.ToString(bs1));
??WL("utf8字節數組﹕");
??
??byte[]?bs2?=?Encoding.UTF8.GetBytes(tmp);
??WL(BitConverter.ToString(bs2));
??WL("default字節數組﹕");
??byte[]?bs3?=?Encoding.Default.GetBytes(tmp);
??WL(BitConverter.ToString(bs3));
??WL("big5字節數組﹕");
??byte[]?bs4?=?Encoding.GetEncoding(950).GetBytes(tmp);
??WL(BitConverter.ToString(bs4));
??RL();
?}
?
?private?static?void?WL(string?text,?params?object[]?args)
?{
??Console.WriteLine(text,?args);?
?}
?
?private?static?void?RL()
?{
??Console.ReadLine();?
?}
?
?private?static?void?Break()?
?{
??System.Diagnostics.Debugger.Break();
?}
}

?

在下面開始之前﹐先摘錄一段關于BOM的知識

-----------------------------------------------------------------
UTF的字節序和BOM

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來標記文本文件的編碼方式的。

----------------------------------------------------------

好了﹐這些問題解決后﹐我們就來做單純的文本文件的編碼識別﹐讀取與寫入測試吧。
以windows的notepad為例(其它的文本文件讀取軟件的原理應該也差不多﹐只是會多一些特殊的判斷算法而已)。

notepad默認有四種編碼來存儲和讀取文本文件。分別是﹕
ANSI,Unicode,Unicode-big-endian和UTF-8。
首先來講ANSI吧﹐這個是windows操作系統在區域與語言塊設置的編碼(也就是系統默認的編碼)﹐因此像繁體操作系統就是big5,而簡體操作系統則是GBK。

而Unicode和UTF-8這兩種格式相信大家已經有所了解(當然前者是unicode-16)

而Unicode-big-endian是什么意思呢﹐它與Unicode幾乎一樣﹐只是它把高位放在前面(而后者則剛好相反)
上面的摘錄已經有所說明﹐這里再解釋一下﹕
如同樣是字符"A"﹐在以下幾種格式中的存儲形式分別是﹕
UTF-16 big-endian : 00 41
UTF-16 little-endian : 41 00
UTF-32 big-endian : 00 00 00 41
UTF-32 little-endian : 41 00 00 00

好了﹐大家想一想﹐文本文件在硬盤中是以字節形式存儲的﹐如果不知道文本文件的編碼﹐那是無論如何也不能正確讀出文本文件顯示給用戶看的(亂碼了只有人才知道﹐程序則認為一切正常)

根據BOM的規則﹐因此在一段字節流開始時﹐如果接收到以下字節﹐則分別表明了該文本文件的編碼。
UTF-8: EF BB BF
UTF-16 : FF FE
UTF-16 big-endian: FE FF
UTF-32 little-endian: FF FE 00 00
UTF-32 big-endian: 00 00 FE FF
而如果不是以這個開頭﹐那程序則會以ANSI,也就是系統默認編碼讀取。

所以現在我們來做個測試就可以很清楚地對以上的東東進行驗證了。
1.用notepad輸入"漢A"這2個字符﹐然后分別保存成ANSI,Unicode,Unicode-big-endian和UTF-8,名字分別取為ansi.txt,unicode.txt,unicode_b.txt,utf8.txt,并且放在c盤根目錄下

2.用以下程序進行驗證

using?System;
using?System.Collections;
using?System.IO;

public?class?MyClass
{
?private?static?void?writefile(string?path)
?{
??FileStream?fs?=?null;
??try{
???fs?=?new?FileStream(path,FileMode.Open);
???byte[]?bs?=?new?byte[fs.Length];
???fs.Read(bs,0,bs.Length);
???WL(BitConverter.ToString(bs));
???SixTTwo(BitConverter.ToString(bs));
??}
??catch(Exception?ex)
??{
???WL(ex.ToString());
??}?
??finally
??{
???if(fs!=null)
????fs.Close();
??}
?}
?
?public?static?void?Main()
?{
??string?path;
??WL("ANSI文件格式的字節流﹕");
??path?=?"c:\\ansi.txt";
??writefile(path);
??
??WL("Unicode文件格式的字節流﹕");
??path?=?"c:\\unicode.txt";
??writefile(path);
??
??WL("Unicode-big-endian文件格式的字節流﹕");
??path?=?"c:\\unicode_b.txt";
??writefile(path);
??
??WL("utf-8文件格式的字節流﹕");
??path?=?"c:\\utf8.txt";
??writefile(path);
??RL();
?}
?
?public?static?void?SixTTwo(string?sixstr)
?{
??string[]?tmp?=?sixstr.Split(new?char[]{'-'});
??foreach(string?s?in?tmp)
??{
???

Console.Write(Convert.ToString(Convert.ToByte(s,16),2).PadLeft(8,'0')+?"?

");
??}
??WL("");
?}
?
?private?static?void?WL(string?text,?params?object[]?args)
?{
??Console.WriteLine(text,?args);?
?}
?
?private?static?void?RL()
?{
??Console.ReadLine();?
?}
?
?private?static?void?Break()?
?{
??System.Diagnostics.Debugger.Break();
?}
}

3.以下是輸出格式﹕
ANSI文件格式的字節流﹕
BA-BA-41
10111010 10111010 01000001
Unicode文件格式的字節流﹕
FF-FE-49-6C-41-00
11111111 11111110 01001001 01101100 01000001 00000000
Unicode-big-endian文件格式的字節流﹕
FE-FF-6C-49-00-41
11111110 11111111 01101100 01001001 00000000 01000001
utf-8文件格式的字節流﹕
EF-BB-BF-E6-B1-89-41
11101111 10111011 10111111 11100110 10110001 10001001 01000001

從以上結果可以很容易的看到BABA正是"漢"字的gb2312編碼﹐當然我的操作系統是繁體的﹐如果我直接雙擊打開﹐則可以看到"犖A"﹐這是亂碼﹐因為我的系統baba查的是big5﹐而baba的big5碼正是"犖"

然而還有其它很多程序﹐像IE呀,它可以使用meta標簽來識別文件的編碼,xml也是可以通過encoding屬性來說明文件的編碼的﹐所以這些程序的識別方法和普通的又有些不同罷了。

同樣﹐寫一個文本文件時﹐先寫入這些標記符﹐則也會幫助notepad識別這些文件的編碼(當然.net專門提供了一些類別﹐如StreamWriter﹐可以直接存成某種編碼的格式)。

至于各種encoding之間的轉換﹐我想也不必多說了﹐通過Encoding類的Convert,GetBytes和GetString方法是很容易進行轉換的。