（一）Unicode與UCS的歷史恩怨 地球人都知道ASCII就是美國(guó)標(biāo)準(zhǔn)信息交換碼的縮寫，也知道ASCII規(guī)定用7位二進(jìn)制數(shù)字來表示英文字符，ASCII被定為國(guó)際標(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》一書。
無獨(dú)有偶，在1984年，喜歡以繁多的編號(hào)糊弄群眾的國(guó)際標(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)），這回真的足以容納古往今來所有國(guó)家，所有語言所包含的字符了（是的，任何國(guó)家，任何小語種都包 括，也不管這些國(guó)家是與臺(tái)灣建交還是與中國(guó)大陸建交，是擁護(hù)民主制度還是實(shí)行恐怖主義，所以說科學(xué)無國(guó)界）。雖然后來他們意識(shí)到，2的31次方個(gè)碼位又實(shí) 在太多了…… 天下大勢(shì)，分久必合。無論Unicode還是UCS，最初的目的都是杜絕各種各樣名目繁多形式各異互不兼容老死不相往來的私用擴(kuò)展編碼（好啰嗦的一句 話），結(jié)果兩方確立標(biāo)準(zhǔn)的同時(shí)（最初時(shí)這兩個(gè)標(biāo)準(zhǔn)是不兼容的），又形成了割據(jù)，這對(duì)建設(shè)和諧社會(huì)是不利的，違反當(dāng)今世界和平與發(fā)展的主旋律，中國(guó)政府一向 反對(duì)任何形式的霸權(quán)主義和強(qiáng)權(quán)政治，對(duì)以米國(guó)為首的發(fā)達(dá)國(guó)家……扯遠(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，指代兩者均無不妥。（二）編碼字符集與字符集編碼的區(qū)別需要再一次強(qiáng)調(diào)的是，無論歷史上的UCS還是現(xiàn)如今的Unicode，兩者指的都是編碼字符集，而不是字符集編碼?；ㄙM(fèi)一點(diǎn)時(shí)間來理解好這件事，然后你會(huì)發(fā)現(xiàn)對(duì)所有網(wǎng)頁的，系統(tǒng)的，編碼標(biāo)準(zhǔn)之間的來回轉(zhuǎn)換等等繁雜事務(wù)都會(huì)思路清晰，手到擒來。
字符集編碼決 定了如何將一個(gè)字符的整數(shù)編號(hào)對(duì)應(yīng)到一個(gè)二進(jìn)制的整數(shù)值，有的編碼方案簡(jiǎn)單的將該整數(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.（三）GB2312，GBK與中文網(wǎng)頁GB2312是對(duì)中國(guó)的開發(fā)人員來說很重要的一個(gè)詞匯，它的來龍去脈并不需要我在這里贅述，隨便Goolge之便明白無誤。我只是想提一句，記得前一節(jié)說到編碼字符集和字符集編碼不是一回事，而有的字符集編碼又實(shí)際上沒有做任何事，GB2312正是這樣一種東西！
GBK還是現(xiàn)如今中文Windows操作系統(tǒng)的系統(tǒng)默認(rèn)編碼（這正是幾乎所有網(wǎng)頁上的，文件里的亂碼問題的根源）。
輸出結(jié)果為GBK （什么？你的輸出不是這樣？怎么可能？完了，我的牌子要砸了，等等，你用的繁體版XP？我說你這同志在這里搗什么亂？去！去?。? 說到GB2312和GBK就不得不提中文網(wǎng)頁的編碼。盡管很多新開發(fā)的Web系統(tǒng)和新上線的注重國(guó)際化的網(wǎng)站都開始使用UTF-8，仍有相當(dāng)一部分的中文媒體堅(jiān)持使用GB2312和GBK，例如新浪的頁面。其中有兩點(diǎn)很值得注意。 第一，頁面中meta標(biāo)簽的部分，常?？梢砸姷絚harset=GB2312這樣的寫法，很不幸的是，這個(gè)“charset”其實(shí)是用來指定頁面使用的是什么字符集編碼，而不是使用什么字符集。例如你見到過有人寫“charset=UTF-8”，見到過有人寫“charset=ISO-8859-1”，但你見過有人寫“charset=Unicode”么？當(dāng)然沒有，因?yàn)?span style="color: #0061c3;">Unicode是一個(gè)字符集，而不是編碼。 然而正是charset這個(gè)名稱誤導(dǎo)了很多程序員，真的以為這里要指定的是字符集，也因而使他們進(jìn)一步的誤以為UTF-8和UTF-16是一種字符集?。ㄈf惡?。┖迷?strong>XML中已經(jīng)做出了修改，這個(gè)位置改成了正確的名稱：encoding.第二，頁面中說的GB2312，實(shí)際上并不真的是GB2312（驚 訝么？）。我們來做個(gè)實(shí)驗(yàn)，例如找一個(gè)GB2312中不存在的漢字“亸”（這個(gè)字確實(shí)不在GB2312中，你可以到GB2312的碼表中去找，保證找不 到），這個(gè)字在GBK中。然后你把它放到一個(gè)html頁面中，試著在瀏覽器中打開它，然后選擇瀏覽器的編碼為“GB2312”，看到了什么？它完全正常顯 示！
（四）網(wǎng)頁文件的編碼 接著上節(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ì)盡量猜測(cè)使用什么編碼查看最合適。
例如有這樣一個(gè)頁面，它使用GBK保存，但聲明自己是UTF-8的。這個(gè)時(shí)候用瀏覽器打開它，首先會(huì)看到亂碼，因?yàn)檫@個(gè)頁面“告訴”瀏覽器用UTF-8顯示，瀏覽器會(huì)很尊重這個(gè)提示，于是亂碼一片。但當(dāng)手工把瀏覽器設(shè)為GBK之后，顯示正常。 說了以上四節(jié)這么多，后面我們就來侃侃Java里的字符編碼，你會(huì)發(fā)現(xiàn)有意思且撓頭的事情很多，但一旦弄通，天下無敵（不過不要像東方不敗那樣才好）。 （五）Java代碼中的字符編碼轉(zhuǎn)換Part 1 如果你是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類型的變量中。例如你在程序中這樣寫
在內(nèi)存的相應(yīng)區(qū)域，這個(gè)字符就表示為0x6C49.可以用下面的代碼證明一下：
輸出是：6c49反過來用Unicode編號(hào)來指定一個(gè)字符也可以，像這樣：
輸出是：漢 這其實(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類）起作用的地方。
盡管看上去混亂繁雜，但是所有的IO基本上可以分為兩大陣營(yíng)：面向字符的Reader啊Wrtier啊，以及面向字節(jié)的輸入輸出流。
面向字符和面向字節(jié)中的所謂“面向”什么，是指這些類在處理輸入輸出的時(shí)候，在哪個(gè)意義上保持一致。如果是面向字節(jié)，那么這類工作要保證系統(tǒng)中的文件二進(jìn)制內(nèi)容和讀入JVM內(nèi)部的二進(jìn)制內(nèi)容要一致。不能變換任何0和1的順序（也就是文件是怎么存的就怎么取，與文件保存的編碼一致）。因此這是一種非?！爸覍?shí)于原著”的做法（偶然間讓我想起郭敬明抄襲莊羽的文章，那家伙，太忠實(shí)于原著了，笑）。
而面向字符的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í)用戶）來說反而是件好事。 說了上面這些內(nèi)容，想必聰明的讀者已經(jīng)看出來，所謂編碼轉(zhuǎn)換就是一個(gè)字符與字節(jié)之間的轉(zhuǎn)換，因此Java的IO系統(tǒng)中能夠指定轉(zhuǎn)換編碼的地方，也就在字符與字節(jié)轉(zhuǎn)換的地方，那就是（讀者：InputStreamReader和OutputStreamWriter！作者：太強(qiáng)了，都會(huì)搶答了?。?/span>
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ù)簡(jiǎn)直太自然啦！要注意，實(shí)際上也只能在這兩類實(shí)例化的時(shí)候指定編碼，是不是很好記呢？ 下面來寫一段小程序，來把“漢”字用我們非常崇拜的UTF-8編碼寫到文件中！ Java代碼 
運(yùn)行之后到c盤下去找utf-8.txt這個(gè)文件，用UltraEdit打開，使用16進(jìn)制查看，看到了什么？它的值是0xE6B189！噢耶?。ㄗx者：這，這有什么好高興的……） （六）Java中的增補(bǔ)字符 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代碼
后面的for循環(huán)把這個(gè)字符的UTF-16編碼打印了出來，結(jié)果是d87edc1a注意到了嗎？這個(gè)字符變成了兩個(gè)char型變量，其中0xd87e就是高代理部分的值，0xdc1a就是低代理的值。 |
|
|
