ascii和utf8的區(qū)別_ASCII編碼與UTF-8的關(guān)系

utf8

UTF-8（8-bit Unicode Transformation Format）是一種針對(duì)Unicode的可變長(zhǎng)度字符編碼，又稱萬國(guó)碼。由Ken Thompson于1992年創(chuàng)建?，F(xiàn)在已經(jīng)標(biāo)準(zhǔn)化為RFC 3629。UTF-8用1到6個(gè)字節(jié)編碼Unicode字符。用在網(wǎng)頁上可以統(tǒng)一頁面顯示中文簡(jiǎn)體繁體及其它語言（如英文，日文，韓文）。

如果UNICODE字符由2個(gè)字節(jié)表示，則編碼成UTF-8很可能需要3個(gè)字節(jié)。而如果UNICODE字符由4個(gè)字節(jié)表示，則編碼成UTF-8可能需要6個(gè)字節(jié)。用4個(gè)或6個(gè)字節(jié)去編碼一個(gè)UNICODE字符可能太多了，但很少會(huì)遇到那樣的UNICODE字符。

ascii

ASCII是基于拉丁字母的一套電腦編碼系統(tǒng)，主要用于顯示現(xiàn)代英語和其他西歐語言。它是現(xiàn)今最通用的單字節(jié)編碼系統(tǒng)，并等同于國(guó)際標(biāo)準(zhǔn)ISO/IEC 646。

在計(jì)算機(jī)中，所有的數(shù)據(jù)在存儲(chǔ)和運(yùn)算時(shí)都要使用二進(jìn)制數(shù)表示（因?yàn)橛?jì)算機(jī)用高電平和低電平分別表示1和0），例如，像a、b、c、d這樣的52個(gè)字母（包括大寫）、以及0、1等數(shù)字還有一些常用的符號(hào)（例如*、#、@等）在計(jì)算機(jī)中存儲(chǔ)時(shí)也要使用二進(jìn)制數(shù)來表示，而具體用哪些二進(jìn)制數(shù)字表示哪個(gè)符號(hào)，當(dāng)然每個(gè)人都可以約定自己的一套（這就叫編碼），而大家如果要想互相通信而不造成混亂，那么大家就必須使用相同的編碼規(guī)則，于是美國(guó)有關(guān)的標(biāo)準(zhǔn)化組織就出臺(tái)了ASCII編碼，統(tǒng)一規(guī)定了上述常用符號(hào)用哪些二進(jìn)制數(shù)來表示。

一、編碼歷史與區(qū)別

一直對(duì)字符的各種編碼方式懵懵懂懂，什么ANSI UNICODE UTF-8 GB2312 GBK DBCS UCS……是不是看的很暈，假如您細(xì)細(xì)的閱讀本文你一定可以清晰的理解他們。Let‘s go！

很久很久以前，有一群人，他們決定用8個(gè)可以開合的晶體管來組合成不同的狀態(tài)，以表示世界上的萬物。他們看到8個(gè)開關(guān)狀態(tài)是好的，于是他們把這稱為“字節(jié)”。

再后來，他們又做了一些可以處理這些字節(jié)的機(jī)器，機(jī)器開動(dòng)了，可以用字節(jié)來組合出很多狀態(tài)，狀態(tài)開始變來變?nèi)ァＫ麄兛吹竭@樣是好的，于是它們就這機(jī)器稱為“計(jì)算機(jī)”。

開始計(jì)算機(jī)只在美國(guó)用。八位的字節(jié)一共可以組合出256（2的8次方）種不同的狀態(tài)。

他們把其中的編號(hào)從0開始的32種狀態(tài)分別規(guī)定了特殊的用途，一但終端、打印機(jī)遇上約定好的這些字節(jié)被傳過來時(shí)，就要做一些約定的動(dòng)作。遇上00x10， 終端就換行，遇上0x07， 終端就向人們嘟嘟叫，例好遇上0x1b， 打印機(jī)就打印反白的字，或者終端就用彩色顯示字母。他們看到這樣很好，于是就把這些0x20以下的字節(jié)狀態(tài)稱為“控制碼”。

他們又把所有的空格、標(biāo)點(diǎn)符號(hào)、數(shù)字、大小寫字母分別用連續(xù)的字節(jié)狀態(tài)表示，一直編到了第127號(hào)，這樣計(jì)算機(jī)就可以用不同字節(jié)來存儲(chǔ)英語的文字了。大家看到這樣，都感覺很好，于是大家都把這個(gè)方案叫做 ANSI 的“Ascii”編碼（American Standard Code for Information Interchange，美國(guó)信息互換標(biāo)準(zhǔn)代碼）。當(dāng)時(shí)世界上所有的計(jì)算機(jī)都用同樣的ASCII方案來保存英文文字。

