來(lái)自;:http://tsoukw.cnblogs.com/archive/2006/07/13/449588.html
正式解釋;:http://www.shnenglu.com/mzty/archive/2005/12/06/1565.html
???????? ;:http://www.shnenglu.com/mzty/archive/2005/12/06/1564.html
很久沒(méi)有寫(xiě)blog了﹐今天下午工作剛好告一段落﹐有點(diǎn)時(shí)間﹐就把上周花了很多時(shí)間總結(jié)出來(lái)的一些計(jì)算機(jī)字符相關(guān)的心得寫(xiě)出來(lái)﹐希望能夠幫助當(dāng)初和我一樣迷茫的人能夠容易理解﹐也希望能夠引出玉來(lái)(這么多廢話(huà)﹐還不快開(kāi)始...)
由于公司使用的是繁體操作系統(tǒng)﹐而我有時(shí)習(xí)慣在自己家里的簡(jiǎn)體計(jì)算機(jī)上寫(xiě)一些程序﹐但是當(dāng)我用U盤(pán)把代碼在兩者之間copy時(shí)﹐經(jīng)常發(fā)現(xiàn)文件中文的
地方成了亂碼﹐所以就花了些時(shí)間到網(wǎng)上查了一下﹐發(fā)現(xiàn)有很多關(guān)于亂碼問(wèn)題的討論﹐按自己的方法總結(jié)了一下(有不對(duì)的地方﹐還希望各位指出):
1.文件分為文本文件和二進(jìn)制文件﹐不過(guò)本質(zhì)都一樣﹐都是些01。
2.計(jì)算機(jī)存儲(chǔ)設(shè)備存儲(chǔ)的0或1﹐稱(chēng)為計(jì)算機(jī)的一個(gè)二進(jìn)制位(bit)。
3.二進(jìn)制文件的0和1有專(zhuān)門(mén)的應(yīng)用程序來(lái)讀﹐所以它們沒(méi)有什么亂不亂碼的問(wèn)題﹐只要該程序認(rèn)得就行。(像doc,xls,exe,dll等)
4.文本文件就不一樣了﹐notepad要認(rèn)識(shí)它﹐vs.net要認(rèn)識(shí)它,UE也要認(rèn)識(shí)它...所以它們就要有一個(gè)標(biāo)準(zhǔn)。這個(gè)標(biāo)準(zhǔn)的原理其實(shí)很簡(jiǎn)單﹐就是把所有的字符都給它一個(gè)序號(hào)﹐然后根據(jù)這個(gè)序號(hào)來(lái)找字符就可以了。這個(gè)東東就是編碼表,也叫字符集(charset)。
5.文本文件存的都是字符﹐如﹕A,?,@,x。很明顯一個(gè)bit不能表示﹐剛好計(jì)算機(jī)的存儲(chǔ)單位--字節(jié)(byte)就是多個(gè)字節(jié)(1個(gè)byte=8個(gè)bit),因此用byte來(lái)表示字符就理所當(dāng)然了。
6.第一個(gè)編碼表--ASCII碼很快產(chǎn)生﹐很簡(jiǎn)單﹐就是用一個(gè)byte來(lái)表示一個(gè)字符(最高位置0),總共能存儲(chǔ)128(2^8)個(gè)字符。如A用
65表示﹐存在計(jì)算機(jī)中就是01000001(65)﹐為了書(shū)寫(xiě)方便﹐我們一般記作0x41(16進(jìn)制),97則表示小寫(xiě)的a,存在計(jì)算機(jī)中就是
01100001(97)﹐記作0x61。?用63表示,記作0x3F。
7.英語(yǔ)國(guó)家的大小寫(xiě)字母加起來(lái)才52個(gè)字符﹐再加上數(shù)字﹐符號(hào)和一些特殊字符﹐已經(jīng)足夠使用。所以ASCII剛開(kāi)始非常流行(誰(shuí)叫計(jì)算機(jī)不是咱中國(guó)發(fā)明的... )
8.隨著計(jì)算機(jī)的普及﹐當(dāng)非英語(yǔ)系的國(guó)家開(kāi)始使用時(shí)﹐ASCII已經(jīng)明顯不能滿(mǎn)足了(總不成天天使用xiao sheng來(lái)表示"小生"吧),所以這些國(guó)家(地區(qū))就開(kāi)始制訂自己的標(biāo)準(zhǔn)。
9.中國(guó)大陸制訂了簡(jiǎn)體漢字的字符集(GB2312)。和英語(yǔ)國(guó)家不同﹐我們的漢字遠(yuǎn)遠(yuǎn)不止128個(gè)﹐所以一個(gè)byte肯定不能表示完﹐那就多加個(gè)
byte,16位(65536)總可以了吧。不過(guò)這樣雖解決了位數(shù)不夠的問(wèn)題﹐但是原來(lái)的英文文件怎么辦?總不成又全部拿出來(lái)改成雙字節(jié)吧。幸好﹐居然發(fā)
現(xiàn)原來(lái)的ASCII的第一位居然是0﹐那我們把第1位改成1不就OK了嗎?以后凡看到0開(kāi)頭的就讀1個(gè)字節(jié)﹐1開(kāi)頭的就讀2個(gè)字節(jié)。(而且128*128
表示所有的簡(jiǎn)體字也足夠了)
10.因此在GB2312標(biāo)準(zhǔn)中,"小"的序號(hào)是0xD0A1,表示成11010000 10100001,而A還是表示成01000001,這就是為什么簡(jiǎn)體操作系統(tǒng)讀ASCII文件不會(huì)亂碼﹐而反之則不然的原因。
11.目前來(lái)說(shuō)﹐情況還比較好﹐中國(guó)大陸的計(jì)算機(jī)運(yùn)行正常。
12.看到中國(guó)大陸制訂了一個(gè)標(biāo)準(zhǔn)﹐其它國(guó)家和地區(qū)也不甘示弱﹐紛紛亮出自己的字符集,于是乎什么BIG5(中國(guó)臺(tái)灣),shift_jis(日本),ks_c_5601-1987(韓國(guó))都閃亮登場(chǎng)﹐一時(shí)間百鳥(niǎo)爭(zhēng)鳴,百花齊放。
13.每個(gè)國(guó)家都想與ASCII保持兼容﹐理所當(dāng)然﹐后面的字符就完全不一樣了﹐因此﹐同樣的0xD0A1,在GB2312中是"小"字﹐而在BIG5中卻是"苤"字。你想想﹐這樣不亂才怪。
14.到了這時(shí)候﹐總有人會(huì)想到﹐再這樣繼續(xù)下去是肯定不行的﹐于是它們就想到了﹐如果有一個(gè)標(biāo)準(zhǔn)﹐能包括所有字符那不就OK了嗎?
15.于是"大哥大"標(biāo)準(zhǔn)就出來(lái)了﹐這就是unicode,為了能夠足夠表示世界上的所有字符這樣光榮而又偉大的任務(wù)﹐這家伙用了四個(gè)字節(jié)來(lái)表示
(2的32次方到底是多少﹐我也懶得算了),這下好了﹐天下太平了﹐再也不會(huì)有麻煩了﹐耳根清靜了...(打住﹐你小子這么這么羅嗦呀)
15.不過(guò)unicode好是好﹐但是畢竟四個(gè)字節(jié)表示一個(gè)字符"浪費(fèi)"太大了(我那破貓上網(wǎng)容易嗎﹐電信黑呀﹐說(shuō)好是2M﹐就給我
200K...)﹐而且大家"驚奇"地發(fā)現(xiàn)﹐居然世界上一些"較強(qiáng)大"的國(guó)家的字符剛好集中在前65536位前﹐呵呵﹐結(jié)果unicode也分成了
unicode-16和unicode-32了﹐自然﹐前者只用兩個(gè)字節(jié)表示(所以只能表示前65536位嘍,歐亞國(guó)家大部分字符都OK了﹐什么﹐你們那
個(gè)@$Y$%字符沒(méi)有﹐呵呵﹐不管我什么事,找標(biāo)準(zhǔn)協(xié)會(huì)﹐都是那幫家伙弄的...)
16.雖然標(biāo)準(zhǔn)出來(lái)了﹐可是好歹ASCII也用了這么久﹐那些英語(yǔ)國(guó)家也在那里嚷嚷﹐這倒好﹐搞個(gè)什么破標(biāo)準(zhǔn)﹐我們又沒(méi)有得到什么好處﹐反而讓我們
原來(lái)的程序都運(yùn)行不了了(為什么呀﹐你想想﹐原來(lái)我們的程序字符都是一個(gè)字節(jié)一個(gè)字節(jié)認(rèn)﹐現(xiàn)在倒好﹐全改成2個(gè)一起認(rèn)﹐這還怎么跑呀?)﹐況且我們憑白無(wú)
故了用了這么多0﹐真別扭(unicode中的前128位還是ASCII標(biāo)準(zhǔn)﹐只不過(guò)在前面加了8個(gè)0)﹐由于那些國(guó)家"勢(shì)力"比較大﹐所以這個(gè)問(wèn)題不容
忽視
17.這個(gè)世界上的牛人總是這么多﹐這個(gè)問(wèn)題很容易就被小意思地解決了。
18.想想GB2312怎么解決與ASCII兼容的問(wèn)題的(1開(kāi)頭的就讀2個(gè)字節(jié)﹐0開(kāi)頭的就讀1個(gè)字節(jié))﹐同樣﹐UTF也這樣﹐0開(kāi)頭的讀1個(gè)字
節(jié)(ASCII碼)﹐110開(kāi)頭的讀2個(gè)字節(jié)﹐1110開(kāi)頭的讀3個(gè)字節(jié)﹐這就是偉大的UTF-8(當(dāng)然還有UTF-16,原理一樣﹐xx開(kāi)頭的讀4個(gè)字
節(jié)﹐xx開(kāi)頭的讀5個(gè)字節(jié)﹐xx開(kāi)頭的讀6個(gè)字節(jié))
19.當(dāng)然UTF-8沒(méi)GB2312這么簡(jiǎn)單﹐讀完之后不能直接查編碼表﹐多加一個(gè)步驟﹐按照模板提取一下字符再查就OK了
以下就是UTF-8的模板
0x0000 - 0x007F用一個(gè)字節(jié)表示 0xxxxxxx
0x0080 - 0x07FF用兩個(gè)字節(jié)表示 110xxxxx 10xxxxxx
0x0800 - 0xFFFF用三個(gè)字節(jié)表示 1110xxxx 10xxxxxx 10xxxxxx
舉個(gè)例子吧,
如
果你遇到了11100110 10110001 10001001 01000001
這樣的字節(jié)流﹐首先你看第一個(gè)字節(jié)以1110開(kāi)頭﹐即讀3個(gè)字節(jié)并按模板提取得到 0110 110001
001001(去除模板標(biāo)志﹐再四字節(jié)四字節(jié)讀即0x6c49),查unicode編碼表就是"漢"字,而最后一個(gè)以0開(kāi)頭就一定是一個(gè)字節(jié)了
﹐0x0041,也就是"A"。
20.好了﹐上面是原理﹐再來(lái)談?wù)労?jiǎn)繁體操作系統(tǒng)轉(zhuǎn)換時(shí)的亂碼問(wèn)題吧
21.按照我的想法﹐windows操作系統(tǒng)應(yīng)該有一個(gè)默認(rèn)的系統(tǒng)字符集﹐如簡(jiǎn)體操作系統(tǒng)應(yīng)該是GB碼﹐繁體操作系統(tǒng)則是BIG5,英文操作系統(tǒng)是ASCII。系統(tǒng)內(nèi)的軟件(notepad)默認(rèn)都是使用這個(gè)字符集。
22.所以我在繁體操作系統(tǒng)默認(rèn)存儲(chǔ)的文本文件就是BIG5了﹐當(dāng)這個(gè)文件到了簡(jiǎn)體系統(tǒng)里﹐它的notepad程序則使用自己的默認(rèn)編碼(GB)來(lái)讀取﹐這樣就亂了。
23.因此如果在保存時(shí)就使用utf-8來(lái)保存﹐應(yīng)該在兩系統(tǒng)切換時(shí)就不會(huì)有問(wèn)題了。
24.而要解決這個(gè)問(wèn)題其實(shí)也很簡(jiǎn)單﹐只要知道這個(gè)文本文件原來(lái)的編碼就可以了﹐使用它讀出來(lái)﹐再轉(zhuǎn)成unicode即可。
上面的東東都是我用自己的理解來(lái)解釋的﹐當(dāng)然有些東西我避開(kāi)了﹐主要是想讓大家更容易理解原理﹐想要更正式的內(nèi)容大家到網(wǎng)上隨便一搜就出來(lái)了。
在證明那些東東之前﹐首先把.net中關(guān)于處理encoding,二進(jìn)制,16進(jìn)制,byte等相關(guān)類(lèi)別和方法羅列一下。
1.byte與string(那些255以?xún)?nèi)的整數(shù))的相互轉(zhuǎn)換(各種進(jìn)制之間的相互轉(zhuǎn)換)
使用System.Convert類(lèi)別
string to byte
Convert.ToByte(string,base)
base:2表示二進(jìn)制,8表示八進(jìn)制,10表示十進(jìn)制,16表示十六進(jìn)制(你要輸入33,呵呵﹐異常)
這樣可以把字符串的(0--255)轉(zhuǎn)成一個(gè)byte
Convert.ToByte("01000001",2)轉(zhuǎn)成 65
Convert.ToByte("255",10)轉(zhuǎn)成255
Convert.ToByte("42",16)轉(zhuǎn)成66
同理﹐byte to string也是Convert類(lèi)
Convert.ToString(byte,base)
同樣可以轉(zhuǎn)成相應(yīng)的進(jìn)制表示的字符串
通過(guò)這兩個(gè)方法﹐我們要進(jìn)行2,8,10,16進(jìn)制的相互轉(zhuǎn)換就容易了
2.char,int,long,boolean等與byte[]之間的相互轉(zhuǎn)換(這些數(shù)據(jù)在內(nèi)存中的存儲(chǔ)狀況)
使用System.BitConverter類(lèi)別
我們都知道char,int,long等基本類(lèi)型是以字節(jié)形式存在內(nèi)存中的﹐所以要查看其內(nèi)存存儲(chǔ)方式則直接使用BitConverter.GetBytes()就可以了
然后再使用BitConverter.ToString(byte[])就可以以string方式查看了(如:f9-03表示2個(gè)字節(jié))
string是由char組成的﹐只要foreach(char in string)就可以看到string的存儲(chǔ)方式了(實(shí)驗(yàn)表明﹐string在內(nèi)存中是以u(píng)nicode編碼存在的,下有示例)
3.各種Encoding之間的轉(zhuǎn)換
使用System.Text中的Encoding相關(guān)的類(lèi)別就可以了
包括Encoding,ASCIIEncoding,UTF8Encoding等,當(dāng)然也可以通過(guò)Encoding.GetEncoding()來(lái)獲取不同的編碼。
然后再通過(guò)GetBytes(string)方法﹐就可以獲取string的不同編碼的byte數(shù)組了
通過(guò)GetString(byte[])方法﹐就可以把某種編碼的byte數(shù)組轉(zhuǎn)成字符串.
如"I am 小生,hello world!"的各種bytes編碼測(cè)試


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

