Java中的字符集編碼入門技巧
ASCII及相關(guān)標(biāo)準(zhǔn)
地球人都知道ASCII就是美國標(biāo)準(zhǔn)信息交換碼的縮寫，也知道ASCII規(guī)定用7位二進(jìn)制數(shù)字來表示英文字符，ASCII被定為國際標(biāo)準(zhǔn)之后的代號(hào)為ISO-646.由于ASCII碼只使用了7個(gè)二進(jìn)制位，也就是說一個(gè)字節(jié)可以表示的256個(gè)數(shù)字中，它僅使用了0~127這128個(gè)碼位，剩下的128個(gè)碼位便可以用來做擴(kuò)展，用來表示一些特定語言所獨(dú)有的字符，因此對(duì)這多余的128個(gè)碼位的不同擴(kuò)展，就形成了一系列ISO-8859-*的標(biāo)準(zhǔn)。例如為英語作了專門擴(kuò)展的字符集編碼標(biāo)準(zhǔn)編號(hào)為ISO-8859-1，也叫做Latin-1，為希臘語所作的擴(kuò)展編號(hào)為ISO-8859-7等，完整的列表可以參考《Java Internationalization》一書。
整個(gè)Unicode項(xiàng)目是由多家計(jì)算機(jī)軟件公司，還包括一些出版行業(yè)的公司共同發(fā)起的，從上世紀(jì)八十年代就已經(jīng)開始。地球人都知道，對(duì)于日文，漢字來說，256個(gè)碼位是遠(yuǎn)遠(yuǎn)不夠用的（當(dāng)然，在當(dāng)時(shí)并不是地球人都知道，起碼設(shè)計(jì)計(jì)算機(jī)的老美們就不知道，甚至直到今天，還有老美以為米國是世界上唯一的國家）。解決方法很直觀也很明顯，那就是采用碼位多到足夠包含所需字符數(shù)量的編碼方案（即俗話說的頭痛醫(yī)頭，腳痛醫(yī)腳嘛）。這也是Unicode的目標(biāo)之一，能夠包含世界上所有語言的字符（包括漢字，日文，數(shù)學(xué)符號(hào)，音樂符號(hào)，還包括各種奇奇怪怪看也看不懂的東西比如象形文字，甲骨文 ，三個(gè)代表，科學(xué)發(fā)展觀等等，笑），這個(gè)理想，可以說很遠(yuǎn)大，但很快被發(fā)現(xiàn)僅靠Unicode原先的設(shè)計(jì)無法實(shí)現(xiàn)。Unicode的另一個(gè)設(shè)計(jì)目標(biāo)，對(duì)今天影響深遠(yuǎn)，那就是對(duì)所有字符都采用16位編碼（即用一個(gè)大小不超過2的16次方的整數(shù)數(shù)字給每個(gè)字符編號(hào)，注意從這個(gè)意義上也可以看出，Unicode是一種編碼字符集，而非字符集編碼）。說這個(gè)設(shè)計(jì)目標(biāo)對(duì)現(xiàn)今影響深遠(yuǎn)，完全不是表揚(yáng)，因?yàn)榈胶髞磉BUnicode的設(shè)計(jì)者也發(fā)現(xiàn)，16位編碼僅有65536個(gè)碼位，遠(yuǎn)遠(yuǎn)不能容納世界上所有的字符，但當(dāng)意識(shí)到這個(gè)問題的時(shí)候，Unicode大部分的規(guī)范已經(jīng)制定完畢，也有相當(dāng)程度的普及，完全推倒重來是不現(xiàn)實(shí)的。這成了一個(gè)遺留問題，也是surrogate pair這種蹩腳解決方案的發(fā)端。
無獨(dú)有偶，在1984年，喜歡以繁多的編號(hào)糊弄群眾的國際標(biāo)準(zhǔn)化組織ISO也開始著手制定解決不同語言字符數(shù)量太大問題的解決方案，這一方案被稱為Universal Character Set（UCS 統(tǒng)一字符集），正式的編號(hào)是ISO-10646（記得么，ASCII是ISO-646，不知這種安排是否是故意的）。還是ISO高瞻遠(yuǎn)矚，一開始就確定了UCS是一個(gè)31位的編碼字符集（即用一個(gè)大小不超過2的31次方的整數(shù)數(shù)字為每個(gè)字符編號(hào)），這回真的足以容納古往今來所有國家，所有語言所包含的字符了。雖然后來他們意識(shí)到，2的31次方個(gè)碼位又實(shí)在太多了……
天下大勢，分久必合。無論Unicode還是UCS，最初的目的都是杜絕各種各樣名目繁多形式各異互不兼容老死不相往來的私用擴(kuò)展編碼（好啰嗦的一句話），結(jié)果兩方確立標(biāo)準(zhǔn)的同時(shí)（最初時(shí)這兩個(gè)標(biāo)準(zhǔn)是不兼容的），又形成了割據(jù)，這對(duì)建設(shè)和諧社會(huì)是不利的，違反當(dāng)今世界和平與發(fā)展的主旋律，中國政府一向反對(duì)任何形式的霸權(quán)主義和強(qiáng)權(quán)政治，對(duì)以米國為首的發(fā)達(dá)國家……扯遠(yuǎn)了扯遠(yuǎn)了。1991年，Unicode聯(lián)盟與ISO的工作組終于開始討論Unicode與UCS的合并問題，雖然其后的合并進(jìn)行了很多年，Unicode初版規(guī)范中的很多編碼都需要被改寫，UCS也需要對(duì)碼空間的使用進(jìn)行必要限制，但成果是喜人的。最終，兩者統(tǒng)一了抽象字符集（即任何一個(gè)在Unicode中存在的字符，在UCS中也存在），且最靠前的65535個(gè)字符也統(tǒng)一了字符的編碼。對(duì)于碼空間，兩者同意以一百一十萬為限（即兩者都認(rèn)為雖然65536不夠，但2的31次方又太大，一百一十萬是個(gè)雙方都可接受的碼空間大小，也夠用，當(dāng)然，這里說的一百一十萬只是個(gè)約數(shù)），Unicode將碼空間擴(kuò)展到了一百一十萬，而UCS將永久性的不使用一百一十萬以后的碼位。也就是說，現(xiàn)在再講Unicode只包含65536個(gè)字符是不對(duì)的。除了對(duì)已經(jīng)定義的字符進(jìn)行統(tǒng)一外，Unicode聯(lián)盟與ISO工作組也同意今后任何的擴(kuò)展工作兩者均保持同步，因此雖然從歷史的意義上講Unicode與UCS不是一回事（甚至細(xì)節(jié)上說也不是一回事），但現(xiàn)在提起Unicode，指代兩者均無不妥。何的擴(kuò)展工作兩者均保持同步，因此雖然從歷史的意義上講Unicode與UCS不是一回事（甚至細(xì)節(jié)上說也不是一回事），但現(xiàn)在提起Unicode，指代兩者均無不妥。
#p#
需要再一次強(qiáng)調(diào)的是，無論歷史上的UCS還是現(xiàn)如今的Unicode，兩者指的都是編碼字符集，而不是字符集編碼。花費(fèi)一點(diǎn)時(shí)間來理解好這件事，然后你會(huì)發(fā)現(xiàn)對(duì)所有網(wǎng)頁的，系統(tǒng)的，編碼標(biāo)準(zhǔn)之間的來回轉(zhuǎn)換等等繁雜事務(wù)都會(huì)思路清晰，手到擒來。
首先說說最一般意義上的字符集。
一個(gè)抽象字符集其實(shí)就是指字符的集合，例如所有的英文字母是一個(gè)抽象字符集，所有的漢字是一個(gè)抽象字符集，當(dāng)然，把全世界所有語言的符號(hào)都放在一起，也可以稱為一個(gè)抽象字符集，所以這個(gè)劃分是相當(dāng)人為的。之所以說“抽象”二字，是因?yàn)檫@里所提及的字符不是任何具體形式的字符，拿漢字中的“漢”這個(gè)字符來說，您在這篇文章中看到的這個(gè)“漢”其實(shí)是這個(gè)字符的一種具體表現(xiàn)形式，是它的圖像表現(xiàn)形式，而且它是用中文（而非拼音）書寫而成，使用宋體外觀；而當(dāng)人們用嘴發(fā)出“漢”這個(gè)音的時(shí)候，他們是在使用“漢”的另一種具體表現(xiàn)形式——聲音，但無論如何，兩者所指的字符都是“漢”這個(gè)字。同一個(gè)字符的表現(xiàn)形式可能有無數(shù)種（點(diǎn)陣表示，矢量表示，音頻表示，楷體，草書等等等等），把每一種表現(xiàn)形式下的同一個(gè)字符都納入到字符集中，會(huì)使得集合過于龐大，冗余高，也不好管理。因此抽象字符集中的字符，都是指唯一存在的抽象字符，而忽略它的具體表現(xiàn)形式。
抽象字符集中的諸多字符，沒有順序之分，誰也不能說哪個(gè)字符在哪個(gè)字符前面，而且這種抽象字符只有人能理解。在給一個(gè)抽象字符集合中的每個(gè)字符都分配一個(gè)整數(shù)編號(hào)之后（注意這個(gè)整數(shù)并沒有要求大小），這個(gè)字符集就有了順序，就成為了編碼字符集。同時(shí)，通過這個(gè)編號(hào)，可以唯一確定到底指的是哪一個(gè)字符。當(dāng)然，對(duì)于同一個(gè)字符，不同的字符集編碼系統(tǒng)所制定的整數(shù)編號(hào)也不盡相同，例如“兒”這個(gè)字，在Unicode中，它的編號(hào)是0x513F，（為方便起見，以十六進(jìn)制表示，但這個(gè)整數(shù)編號(hào)并不要求必須是以十六進(jìn)制表示）意思是說它是Unicode這個(gè)編碼字符集中的第0x513F個(gè)字符。而在另一種編碼字符集比如Big5中，這個(gè)字就是第0xA449個(gè)字符了。這種情況的另一面是，許多字符在不同的編碼字符集中被分配了相同的整數(shù)編號(hào)，例如英文字母“A”，在ASCII及Unicode中，均是第0x41個(gè)字符。我們常說的Unicode字符集，指的就是這種被分配了整數(shù)編號(hào)的字符集合，但要澄清的是，編碼字符集中字符被分配的整數(shù)編號(hào)，不一定就是該字符在計(jì)算機(jī)中存儲(chǔ)時(shí)所使用的值，計(jì)算機(jī)中存儲(chǔ)的字符到底使用什么二進(jìn)制整數(shù)值來表示，是由下面將要說到的字符集編碼決定的。
字符集編碼決定了如何將一個(gè)字符的整數(shù)編號(hào)對(duì)應(yīng)到一個(gè)二進(jìn)制的整數(shù)值，有的編碼方案簡單的將該整數(shù)值直接作為其在計(jì)算機(jī)中的表示而存儲(chǔ)，例如英文字符就是這樣，幾乎所有的字符集編碼方案中，英文字母的整數(shù)編號(hào)與其在計(jì)算機(jī)內(nèi)部存儲(chǔ)的二進(jìn)制形式都一致。但有的編碼方案，例如適用于Unicode字符集的UTF-8編碼形式，就將很大一部分字符的整數(shù)編號(hào)作了變換后存儲(chǔ)在計(jì)算機(jī)中。以“漢”字為例，“漢”的Unicode值為0x6C49，但其編碼為UTF-8格式后的值為0xE6B189（注意到變成了三個(gè)字節(jié)）。我們經(jīng)常聽說的另一種編碼方案UTF-16，則對(duì)Unicode中的前65536個(gè)字符編號(hào)都不做變換，直接作為計(jì)算機(jī)存儲(chǔ)時(shí)使用的值（對(duì)65536以后的字符，仍然要做變換），例如“漢”字的Unicode編號(hào)為0x6C49，那么經(jīng)過UTF-16編碼后存儲(chǔ)在計(jì)算機(jī)上時(shí)，它的表示仍為0x6C49！。我猜，正是因?yàn)閁TF-16的存在，使得很多人認(rèn)為Unicode是一種編碼（實(shí)際上，是一個(gè)字符集，再次重申），也因此，很多人說Unicode的時(shí)候，他們實(shí)際上指的是UTF-16.UTF-16提供了surrogate pair機(jī)制，使得Unicode中碼位大于65536的那些字符得以表示。
Surrogate pair機(jī)制在目前來說實(shí)在不常用，甚至連一些UTF-16的實(shí)現(xiàn)都不支持，所以我不打算在這里多加討論，其基本的思想就是用兩個(gè)16位的編碼表示一個(gè)字符（注意，只對(duì)碼位超過65536的字符這么做）。Unicode如此死抱著16這個(gè)數(shù)字不放，有歷史的原因，也有實(shí)用的原因。
當(dāng)然還有一種最強(qiáng)的編碼，UTF-32，他對(duì)所有的Unicode字符均不做變換，直接使用編號(hào)存儲(chǔ)！（俗稱的以不變應(yīng)萬變），只是這種編碼方案太浪費(fèi)存儲(chǔ)空間（就連1個(gè)字節(jié)就可以搞定的英文字符，它都必須使用4個(gè)字節(jié)），因而盡管使用起來方便（不需要任何轉(zhuǎn)換），卻沒有得到普及。
記得當(dāng)初Unicode與UCS還沒成家之時(shí)，UCS也是需要人愛，需要人疼的，沒有自己的字符集編碼怎么成。UCS-2與UCS-4就扮演了這樣的角色。UCS-4與UTF-32除了名字不同以外，思想完全一樣。而UCS-2與UTF-16在對(duì)前65536個(gè)字符的處理上也完全相同，唯一的區(qū)別只在于UCS-2 不支持surrogate pair機(jī)制，即是說，UCS-2只能對(duì)前65536個(gè)字符編碼，對(duì)其后的字符毫無辦法。不過現(xiàn)在再談起字符編碼的時(shí)候，UCS-2與UCS-4早已成為計(jì)算機(jī)史學(xué)家才會(huì)用到的詞匯，就讓它們繼續(xù)留在故紙堆里吧。 下一節(jié)我們來說說與中文相關(guān)的GB2312和GBK。
#p#
GB2312是對(duì)中國的開發(fā)人員來說很重要的一個(gè)詞匯，它的來龍去脈并不需要我在這里贅述，隨便Goolge之便明白無誤。我只是想提一句，記得前一節(jié)說到編碼字符集和字符集編碼不是一回事，而有的字符集編碼又實(shí)際上沒有做任何事，GB2312正是這樣一種東西！
GB2312最初指的是一個(gè)編碼字符集，其中包含了ASCII所包含的英文字符，同時(shí)加入了6763個(gè)簡體漢字以及其他一些ASCII之外的符號(hào)。與Unicode有UTF-8和UTF-16一樣（當(dāng)然， UTF-8和UTF-16也沒有被限定只能用來對(duì)Unicode進(jìn)行編碼，實(shí)際上，你用它對(duì)視頻進(jìn)行編碼都是可以的，只是編出的文件沒有播放器支持罷了，哈哈），GB2312也有自己的編碼方案，但這個(gè)方案直接使用一個(gè)字符在GB2312中的編號(hào)作為存儲(chǔ)值（與UTF-32的做法類似），也因此，這個(gè)編碼方案甚至沒有正式的名稱。我們?nèi)粘Ｕf起GB2312的時(shí)候，常常即指這個(gè)字符集，也指這種編碼方案。
GBK是GB2312的后續(xù)標(biāo)準(zhǔn)，添加了更多的漢字和特殊符號(hào)，類似的是，GBK也是同時(shí)指他的字符集和他的編碼。
GBK還是現(xiàn)如今中文Windows操作系統(tǒng)的系統(tǒng)默認(rèn)編碼（這正是幾乎所有網(wǎng)頁上的，文件里的亂碼問題的根源）。
我們可以這樣來驗(yàn)證，使用以下的Java代碼：
String encoding=System.getProperty("file.encoding");
System.out.println(encoding);輸出結(jié)果為GBK
（什么？你的輸出不是這樣？怎么可能？完了，我的牌子要砸了，等等，你用的繁體版XP？我說你這同志在這里搗什么亂？去！去！）
說到GB2312和GBK就不得不提中文網(wǎng)頁的編碼。盡管很多新開發(fā)的Web系統(tǒng)和新上線的注重國際化的網(wǎng)站都開始使用UTF-8，仍有相當(dāng)一部分的中文媒體堅(jiān)持使用GB2312和GBK，例如新浪的頁面。其中有兩點(diǎn)很值得注意。
第一，頁面中meta標(biāo)簽的部分，常常可以見到charset=GB2312這樣的寫法，很不幸的是，這個(gè)“charset”其實(shí)是用來指定頁面使用的是什么字符集編碼，而不是使用什么字符集。例如你見到過有人寫“charset=UTF-8”，見到過有人寫“charset=ISO-8859-1”，但你見過有人寫“charset=Unicode”么？當(dāng)然沒有，因?yàn)閁nicode是一個(gè)字符集，而不是編碼。
然而正是charset這個(gè)名稱誤導(dǎo)了很多程序員，真的以為這里要指定的是字符集，也因而使他們進(jìn)一步的誤以為UTF-8和UTF-16是一種字符集！（萬惡啊）好在XML中已經(jīng)做出了修改，這個(gè)位置改成了正確的名稱：encoding.第二，頁面中說的GB2312，實(shí)際上并不真的是GB2312（驚訝么？）。我們來做個(gè)實(shí)驗(yàn)，例如找一個(gè)GB2312中不存在的漢字“亸”（這個(gè)字確實(shí)不在GB2312中，你可以到GB2312的碼表中去找，保證找不到），這個(gè)字在GBK中。然后你把它放到一個(gè)html頁面中，試著在瀏覽器中打開它，然后選擇瀏覽器的編碼為“GB2312”，看到了什么？它完全正常顯示！
結(jié)論不用我說你也明白了，瀏覽器實(shí)際上使用的是GBK來顯示。
新浪的頁面中也有很多這樣的例子，到處都寫charset=GB2312，卻使用了無數(shù)個(gè)GB2312中并不存在的字符。這種做法對(duì)瀏覽器顯示頁面并不成問題，但在需要程序抓取頁面并保存的時(shí)候帶來了麻煩，程序?qū)⒉荒芤罁?jù)頁面所“聲稱”的編碼進(jìn)行讀取和保存，而只能盡量猜測正確的編碼。
#p#
接著上節(jié)的思路說，一個(gè)網(wǎng)頁要想在瀏覽器中能夠正確顯示，需要在三個(gè)地方保持編碼的一致：網(wǎng)頁文件，網(wǎng)頁編碼聲明和瀏覽器編碼設(shè)置。
首先是網(wǎng)頁文件本身的編碼，即網(wǎng)頁文件在被創(chuàng)建的時(shí)候使用什么編碼來保存。這個(gè)完全取決于創(chuàng)建該網(wǎng)頁的人員使用了什么編碼保存，而進(jìn)一步的取決于該人員使用的操作系統(tǒng)。例如我們使用的中文版WindowsXP系統(tǒng)，當(dāng)你新建一個(gè)文本文件，寫入一些內(nèi)容，并按下ctrl+s進(jìn)行保存的那一刻，操作系統(tǒng)就替你使用GBK編碼將文件進(jìn)行了保存（沒有使用UTF-8，也沒有使用UTF-16）。而使用了英文系統(tǒng)的人，系統(tǒng)會(huì)使用ISO-8859-1進(jìn)行保存，這也意味著，在英文系統(tǒng)的文件中如果輸入一個(gè)漢字，是無法進(jìn)行保存的（當(dāng)然，你甚至都無法輸入）。
一個(gè)在創(chuàng)建XML文件時(shí)（創(chuàng)建HTML的時(shí)候倒很少有人這么認(rèn)為）常見的誤解是以為只要在頁面的encoding部分聲明了UTF-8，則文件就會(huì)被保存為UTF-8格式。這實(shí)在是……怎么說呢，不能埋怨大家。實(shí)際上XML文件中encoding部分與HTML文件中的charset中一樣，只是告訴“別人”（這個(gè)別人可能是瀏覽你的頁面的人，可能是瀏覽器，也可能是處理你頁面的程序，別人需要知道這個(gè)，因?yàn)槌悄愀嬖V他們，否則誰也猜不出你用了什么編碼，僅通過文件的內(nèi)容判斷不出使用了什么編碼，這是真的）這個(gè)文件使用了什么編碼，唯獨(dú)操作系統(tǒng)不會(huì)搭理，它仍然會(huì)按自己默認(rèn)的編碼方式保存文件（再一次的，在我們的中文WindowsXP系統(tǒng)中，使用GBK保存）。至于這個(gè)文件是不是真的是encoding或者charset所聲明的那種編碼保存的呢？答案是不一定！
例如新浪的頁面就“聲稱”他是用GB2312編碼保存的，但實(shí)際上卻是GBK，也有無數(shù)的二把刀程序員用系統(tǒng)默認(rèn)的GBK保存了他們的XML文件，卻在他們的encoding中信誓旦旦的說是UTF-8的。
這就是我們所說的第二個(gè)位置，網(wǎng)頁編碼聲明中的編碼應(yīng)該與網(wǎng)頁文件保存時(shí)使用的編碼一致。
而瀏覽器的編碼設(shè)置實(shí)際上并不嚴(yán)格，就像我們第三節(jié)所說的那樣，在瀏覽器中選擇使用GB2312來查看，它實(shí)際上仍然會(huì)使用GBK進(jìn)行。而且瀏覽器還有這樣一種好習(xí)慣，即它會(huì)盡量猜測使用什么編碼查看最合適。
我要重申的是，網(wǎng)頁文件的編碼和網(wǎng)頁文件中聲明的編碼保持一致，這是一個(gè)極好的建議（值得遵循，會(huì)與人方便，與己方便），但如果不一致，只要網(wǎng)頁文件的編碼與瀏覽器的編碼設(shè)置一致，也是可以正確顯示的。
例如有這樣一個(gè)頁面，它使用GBK保存，但聲明自己是UTF-8的。這個(gè)時(shí)候用瀏覽器打開它，首先會(huì)看到亂碼，因?yàn)檫@個(gè)頁面“告訴”瀏覽器用UTF-8顯示，瀏覽器會(huì)很尊重這個(gè)提示，于是亂碼一片。但當(dāng)手工把瀏覽器設(shè)為GBK之后，顯示正常。
說了以上四節(jié)這么多，后面我們就來侃侃Java里的字符編碼，你會(huì)發(fā)現(xiàn)有意思且撓頭的事情很多，但一旦弄通，天下無敵（不過不要像東方不敗那樣才好）。
#p#
如果你是JVM的設(shè)計(jì)者，讓你來決定JVM中所有字符的表示形式，你會(huì)不會(huì)允許使用各種編碼方式的字符并存？
我想你的答案是不會(huì)，如果在內(nèi)存中的Java字符可以以GB2312，UTF-16，BIG5等各種編碼形式存在，那么對(duì)開發(fā)者來說，連進(jìn)行最基本的字符串打印、連接等操作都會(huì)寸步難行。例如一個(gè)GB2312的字符串后面連接一個(gè)UTF-8的字符串，那么連接后的最終結(jié)果應(yīng)該是什么編碼的呢？你選哪一個(gè)都沒有道理。
因此牢記下面這句話，這也是Java開發(fā)者的共同意志：在Java中，字符只以一種形式存在，那就是Unicode（注意到我們沒有選擇特定的編碼，直接使用它們?cè)谧址械木幪?hào)，這是統(tǒng)一的唯一方法）。
但“在Java中”到底是指在哪里呢？就是指在JVM中，在內(nèi)存中，在你的代碼里聲明的每一個(gè)char，String類型的變量中。例如你在程序中這樣寫
char han='漢';在內(nèi)存的相應(yīng)區(qū)域，這個(gè)字符就表示為0x6C49.可以用下面的代碼證明一下：
char han='漢';
System.out.format("%x",(short)han);輸出是：6c49反過來用Unicode編號(hào)來指定一個(gè)字符也可以，像這樣：
char han=0x6c49;
System.out.println(han);輸出是：漢
這其實(shí)也是說，只要你正確的讀入了“漢”這個(gè)字，那么它在內(nèi)存中的表示形式一定是0x6C49，沒有任何其他的值能代表這個(gè)字（當(dāng)然，如果你讀錯(cuò)了，那結(jié)果是什么就不知道了，范偉說：讀，讀錯(cuò)了呀，那還等于好幾億呢；本山大哥說：好幾億你也沒答上，請(qǐng)聽下一題）。
JVM的這種約定使得一個(gè)字符存在的世界分為了兩部分：JVM內(nèi)部和OS的文件系統(tǒng)。在JVM內(nèi)部，統(tǒng)一使用Unicode表示，當(dāng)這個(gè)字符被從JVM內(nèi)部移到外部（即保存為文件系統(tǒng)中的一個(gè)文件的內(nèi)容時(shí)），就進(jìn)行了編碼轉(zhuǎn)換，使用了具體的編碼方案（也有一種很特殊的情況，使得在JVM內(nèi)部也需要轉(zhuǎn)換，不過這個(gè)是后話）。
因此可以說，所有的編碼轉(zhuǎn)換就只發(fā)生在邊界的地方，JVM和OS的交界處，也就是你的各種輸入輸出流（或者Reader，Writer類）起作用的地方。
話頭扯到這里就必須接著說Java的IO系統(tǒng)。
盡管看上去混亂繁雜，但是所有的IO基本上可以分為兩大陣營：面向字符的Reader啊Wrtier啊，以及面向字節(jié)的輸入輸出流。
下面我來逐一分解，其實(shí)一點(diǎn)也不難。
面向字符和面向字節(jié)中的所謂“面向”什么，是指這些類在處理輸入輸出的時(shí)候，在哪個(gè)意義上保持一致。如果是面向字節(jié)，那么這類工作要保證系統(tǒng)中的文件二進(jìn)制內(nèi)容和讀入JVM內(nèi)部的二進(jìn)制內(nèi)容要一致。不能變換任何0和1的順序（也就是文件是怎么存的就怎么取，與文件保存的編碼一致）。因此這是一種非常“忠實(shí)于原著”的做法（偶然間讓我想起郭敬明抄襲莊羽的文章，那家伙，太忠實(shí)于原著了，笑）。
這種輸入輸出方式很適合讀入視頻文件或者音頻文件，或者任何不需要做變換的文件內(nèi)容。
而面向字符的IO是指希望系統(tǒng)中的文件的字符和讀入內(nèi)存的“字符”（注意和字節(jié)的區(qū)別）要一致。例如我們的中文版WindowsXP系統(tǒng)上有一個(gè)GBK的文本文件，其中有一個(gè)“漢”字，這個(gè)字的GBK編碼是0xBABA（而Unicode編號(hào)是0x6C49），當(dāng)我們使用面向字符的IO把它讀入內(nèi)存并保存在一個(gè)char型變量中時(shí)，我希望IO系統(tǒng)不要傻傻的直接把0xBABA放到這個(gè)char型變量中，我甚至都不關(guān)心這個(gè)char型變量具體的二進(jìn)制內(nèi)容到底是多少，我只希望這個(gè)字符讀進(jìn)來之后仍然是“漢”這個(gè)字。
從這個(gè)意義上也可以看出，面向字符的IO類，也就是Reader和Writer類，實(shí)際上隱式的為我們做了編碼轉(zhuǎn)換，在輸出時(shí)，將內(nèi)存中的Unicode字符使用系統(tǒng)默認(rèn)的編碼方式進(jìn)行了編碼，而在輸入時(shí)，將文件系統(tǒng)中已經(jīng)編碼過的字符使用默認(rèn)編碼方案進(jìn)行了還原。我兩次提到“默認(rèn)”，是說Reader和Writer的聰明也僅此而已了，它們只會(huì)使用這個(gè)默認(rèn)的編碼來做轉(zhuǎn)換，你不能為一個(gè)Reader或者Writer指定轉(zhuǎn)換時(shí)使用的編碼。這也意味著，如果你使用中文版WindowsXP系統(tǒng)，而上面存放了一個(gè)UTF-8編碼的文件，當(dāng)你使用Reader類來讀入的時(shí)候，它會(huì)傻傻的使用GBK來做轉(zhuǎn)換，轉(zhuǎn)換后的內(nèi)容當(dāng)然驢唇不對(duì)馬嘴！
這種笨，有時(shí)候其實(shí)是一種傻瓜式的功能提供方式，對(duì)大多數(shù)初級(jí)用戶（以及不需要跨平臺(tái)的高級(jí)用戶）來說反而是件好事。
但我們不一樣啦，我們都是國家棟梁，肩負(fù)著趕英超美的責(zé)任，必須師夷長技以治夷，所以我們總還要和GBK編碼以外的文件打交道。
說了上面這些內(nèi)容，想必聰明的讀者已經(jīng)看出來，所謂編碼轉(zhuǎn)換就是一個(gè)字符與字節(jié)之間的轉(zhuǎn)換，因此Java的IO系統(tǒng)中能夠指定轉(zhuǎn)換編碼的地方，也就在字符與字節(jié)轉(zhuǎn)換的地方，那就是（讀者：InputStreamReader和OutputStreamWriter！作者：太強(qiáng)了，都會(huì)搶答了！）
PrintStream也可以對(duì)OutputStream進(jìn)行包裝并指定編碼方式：PrintStream(OutputStream out, boolean autoFlush, String encoding)，但實(shí)質(zhì)上也是調(diào)用OutputStreamWriter來實(shí)現(xiàn)的。System.err在eclipse中輸出時(shí)是紅色的字體。
這兩個(gè)類是字節(jié)流和字符流之間的適配器類，因此他們肩負(fù)著編碼轉(zhuǎn)換的任務(wù)簡直太自然啦！要注意，實(shí)際上也只能在這兩類實(shí)例化的時(shí)候指定編碼，是不是很好記呢？
下面來寫一段小程序，來把“漢”字用我們非常崇拜的UTF-8編碼寫到文件中！
Java代碼
try {
PrintWriter out = new PrintWriter(new OutputStreamWriter(
new FileOutputStream("c:/utf-8.txt"), "UTF-8"));
try {
out.write("漢");
} finally {
out.close();
}
} catch (IOException e) {
throw new RuntimeException(e);
}運(yùn)行之后到c盤下去找utf-8.txt這個(gè)文件，用UltraEdit打開，使用16進(jìn)制查看，看到了什么？它的值是0xE6B189！噢耶！（讀者：這，這有什么好高興的……）
#p#
Java號(hào)稱對(duì)Unicode提供天然的支持，這話在很久很久以前就已經(jīng)是假的了（不過曾經(jīng)是真的），實(shí)際上，到JDK5.0為止，Java才算剛剛跟上Unicode的腳步，開始提供對(duì)增補(bǔ)字符的支持。
現(xiàn)在的Unicode碼空間為U+0000到U+10FFFF，一共1114112個(gè)碼位，其中只有1，112，064 個(gè)碼位是合法的（我來替你做算術(shù)，有2048個(gè)碼位不合法），但并不是說現(xiàn)在的Unicode就有這么多個(gè)字符了，實(shí)際上其中很多碼位還是空閑的，到Unicode 4.0 規(guī)范為止，只有96，382個(gè)碼位被分配了字符（但無論如何，仍比很多人認(rèn)為的65536個(gè)字符要多得多了）。其中U+0000 到U+FFFF的部分被稱為基本多語言面（Basic Multilingual Plane，BMP）。U+10000及以上的字符稱為補(bǔ)充字符。在Java中（Java1.5之后），補(bǔ)充字符使用兩個(gè)char型變量來表示，這兩個(gè)char型變量就組成了所謂的surrogate pair（在底層實(shí)際上是使用一個(gè)int進(jìn)行表示的）。第一個(gè)char型變量的范圍稱為“高代理部分”（high-surrogates range，從"uD800到"uDBFF，共1024個(gè)碼位）， 第二個(gè)char型變量的范圍稱為low-surrogates range（從"uDC00到"uDFFF，共1024個(gè)碼位），這樣使用surrogate pair可以表示的字符數(shù)一共是1024的平方計(jì)1048576個(gè)，加上BMP的65536個(gè)碼位，去掉2048個(gè)非法的碼位，正好是1，112，064個(gè)碼位。
關(guān)于Unicode的碼空間實(shí)際上有一些稍不小心就會(huì)讓人犯錯(cuò)的地方。比如我們都知道從U+0000到U+FFFF的部分被稱為基本多語言面（Basic Multilingual Plane，BMP），這個(gè)范圍內(nèi)的字符在使用UTF-16編碼時(shí)，只需要一個(gè)char型變量就可以保存。仔細(xì)看看這個(gè)范圍，應(yīng)該有65536這么大，因此你會(huì)說單字節(jié)的UTF-16編碼能夠表示65536個(gè)字符，你也會(huì)說Unicode的基本多語言面包含65536個(gè)字符，但是再想想剛才說過的surrogate pair，一個(gè)UTF-16表示的增補(bǔ)字符（再一次的，需要兩個(gè)char型變量才能表示的字符）怎樣才能被正確的識(shí)別為增補(bǔ)字符，而不是兩個(gè)普通的字符呢？答案你也知道，就是通過看它的第一個(gè)char是不是在高代理范圍內(nèi)，第二個(gè)char是不是在低代理范圍內(nèi)來決定，這也意味著，高代理和低代理所占的共2048個(gè)碼位（從0xD800到0xDFFF）是不能分配給其他字符的。
但這是對(duì)UTF-16這種編碼方法而言，而對(duì)Unicode這樣的字符集呢？在Unicode的編號(hào)中，U+D800到U+DFFF是否有字符分配？答案是也沒有！這是典型的字符集為方便編碼方法而做的安排（你問他們這么做的目的？當(dāng)然是希望基本多語言面中的字符和一個(gè)char型的UTF-16編碼的字符能夠一一對(duì)應(yīng)，少些麻煩，從中我們也能看出UTF-16與Unicode間很深的淵源與結(jié)合）。也就是說，無論Unicode還是UTF-16編碼后的字符，在0x0000至0xFFFF這個(gè)范圍內(nèi)，只有63488個(gè)字符。這就好比最初的CPU被勉強(qiáng)拿來做多媒體應(yīng)用，用得多了，CPU就不得不修正自己從硬件上對(duì)多媒體應(yīng)用提供支持了。
盡管不情愿，但說到這里總還得扯扯相關(guān)的概念：代碼點(diǎn)和代碼單元。
代碼點(diǎn)（Code Point）就是指Unicode中為字符分配的編號(hào)，一個(gè)字符只占一個(gè)代碼點(diǎn)，例如我們說到字符“漢”，它的代碼點(diǎn)是U+6C49.代碼單元（Code Unit）則是針對(duì)編碼方法而言，它指的是編碼方法中對(duì)一個(gè)字符編碼以后所占的最小存儲(chǔ)單元。例如UTF-8中，代碼單元是一個(gè)字節(jié)，因?yàn)橐粋€(gè)字符可以被編碼為1個(gè)，2個(gè)或者3個(gè)4個(gè)字節(jié)；在UTF-16中，代碼單元變成了兩個(gè)字節(jié)（就是一個(gè)char），因?yàn)橐粋€(gè)字符可以被編碼為1個(gè)或2個(gè)char（你找不到比一個(gè)char還小的UTF-16編碼的字符，嘿嘿）。說得再羅嗦一點(diǎn)，一個(gè)字符，僅僅對(duì)應(yīng)一個(gè)代碼點(diǎn)，但卻可能有多個(gè)代碼單元（即可能被編碼為2個(gè)char）。
以上概念絕非學(xué)術(shù)化的繞口令，這意味著當(dāng)你想以一種統(tǒng)一的方式指定自己使用什么字符的時(shí)候，使用代碼點(diǎn)（即你告訴你的程序，你要用Unicode中的第幾個(gè)字符）總是比使用代碼單元更好（因?yàn)檫@樣做的話你還得區(qū)分情況，有時(shí)候提供一個(gè)16進(jìn)制數(shù)字，有時(shí)候要提供兩個(gè)）。
例如我們有一個(gè)增補(bǔ)字符？？？（哈哈，你看到了三個(gè)問號(hào)對(duì)吧？因?yàn)槲业南到y(tǒng)顯示不出這個(gè)字符），它在Unicode中的編號(hào)是U+2F81A，當(dāng)在程序中需要使用這個(gè)字符的時(shí)候，就可以這樣來寫：
Java代碼
String s=String.valueOf(Character.toChars(0x2F81A));
char[]chars=s.toCharArray();
for(char c:chars){
System.out.format("%x",(short)c);
}后面的for循環(huán)把這個(gè)字符的UTF-16編碼打印了出來，結(jié)果是d87edc1a注意到了嗎？這個(gè)字符變成了兩個(gè)char型變量，其中0xd87e就是高代理部分的值，0xdc1a就是低代理的值。
【編輯推薦】