后來，就像建造巴比倫塔一樣，世界各地的都開始使用計(jì)算機(jī)，但是很多國(guó)家用的不是英文，他們的字母里有許多是ASCII里沒有的，為了可以在計(jì)算機(jī)保存他們的文字，他們決定采用127號(hào)之后的空位來表示這些新的字母、符號(hào)，還加入了很多畫表格時(shí)需要用下到的橫線、豎線、交叉等形狀，一直把序號(hào)編到了最后一個(gè)狀態(tài)255。從128到255這一頁的字符集被稱“擴(kuò)展字符集”。從此之后，貪婪的人類再?zèng)]有新的狀態(tài)可以用了，美帝國(guó)主義可能沒有想到還有第三世界國(guó)家的人們也希望可以用到計(jì)算機(jī)吧！

等中國(guó)人們得到計(jì)算機(jī)時(shí)，已經(jīng)沒有可以利用的字節(jié)狀態(tài)來表示漢字，況且有6000多個(gè)常用漢字需要保存呢。但是這難不倒智慧的中國(guó)人民，我們不客氣地把那些127號(hào)之后的奇異符號(hào)們直接取消掉， 規(guī)定：一個(gè)小于127的字符的意義與原來相同，但兩個(gè)大于127的字符連在一起時(shí)，就表示一個(gè)漢字，前面的一個(gè)字節(jié)（他稱之為高字節(jié)）從0xA1用到0xF7，后面一個(gè)字節(jié)（低字節(jié)）從0xA1到0xFE，這樣我們就可以組合出大約7000多個(gè)簡(jiǎn)體漢字了。在這些編碼里，我們還把數(shù)學(xué)符號(hào)、羅馬希臘的字母、日文的假名們都編進(jìn)去了，連在 ASCII 里本來就有的數(shù)字、標(biāo)點(diǎn)、字母都統(tǒng)統(tǒng)重新編了兩個(gè)字節(jié)長(zhǎng)的編碼，這就是常說的“全角”字符，而原來在127號(hào)以下的那些就叫“半角”字符了。

中國(guó)人民看到這樣很不錯(cuò)，于是就把這種漢字方案叫做 “GB2312”。GB2312 是對(duì) ASCII 的中文擴(kuò)展。

但是中國(guó)的漢字太多了，我們很快就就發(fā)現(xiàn)有許多人的人名沒有辦法在這里打出來，特別是某些很會(huì)麻煩別人的國(guó)家領(lǐng)導(dǎo)人。于是我們不得不繼續(xù)把 GB2312 沒有用到的碼位找出來老實(shí)不客氣地用上。

后來還是不夠用，于是干脆不再要求低字節(jié)一定是127號(hào)之后的內(nèi)碼，只要第一個(gè)字節(jié)是大于127就固定表示這是一個(gè)漢字的開始，不管后面跟的是不是擴(kuò)展字符集里的內(nèi)容。結(jié)果擴(kuò)展之后的編碼方案被稱為 GBK 標(biāo)準(zhǔn)，GBK 包括了 GB2312 的所有內(nèi)容，同時(shí)又增加了近20000個(gè)新的漢字（包括繁體字）和符號(hào)。

后來少數(shù)民族也要用電腦了，于是我們?cè)贁U(kuò)展，又加了幾千個(gè)新的少數(shù)民族的字，GBK 擴(kuò)成了 GB18030。從此之后，中華民族的文化就可以在計(jì)算機(jī)時(shí)代中傳承了。

中國(guó)的程序員們看到這一系列漢字編碼的標(biāo)準(zhǔn)是好的，于是通稱他們叫做 “DBCS”（Double Byte Charecter Set 雙字節(jié)字符集）。在DBCS系列標(biāo)準(zhǔn)里，最大的特點(diǎn)是兩字節(jié)長(zhǎng)的漢字字符和一字節(jié)長(zhǎng)的英文字符并存于同一套編碼方案里，因此他們寫的程序?yàn)榱酥С种形奶幚?，必須要注意字串里的每一個(gè)字節(jié)的值，如果這個(gè)值是大于127的，那么就認(rèn)為一個(gè)雙字節(jié)字符集里的字符出現(xiàn)了。那時(shí)候凡是受過加持，會(huì)編程的計(jì)算機(jī)僧侶們都要每天念下面這個(gè)咒語數(shù)百遍：

“一個(gè)漢字算兩個(gè)英文字符！一個(gè)漢字算兩個(gè)英文字符……”