public?class?MyClass


{
?public?static?void?Main()

?
{
??string?tmp?=?"I?am?小生,hello?world!";
??WL("內(nèi)存中存儲(chǔ)的字節(jié)數(shù)組﹕");
??
??foreach(char?c?in?tmp)

??
{
???byte[]?b?=?BitConverter.GetBytes(c);
???Console.Write(BitConverter.ToString(b)?+?"-");
??}
??WL("");
??WL("unicode字節(jié)數(shù)組﹕");
??byte[]?bs1?=?Encoding.Unicode.GetBytes(tmp);
??WL(BitConverter.ToString(bs1));
??WL("utf8字節(jié)數(shù)組﹕");
??
??byte[]?bs2?=?Encoding.UTF8.GetBytes(tmp);
??WL(BitConverter.ToString(bs2));
??WL("default字節(jié)數(shù)組﹕");
??byte[]?bs3?=?Encoding.Default.GetBytes(tmp);
??WL(BitConverter.ToString(bs3));
??WL("big5字節(jié)數(shù)組﹕");
??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();
?}
}


?
在下面開(kāi)始之前﹐先摘錄一段關(guān)于BOM的知識(shí)
-----------------------------------------------------------------
UTF的字節(jié)序和BOM
UTF-8以字節(jié)為編碼單元,沒(méi)有字節(jié)序的問(wèn)題。UTF-16以?xún)蓚€(gè)字節(jié)為編碼單元,在解釋一個(gè)UTF-16文本前,首先要弄清楚每個(gè)編碼單元的字
節(jié)序。例如收到一個(gè)“奎”的Unicode編碼是594E,“乙”的Unicode編碼是4E59。如果我們收到UTF-16字節(jié)流“594E”,那么這
是“奎”還是“乙”?
Unicode規(guī)范中推薦的標(biāo)記字節(jié)順序的方法是BOM。BOM不是“Bill Of Material”的BOM表,而是Byte Order
Mark。BOM是一個(gè)有點(diǎn)小聰明的想法:在UCS編碼中有一個(gè)叫做"ZERO WIDTH NO-BREAK
SPACE"的字符,它的編碼是FEFF。而FFFE在UCS中是不存在的字符,所以不應(yīng)該出現(xiàn)在實(shí)際傳輸中。UCS規(guī)范建議我們?cè)趥鬏斪止?jié)流前,先傳輸
字符"ZERO WIDTH NO-BREAK SPACE"。
這樣如果接收者收到FEFF,就表明這個(gè)字節(jié)流是Big-Endian的;如果收到FFFE,就表明這個(gè)字節(jié)流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被稱(chēng)作BOM。
UTF-8不需要BOM來(lái)表明字節(jié)順序,但可以用BOM來(lái)表明編碼方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8編碼是EF BB BF。所以如果接收者收到以EF BB BF開(kāi)頭的字節(jié)流,就知道這是UTF-8編碼了。
Windows就是使用BOM來(lái)標(biāo)記文本文件的編碼方式的。
----------------------------------------------------------
好了﹐這些問(wèn)題解決后﹐我們就來(lái)做單純的文本文件的編碼識(shí)別﹐讀取與寫(xiě)入測(cè)試吧。
以windows的notepad為例(其它的文本文件讀取軟件的原理應(yīng)該也差不多﹐只是會(huì)多一些特殊的判斷算法而已)。
notepad默認(rèn)有四種編碼來(lái)存儲(chǔ)和讀取文本文件。分別是﹕
ANSI,Unicode,Unicode-big-endian和UTF-8。
首先來(lái)講ANSI吧﹐這個(gè)是windows操作系統(tǒng)在區(qū)域與語(yǔ)言塊設(shè)置的編碼(也就是系統(tǒng)默認(rèn)的編碼)﹐因此像繁體操作系統(tǒng)就是big5,而簡(jiǎn)體操作系統(tǒng)則是GBK。
而Unicode和UTF-8這兩種格式相信大家已經(jīng)有所了解(當(dāng)然前者是unicode-16)
而Unicode-big-endian是什么意思呢﹐它與Unicode幾乎一樣﹐只是它把高位放在前面(而后者則剛好相反)
上面的摘錄已經(jīng)有所說(shuō)明﹐這里再解釋一下﹕
如同樣是字符"A"﹐在以下幾種格式中的存儲(chǔ)形式分別是﹕
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
好了﹐大家想一想﹐文本文件在硬盤(pán)中是以字節(jié)形式存儲(chǔ)的﹐如果不知道文本文件的編碼﹐那是無(wú)論如何也不能正確讀出文本文件顯示給用戶(hù)看的(亂碼了只有人才知道﹐程序則認(rèn)為一切正常)
根據(jù)BOM的規(guī)則﹐因此在一段字節(jié)流開(kāi)始時(shí)﹐如果接收到以下字節(jié)﹐則分別表明了該文本文件的編碼。
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
而如果不是以這個(gè)開(kāi)頭﹐那程序則會(huì)以ANSI,也就是系統(tǒng)默認(rèn)編碼讀取。
所以現(xiàn)在我們來(lái)做個(gè)測(cè)試就可以很清楚地對(duì)以上的東東進(jìn)行驗(yàn)證了。
1.用notepad輸入"漢A"這2個(gè)字符﹐然后分別保存成ANSI,Unicode,Unicode-big-endian和UTF-8,名字分別取為ansi.txt,unicode.txt,unicode_b.txt,utf8.txt,并且放在c盤(pán)根目錄下
2.用以下程序進(jìn)行驗(yàn)證


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文件格式的字節(jié)流﹕");
??path?=?"c:\\ansi.txt";
??writefile(path);
??
??WL("Unicode文件格式的字節(jié)流﹕");
??path?=?"c:\\unicode.txt";
??writefile(path);
??
??WL("Unicode-big-endian文件格式的字節(jié)流﹕");
??path?=?"c:\\unicode_b.txt";
??writefile(path);
??
??WL("utf-8文件格式的字節(jié)流﹕");
??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文件格式的字節(jié)流﹕
BA-BA-41
10111010 10111010 01000001
Unicode文件格式的字節(jié)流﹕
FF-FE-49-6C-41-00
11111111 11111110 01001001 01101100 01000001 00000000
Unicode-big-endian文件格式的字節(jié)流﹕
FE-FF-6C-49-00-41
11111110 11111111 01101100 01001001 00000000 01000001
utf-8文件格式的字節(jié)流﹕
EF-BB-BF-E6-B1-89-41
11101111 10111011 10111111 11100110 10110001 10001001 01000001
從以上結(jié)果可以很容易的看到BABA正是"漢"字的gb2312編碼﹐當(dāng)然我的操作系統(tǒng)是繁體的﹐如果我直接雙擊打開(kāi)﹐則可以看到"犖A"﹐這是亂碼﹐因?yàn)槲业南到y(tǒng)baba查的是big5﹐而baba的big5碼正是"犖"
然而還有其它很多程序﹐像IE呀,它可以使用meta標(biāo)簽來(lái)識(shí)別文件的編碼,xml也是可以通過(guò)encoding屬性來(lái)說(shuō)明文件的編碼的﹐所以這些程序的識(shí)別方法和普通的又有些不同罷了。
同樣﹐寫(xiě)一個(gè)文本文件時(shí)﹐先寫(xiě)入這些標(biāo)記符﹐則也會(huì)幫助notepad識(shí)別這些文件的編碼(當(dāng)然.net專(zhuān)門(mén)提供了一些類(lèi)別﹐如StreamWriter﹐可以直接存成某種編碼的格式)。
至于各種encoding之間的轉(zhuǎn)換﹐我想也不必多說(shuō)了﹐通過(guò)Encoding類(lèi)的Convert,GetBytes和GetString方法是很容易進(jìn)行轉(zhuǎn)換的。