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