因?yàn)楫?dāng)時(shí)各個(gè)國(guó)家都像中國(guó)這樣搞出一套自己的編碼標(biāo)準(zhǔn)，結(jié)果互相之間誰也不懂誰的編碼，誰也不支持別人的編碼，連大陸和***這樣只相隔了150海里，使用著同一種語言的兄弟地區(qū)，也分別采用了不同的 DBCS 編碼方案——當(dāng)時(shí)的中國(guó)人想讓電腦顯示漢字，就必須裝上一個(gè)“漢字系統(tǒng)”，專門用來處理漢字的顯示、輸入的問題，但是那個(gè)***的愚昧封建人士寫的算命程序就必須加裝另一套支持 BIG5 編碼的什么“倚天漢字系統(tǒng)”才可以用，裝錯(cuò)了字符系統(tǒng)，顯示就會(huì)亂了套！這怎么辦？而且世界民族之林中還有那些一時(shí)用不上電腦的窮苦人民，他們的文字又怎么辦？

真是計(jì)算機(jī)的巴比倫塔命題??！

正在這時(shí)，大天使加百列及時(shí)出現(xiàn)了——一個(gè)叫 ISO （國(guó)際標(biāo)誰化組織）的國(guó)際組織決定著手解決這個(gè)問題。他們采用的方法很簡(jiǎn)單：廢了所有的地區(qū)性編碼方案，重新搞一個(gè)包括了地球上所有文化、所有字母和符號(hào)的編碼！他們打算叫它“Universal Multiple-Octet Coded Character Set”，簡(jiǎn)稱 UCS， 俗稱 “UNICODE”。

UNICODE 開始制訂時(shí)，計(jì)算機(jī)的存儲(chǔ)器容量極大地發(fā)展了，空間再也不成為問題了。于是 ISO 就直接規(guī)定必須用兩個(gè)字節(jié)，也就是16位來統(tǒng)一表示所有的字符，對(duì)于ascii里的那些“半角”字符，UNICODE 包持其原編碼不變，只是將其長(zhǎng)度由原來的8位擴(kuò)展為16位，而其他文化和語言的字符則全部重新統(tǒng)一編碼。由于“半角”英文符號(hào)只需要用到低8位，所以其高8位永遠(yuǎn)是0，因此這種大氣的方案在保存英文文本時(shí)會(huì)多浪費(fèi)一倍的空間。

這時(shí)候，從舊社會(huì)里走過來的程序員開始發(fā)現(xiàn)一個(gè)奇怪的現(xiàn)象：他們的strlen函數(shù)靠不住了，一個(gè)漢字不再是相當(dāng)于兩個(gè)字符了，而是一個(gè)！是的，從 UNICODE 開始，無論是半角的英文字母，還是全角的漢字，它們都是統(tǒng)一的“一個(gè)字符”！同時(shí)，也都是統(tǒng)一的“兩個(gè)字節(jié)”，請(qǐng)注意“字符”和“字節(jié)”兩個(gè)術(shù)語的不同，“字節(jié)”是一個(gè)8位的物理存貯單元，而“字符”則是一個(gè)文化相關(guān)的符號(hào)。在UNICODE 中，一個(gè)字符就是兩個(gè)字節(jié)。一個(gè)漢字算兩個(gè)英文字符的時(shí)代已經(jīng)快過去了。

從前多種字符集存在時(shí)，那些做多語言軟件的公司遇上過很大麻煩，他們?yōu)榱嗽诓煌膰?guó)家銷售同一套軟件，就不得不在區(qū)域化軟件時(shí)也加持那個(gè)雙字節(jié)字符集咒語，不僅要處處小心不要搞錯(cuò)，還要把軟件中的文字在不同的字符集中轉(zhuǎn)來轉(zhuǎn)去。UNICODE 對(duì)于他們來說是一個(gè)很好的一攬子解決方案，于是從 Windows NT 開始，MS 趁機(jī)把它們的操作系統(tǒng)改了一遍，把所有的核心代碼都改成了用 UNICODE 方式工作的版本，從這時(shí)開始，WINDOWS 系統(tǒng)終于無需要加裝各種本土語言系統(tǒng)，就可以顯示全世界上所有文化的字符了。

但是，UNICODE 在制訂時(shí)沒有考慮與任何一種現(xiàn)有的編碼方案保持兼容，這使得 GBK 與UNICODE 在漢字的內(nèi)碼編排上完全是不一樣的，沒有一種簡(jiǎn)單的算術(shù)方法可以把文本內(nèi)容從UNICODE編碼和另一種編碼進(jìn)行轉(zhuǎn)換，這種轉(zhuǎn)換必須通過查表來進(jìn)行。

如前所述，UNICODE 是用兩個(gè)字節(jié)來表示為一個(gè)字符，他總共可以組合出65535不同的字符，這大概已經(jīng)可以覆蓋世界上所有文化的符號(hào)。如果還不夠也沒有關(guān)系，ISO已經(jīng)準(zhǔn)備了UCS-4方案，說簡(jiǎn)單了就是四個(gè)字節(jié)來表示一個(gè)字符，這樣我們就可以組合出21億個(gè)不同的字符出來（最高位有其他用途），這大概可以用到銀河聯(lián)邦成立那一天吧！

UNICODE 來到時(shí)，一起到來的還有計(jì)算機(jī)網(wǎng)絡(luò)的興起，UNICODE 如何在網(wǎng)絡(luò)上傳輸也是一個(gè)必須考慮的問題，于是面向傳輸?shù)谋姸?UTF（UCS Transfer Format）標(biāo)準(zhǔn)出現(xiàn)了，顧名思義，UTF8就是每次8個(gè)位傳輸數(shù)據(jù)，而UTF16就是每次16個(gè)位，只不過為了傳輸時(shí)的可靠性，從UNICODE到UTF時(shí)并不是直接的對(duì)應(yīng)，而是要過一些算法和規(guī)則來轉(zhuǎn)換。

受到過網(wǎng)絡(luò)編程加持的計(jì)算機(jī)僧侶們都知道，在網(wǎng)絡(luò)里傳遞信息時(shí)有一個(gè)很重要的問題，就是對(duì)于數(shù)據(jù)高低位的解讀方式，一些計(jì)算機(jī)是采用低位先發(fā)送的方法，例如我們PC機(jī)采用的 INTEL 架構(gòu)，而另一些是采用高位先發(fā)送的方式，在網(wǎng)絡(luò)中交換數(shù)據(jù)時(shí)，為了核對(duì)雙方對(duì)于高低位的認(rèn)識(shí)是否是一致的，采用了一種很簡(jiǎn)便的方法，就是在文本流的開始時(shí)向?qū)Ψ桨l(fā)送一個(gè)標(biāo)志符——如果之后的文本是高位在位，那就發(fā)送“FEFF”，反之，則發(fā)送“FFFE”。不信你可以用二進(jìn)制方式打開一個(gè)UTF-X格式的文件，看看開頭兩個(gè)字節(jié)是不是這兩個(gè)字節(jié)？

講到這里，我們?cè)夙槺阏f說一個(gè)很著名的奇怪現(xiàn)象：當(dāng)你在 windows 的記事本里新建一個(gè)文件，輸入“聯(lián)通”兩個(gè)字之后，保存，關(guān)閉，然后再次打開，你會(huì)發(fā)現(xiàn)這兩個(gè)字已經(jīng)消失了，代之的是幾個(gè)亂碼！呵呵，有人說這就是聯(lián)通之所以拼不過移動(dòng)的原因。

其實(shí)這是因?yàn)镚B2312編碼與UTF8編碼產(chǎn)生了編碼沖撞的原因。

從網(wǎng)上引來一段從UNICODE到UTF8的轉(zhuǎn)換規(guī)則：

Unicode

UTF-8

0000 - 007F

0xxxxxxx

0080 - 07FF

110xxxxx 10xxxxxx

0800 - FFFF

1110xxxx 10xxxxxx 10xxxxxx

例如“漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間，所以要用3字節(jié)模板：1110xxxx 10xxxxxx 10xxxxxx。將6C49寫成二進(jìn)制是：0110 1100 0100 1001，將這個(gè)比特流按三字節(jié)模板的分段方法分為0110 110001 001001，依次代替模板中的x，得到：1110-0110 10-110001 10-001001，即E6 B1 89，這就是其UTF8的編碼。

而當(dāng)你新建一個(gè)文本文件時(shí)，記事本的編碼默認(rèn)是ANSI， 如果你在ANSI的編碼輸入漢字，那么他實(shí)際就是GB系列的編碼方式，在這種編碼下，“聯(lián)通”的內(nèi)碼是：

c1 1100 0001

aa 1010 1010

cd 1100 1101

a8 1010 1000

注意到了嗎？第一二個(gè)字節(jié)、第三四個(gè)字節(jié)的起始部分的都是“110”和“10”，正好與UTF8規(guī)則里的兩字節(jié)模板是一致的，于是再次打開記事本時(shí)，記事本就誤認(rèn)為這是一個(gè)UTF8編碼的文件，讓我們把第一個(gè)字節(jié)的110和第二個(gè)字節(jié)的10去掉，我們就得到了“00001 101010”，再把各位對(duì)齊，補(bǔ)上前導(dǎo)的0，就得到了“0000 0000 0110 1010”，不好意思，這是UNICODE的006A，也就是小寫的字母“j”，而之后的兩字節(jié)用UTF8解碼之后是0368，這個(gè)字符什么也不是。這就是只有“聯(lián)通”兩個(gè)字的文件沒有辦法在記事本里正常顯示的原因。

而如果你在“聯(lián)通”之后多輸入幾個(gè)字，其他的字的編碼不見得又恰好是110和10開始的字節(jié)，這樣再次打開時(shí)，記事本就不會(huì)堅(jiān)持這是一個(gè)utf8編碼的文件，而會(huì)用ANSI的方式解讀之，這時(shí)亂碼又不出現(xiàn)了。

好了，終于可以回答NICO的問題了，在數(shù)據(jù)庫里，有n前綴的字串類型就是UNICODE類型，這種類型中，固定用兩個(gè)字節(jié)來表示一個(gè)字符，無論這個(gè)字符是漢字還是英文字母，或是別的么。

如果你要測(cè)試“abc漢字”這個(gè)串的長(zhǎng)度，在沒有n前綴的數(shù)據(jù)類型里，這個(gè)字串是7個(gè)字符的長(zhǎng)度，因?yàn)橐粋€(gè)漢字相當(dāng)于兩個(gè)字符。而在有n前綴的數(shù)據(jù)類型里，同樣的測(cè)試串長(zhǎng)度的函數(shù)將會(huì)告訴你是5個(gè)字符，因?yàn)橐粋€(gè)漢字就是一個(gè)字符。

1. ASCII碼

我們知道，在計(jì)算機(jī)內(nèi)部，所有的信息最終都表示為一個(gè)二進(jìn)制的字符串。每一個(gè)二進(jìn)制位（bit）有0和1兩種狀態(tài)，因此八個(gè)二進(jìn)制位就可以組合出256種狀態(tài)，這被稱為一個(gè)字節(jié)（byte）。也就是說，一個(gè)字節(jié)一共可以用來表示256種不同的狀態(tài)，每一個(gè)狀態(tài)對(duì)應(yīng)一個(gè)符號(hào)，就是256個(gè)符號(hào)，從0000000到11111111。

上個(gè)世紀(jì)60年代，美國(guó)制定了一套字符編碼，對(duì)英語字符與二進(jìn)制位之間的關(guān)系，做了統(tǒng)一規(guī)定。這被稱為ASCII碼，一直沿用至今。

ASCII碼一共規(guī)定了128個(gè)字符的編碼，比如空格“SPACE”是32（二進(jìn)制00100000），大寫的字母A是65（二進(jìn)制01000001）。這128個(gè)符號(hào)（包括32個(gè)不能打印出來的控制符號(hào)），只占用了一個(gè)字節(jié)的后面7位，最前面的1位統(tǒng)一規(guī)定為0。

2、非ASCII編碼

英語用128個(gè)符號(hào)編碼就夠了，但是用來表示其他語言，128個(gè)符號(hào)是不夠的。比如，在法語中，字母上方有注音符號(hào)，它就無法用ASCII碼表示。于是，一些歐洲國(guó)家就決定，利用字節(jié)中閑置的最高位編入新的符號(hào)。比如，法語中的é的編碼為130（二進(jìn)制10000010）。這樣一來，這些歐洲國(guó)家使用的編碼體系，可以表示最多256個(gè)符號(hào)。

但是，這里又出現(xiàn)了新的問題。不同的國(guó)家有不同的字母，因此，哪怕它們都使用256個(gè)符號(hào)的編碼方式，代表的字母卻不一樣。比如，130在法語編碼中代表了é，在希伯來語編碼中卻代表了字母Gimel （?），在俄語編碼中又會(huì)代表另一個(gè)符號(hào)。但是不管怎樣，所有這些編碼方式中，0—127表示的符號(hào)是一樣的，不一樣的只是128—255的這一段。

至于亞洲國(guó)家的文字，使用的符號(hào)就更多了，漢字就多達(dá)10萬左右。一個(gè)字節(jié)只能表示256種符號(hào)，肯定是不夠的，就必須使用多個(gè)字節(jié)表達(dá)一個(gè)符號(hào)。比如，簡(jiǎn)體中文常見的編碼方式是GB2312，使用兩個(gè)字節(jié)表示一個(gè)漢字，所以理論上最多可以表示256x256=65536個(gè)符號(hào)。

中文編碼的問題需要專文討論，這篇筆記不涉及。這里只指出，雖然都是用多個(gè)字節(jié)表示一個(gè)符號(hào)，但是GB類的漢字編碼與后文的Unicode和UTF-8是毫無關(guān)系的。

3.Unicode

正如上一節(jié)所說，世界上存在著多種編碼方式，同一個(gè)二進(jìn)制數(shù)字可以被解釋成不同的符號(hào)。因此，要想打開一個(gè)文本文件，就必須知道它的編碼方式，否則用錯(cuò)誤的編碼方式解讀，就會(huì)出現(xiàn)亂碼。為什么電子郵件常常出現(xiàn)亂碼？就是因?yàn)榘l(fā)信人和收信人使用的編碼方式不一樣。

可以想象，如果有一種編碼，將世界上所有的符號(hào)都納入其中。每一個(gè)符號(hào)都給予一個(gè)獨(dú)一無二的編碼，那么亂碼問題就會(huì)消失。這就是Unicode，就像它的名字都表示的，這是一種所有符號(hào)的編碼。

Unicode當(dāng)然是一個(gè)很大的集合，現(xiàn)在的規(guī)模可以容納100多萬個(gè)符號(hào)。每個(gè)符號(hào)的編碼都不一樣，比如，U+0639表示阿拉伯字母Ain，U+0041表示英語的大寫字母A，U+4E25表示漢字“嚴(yán)”。具體的符號(hào)對(duì)應(yīng)表，可以查詢unicode.org，或者專門的漢字對(duì)應(yīng)表。

4. Unicode的問題

需要注意的是，Unicode只是一個(gè)符號(hào)集，它只規(guī)定了符號(hào)的二進(jìn)制代碼，卻沒有規(guī)定這個(gè)二進(jìn)制代碼應(yīng)該如何存儲(chǔ)。

比如，漢字“嚴(yán)”的unicode是十六進(jìn)制數(shù)4E25，轉(zhuǎn)換成二進(jìn)制數(shù)足足有15位（100111000100101），也就是說這個(gè)符號(hào)的表示至少需要2個(gè)字節(jié)。表示其他更大的符號(hào)，可能需要3個(gè)字節(jié)或者4個(gè)字節(jié)，甚至更多。

這里就有兩個(gè)嚴(yán)重的問題，第一個(gè)問題是，如何才能區(qū)別unicode和ascii？計(jì)算機(jī)怎么知道三個(gè)字節(jié)表示一個(gè)符號(hào)，而不是分別表示三個(gè)符號(hào)呢？第二個(gè)問題是，我們已經(jīng)知道，英文字母只用一個(gè)字節(jié)表示就夠了，如果unicode統(tǒng)一規(guī)定，每個(gè)符號(hào)用三個(gè)或四個(gè)字節(jié)表示，那么每個(gè)英文字母前都必然有二到三個(gè)字節(jié)是0，這對(duì)于存儲(chǔ)來說是極大的浪費(fèi)，文本文件的大小會(huì)因此大出二三倍，這是無法接受的。

它們?cè)斐傻慕Y(jié)果是：1）出現(xiàn)了unicode的多種存儲(chǔ)方式，也就是說有許多種不同的二進(jìn)制格式，可以用來表示unicode。2）unicode在很長(zhǎng)一段時(shí)間內(nèi)無法推廣，直到互聯(lián)網(wǎng)的出現(xiàn)。

5.UTF-8

互聯(lián)網(wǎng)的普及，強(qiáng)烈要求出現(xiàn)一種統(tǒng)一的編碼方式。UTF-8就是在互聯(lián)網(wǎng)上使用最廣的一種unicode的實(shí)現(xiàn)方式。其他實(shí)現(xiàn)方式還包括UTF-16和UTF-32，不過在互聯(lián)網(wǎng)上基本不用。重復(fù)一遍，這里的關(guān)系是，UTF-8是Unicode的實(shí)現(xiàn)方式之一。

UTF-8最大的一個(gè)特點(diǎn)，就是它是一種變長(zhǎng)的編碼方式。它可以使用1~4個(gè)字節(jié)表示一個(gè)符號(hào)，根據(jù)不同的符號(hào)而變化字節(jié)長(zhǎng)度。

UTF-8的編碼規(guī)則很簡(jiǎn)單，只有二條：

1）對(duì)于單字節(jié)的符號(hào)，字節(jié)的第一位設(shè)為0，后面7位為這個(gè)符號(hào)的unicode碼。因此對(duì)于英語字母，UTF-8編碼和ASCII碼是相同的。

2）對(duì)于n字節(jié)的符號(hào)（n》1），第一個(gè)字節(jié)的前n位都設(shè)為1，第n+1位設(shè)為0，后面字節(jié)的前兩位一律設(shè)為10。剩下的沒有提及的二進(jìn)制位，全部為這個(gè)符號(hào)的unicode碼。

下表總結(jié)了編碼規(guī)則，字母x表示可用編碼的位。

Unicode符號(hào)范圍 | UTF-8編碼方式

（十六進(jìn)制） | （二進(jìn)制）

--------------------+---------------------------------------------

0000 0000-0000 007F | 0xxxxxxx

0000 0080-0000 07FF | 110xxxxx 10xxxxxx

0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx

0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

下面，還是以漢字“嚴(yán)”為例，演示如何實(shí)現(xiàn)UTF-8編碼。

已知“嚴(yán)”的unicode是4E25（100111000100101），根據(jù)上表，可以發(fā)現(xiàn)4E25處在第三行的范圍內(nèi)（0000 0800-0000 FFFF），因此“嚴(yán)”的UTF-8編碼需要三個(gè)字節(jié)，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，從“嚴(yán)”的最后一個(gè)二進(jìn)制位開始，依次從后向前填入格式中的x，多出的位補(bǔ)0。這樣就得到了，“嚴(yán)”的UTF-8編碼是“11100100 10111000 10100101”，轉(zhuǎn)換成十六進(jìn)制就是E4B8A5。

6. Unicode與UTF-8之間的轉(zhuǎn)換

通過上一節(jié)的例子，可以看到“嚴(yán)”的Unicode碼是4E25，UTF-8編碼是E4B8A5，兩者是不一樣的。它們之間的轉(zhuǎn)換可以通過程序?qū)崿F(xiàn)。

在Windows平臺(tái)下，有一個(gè)最簡(jiǎn)單的轉(zhuǎn)化方法，就是使用內(nèi)置的記事本小程序Notepad.exe。打開文件后，點(diǎn)擊“文件”菜單中的“另存為”命令，會(huì)跳出一個(gè)對(duì)話框，在最底部有一個(gè)“編碼”的下拉條。

里面有四個(gè)選項(xiàng)：ANSI，Unicode，Unicode big endian 和 UTF-8。

1）ANSI是默認(rèn)的編碼方式。對(duì)于英文文件是ASCII編碼，對(duì)于簡(jiǎn)體中文文件是GB2312編碼（只針對(duì)Windows簡(jiǎn)體中文版，如果是繁體中文版會(huì)采用Big5碼）。

2）Unicode編碼指的是UCS-2編碼方式，即直接用兩個(gè)字節(jié)存入字符的Unicode碼。這個(gè)選項(xiàng)用的little endian格式。

3）Unicode big endian編碼與上一個(gè)選項(xiàng)相對(duì)應(yīng)。我在下一節(jié)會(huì)解釋little endian和big endian的涵義。

4）UTF-8編碼，也就是上一節(jié)談到的編碼方法。

選擇完”編碼方式“后，點(diǎn)擊”保存“按鈕，文件的編碼方式就立刻轉(zhuǎn)換好了。

7. Little endian和Big endian

上一節(jié)已經(jīng)提到，Unicode碼可以采用UCS-2格式直接存儲(chǔ)。以漢字”嚴(yán)“為例，Unicode碼是4E25，需要用兩個(gè)字節(jié)存儲(chǔ)，一個(gè)字節(jié)是4E，另一個(gè)字節(jié)是25。存儲(chǔ)的時(shí)候，4E在前，25在后，就是Big endian方式；25在前，4E在后，就是Little endian方式。

這兩個(gè)古怪的名稱來自英國(guó)作家斯威夫特的《格列佛游記》。在該書中，小人國(guó)里爆發(fā)了內(nèi)戰(zhàn)，戰(zhàn)爭(zhēng)起因是人們爭(zhēng)論，吃雞蛋時(shí)究竟是從大頭（Big-Endian）敲開還是從小頭（Little-Endian）敲開。為了這件事情，前后爆發(fā)了六次戰(zhàn)爭(zhēng)，一個(gè)皇帝送了命，另一個(gè)皇帝丟了王位。

因此，第一個(gè)字節(jié)在前，就是”大頭方式“（Big endian），第二個(gè)字節(jié)在前就是”小頭方式“（Little endian）。

那么很自然的，就會(huì)出現(xiàn)一個(gè)問題：計(jì)算機(jī)怎么知道某一個(gè)文件到底采用哪一種方式編碼？

Unicode規(guī)范中定義，每一個(gè)文件的最前面分別加入一個(gè)表示編碼順序的字符，這個(gè)字符的名字叫做”零寬度非換行空格“（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。這正好是兩個(gè)字節(jié)，而且FF比FE大1。

如果一個(gè)文本文件的頭兩個(gè)字節(jié)是FE FF，就表示該文件采用大頭方式；如果頭兩個(gè)字節(jié)是FF FE，就表示該文件采用小頭方式。

8. 實(shí)例

下面，舉一個(gè)實(shí)例。

打開”記事本“程序Notepad.exe，新建一個(gè)文本文件，內(nèi)容就是一個(gè)”嚴(yán)“字，依次采用ANSI，Unicode，Unicode big endian 和 UTF-8編碼方式保存。

然后，用文本編輯軟件UltraEdit中的”十六進(jìn)制功能“，觀察該文件的內(nèi)部編碼方式。

1）ANSI：文件的編碼就是兩個(gè)字節(jié)“D1 CF”，這正是“嚴(yán)”的GB2312編碼，這也暗示GB2312是采用大頭方式存儲(chǔ)的。

2）Unicode：編碼是四個(gè)字節(jié)“FF FE 25 4E”，其中“FF FE”表明是小頭方式存儲(chǔ)，真正的編碼是4E25。

3）Unicode big endian：編碼是四個(gè)字節(jié)“FE FF 4E 25”，其中“FE FF”表明是大頭方式存儲(chǔ)。

4）UTF-8：編碼是六個(gè)字節(jié)“EF BB BF E4 B8 A5”，前三個(gè)字節(jié)“EF BB BF”表示這是UTF-8編碼，后三個(gè)“E4B8A5”就是“嚴(yán)”的具體編碼，它的存儲(chǔ)順序與編碼順序是一致的。

二、編碼轉(zhuǎn)換

［html］ view plaincopy

/** 中文字符串轉(zhuǎn)UTF-8與GBK碼示例

*/

public static void tttt（） throws Exception {

String old = “手機(jī)銀行”;

//中文轉(zhuǎn)換成UTF-8編碼（16進(jìn)制字符串）

StringBuffer utf8Str = new StringBuffer（）;

byte［］ utf8Decode = old.getBytes（“utf-8”）;

for （byte b ： utf8Decode） {

utf8Str.append（Integer.toHexString（b & 0xFF））;

}

// utf8Str.toString（）=====e6898be69cbae993b6e8a18c

// System.out.println（“UTF-8字符串e6898be69cbae993b6e8a18c轉(zhuǎn)換成中文值======” + new String（utf8Decode， “utf-8”））;//-------手機(jī)銀行

//中文轉(zhuǎn)換成GBK碼（16進(jìn)制字符串）

StringBuffer gbkStr = new StringBuffer（）;

byte［］ gbkDecode = old.getBytes（“gbk”）;

for （byte b ： gbkDecode） {

gbkStr.append（Integer.toHexString（b & 0xFF））;

}

// gbkStr.toString（）=====cad6bbfad2f8d0d0

// System.out.println（“GBK字符串cad6bbfad2f8d0d0轉(zhuǎn)換成中文值======” + new String（gbkDecode， “gbk”））;//----------手機(jī)銀行

//16進(jìn)制字符串轉(zhuǎn)換成中文

byte［］ bb = HexString2Bytes（gbkStr.toString（））;

bb = HexString2Bytes（“CAD6BBFAD2F8D0D0000000000000000000000000”）;

byte［］ cc = hexToByte（“CAD6BBFAD2F8D0D0000000000000000000000000”， 20）;

String aa = new String（bb， “gbk”）;

System.out.println（“aa====” + aa）;

}

［html］ view plaincopy/**

* 把16進(jìn)制字符串轉(zhuǎn)換成字節(jié)數(shù)組

* @param hexstr

* @return

*/

public static byte［］ HexString2Bytes（String hexstr） {

byte［］ b = new byte［hexstr.length（） / 2］;

int j = 0;

for （int i = 0; i 《 b.length; i++） {

char c0 = hexstr.charAt（j++）;

char c1 = hexstr.charAt（j++）;

b［i］ = （byte） （（parse（c0） 《《 4） | parse（c1））;

}

return b;

}

private static int parse（char c） {

if （c 》= ’a‘）

return （c - ’a‘ + 10） & 0x0f;

if （c 》= ’A‘）

return （c - ’A‘ + 10） & 0x0f;

return （c - ’0‘） & 0x0f;

}

［html］ view plaincopy/**

* 把字節(jié)數(shù)組轉(zhuǎn)換成16進(jìn)制字符串

* @param bArray

* @return

*/

public static final String bytesToHexString（byte［］ bArray） {

StringBuffer sb = new StringBuffer（bArray.length）;

String sTemp;

for （int i = 0; i 《 bArray.length; i++） {

sTemp = Integer.toHexString（0xFF & bArray［i］）;

if （sTemp.length（） 《 2）

sb.append（0）;

sb.append（sTemp.toUpperCase（））;

}

return sb.toString（）;

}