一、編碼歷史與區別

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

　　很久很久以前，有一群人，他們決定用8個可以開合的電晶體來組合成不同的狀態，以表示世界上的萬物。他們看到8個開關狀態是好的，於是他們把這稱為"位元組"。

　　再後來，他們又做了一些可以處理這些位元組的機器，機器開動了，可以用位元組來組合出很多狀態，狀態開始變來變去。他們看到這樣是好的，於是它們就這機器稱為"計算機"。

　　開始計算機只在美國用。八位的位元組一共可以組合出256(2的8次方)種不同的狀態。

　　他們把其中的編號從0開始的32種狀態分別規定了特殊的用途，一但終端、印表機遇上約定好的這些位元組被傳過來時，就要做一些約定的動作。遇上00x10, 終端就換行，遇上0x07, 終端就向人們嘟嘟叫，例好遇上0x1b, 印表機就列印反白的字，或者終端就用彩色顯示字母。他們看到這樣很好，於是就把這些0x20以下的位元組狀態稱為"控制碼"。

　　他們又把所有的空格、標點符號、數字、大小寫字母分別用連續的位元組狀態表示，一直編到了第127號，這樣計算機就可以用不同位元組來儲存英語的文字了。大家看到這樣，都感覺很好，於是大家都把這個方案叫做 ANSI 的"Ascii"編碼（American Standard Code for Information Interchange，美國資訊互換標準程式碼）。當時世界上所有的計算機都用同樣的ASCII方案來儲存英文文字。

　　後來，就像建造巴比倫塔一樣，世界各地的都開始使用計算機，但是很多國家用的不是英文，他們的字母裡有許多是ASCII裡沒有的，為了可以在計算機儲存他們的文字，他們決定採用127號之後的空位來表示這些新的字母、符號，還加入了很多畫表格時需要用下到的橫線、豎線、交叉等形狀，一直把序號編到了最後一個狀態255。從128到255這一頁的字符集被稱"擴充套件字符集"。從此之後，貪婪的人類再沒有新的狀態可以用了，美帝國主義可能沒有想到還有第三世界國家的人們也希望可以用到計算機吧！

　　等中國人們得到計算機時，已經沒有可以利用的位元組狀態來表示漢字，況且有6000多個常用漢字需要儲存呢。但是這難不倒智慧的中國人民，我們不客氣地把那些127號之後的奇異符號們直接取消掉, 規定：一個小於127的字元的意義與原來相同，但兩個大於127的字元連在一起時，就表示一個漢字，前面的一個位元組（他稱之為高位元組）從0xA1用到0xF7，後面一個位元組（低位元組）從0xA1到0xFE，這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼裡，我們還把數學符號、羅馬希臘的字母、日文的假名們都編進去了，連在 ASCII 裡本來就有的數字、標點、字母都統統重新編了兩個位元組長的編碼，這就是常說的"全形"字元，而原來在127號以下的那些就叫"半形"字元了。

　　中國人民看到這樣很不錯，於是就把這種漢字方案叫做 "GB2312"。GB2312 是對 ASCII 的中文擴充套件。

　　但是中國的漢字太多了，我們很快就就發現有許多人的人名沒有辦法在這裡打出來，特別是某些很會麻煩別人的國家領導人。於是我們不得不繼續把 GB2312 沒有用到的碼位找出來老實不客氣地用上。

　　後來還是不夠用，於是乾脆不再要求低位元組一定是127號之後的內碼，只要第一個位元組是大於127就固定表示這是一個漢字的開始，不管後面跟的是不是擴充套件字符集裡的內容。結果擴充套件之後的編碼方案被稱為 GBK 標準，GBK 包括了 GB2312 的所有內容，同時又增加了近20000個新的漢字（包括繁體字）和符號。

　　後來少數民族也要用電腦了，於是我們再擴充套件，又加了幾千個新的少數民族的字，GBK 擴成了 GB18030。從此之後，中華民族的文化就可以在計算機時代中傳承了。

　　中國的程式設計師們看到這一系列漢字編碼的標準是好的，於是通稱他們叫做 "DBCS"（Double Byte Charecter Set 雙位元組字符集）。在DBCS系列標準裡，最大的特點是兩位元組長的漢字字元和一位元組長的英文字元並存於同一套編碼方案裡，因此他們寫的程式為了支援中文處理，必須要注意字串裡的每一個位元組的值，如果這個值是大於127的，那麼就認為一個雙位元組字符集裡的字元出現了。那時候凡是受過加持，會程式設計的計算機僧侶們都要每天念下面這個咒語數百遍：

　　"一個漢字算兩個英文字元！一個漢字算兩個英文字元……"

　　因為當時各個國家都像中國這樣搞出一套自己的編碼標準，結果互相之間誰也不懂誰的編碼，誰也不支援別人的編碼，連大陸和臺灣這樣只相隔了150海里，使用著同一種語言的兄弟地區，也分別採用了不同的 DBCS 編碼方案——當時的中國人想讓電腦顯示漢字，就必須裝上一個"漢字系統"，專門用來處理漢字的顯示、輸入的問題，但是那個臺灣的愚昧封建人士寫的算命程式就必須加裝另一套支援 BIG5 編碼的什麼"倚天漢字系統"才可以用，裝錯了字元系統，顯示就會亂了套！這怎麼辦？而且世界民族之林中還有那些一時用不上電腦的窮苦人民，他們的文字又怎麼辦？

　　真是計算機的巴比倫塔命題啊！

　　正在這時，大天使加百列及時出現了——一個叫 ISO （國際標誰化組織）的國際組織決定著手解決這個問題。他們採用的方法很簡單：廢了所有的地區性編碼方案，重新搞一個包括了地球上所有文化、所有字母和符號的編碼！他們打算叫它"Universal Multiple-Octet Coded Character Set"，簡稱 UCS, 俗稱 "UNICODE"。

　　UNICODE 開始制訂時，計算機的儲存器容量極大地發展了，空間再也不成為問題了。於是 ISO 就直接規定必須用兩個位元組，也就是16位來統一表示所有的字元，對於ascii裡的那些“半形”字元，UNICODE 包持其原編碼不變，只是將其長度由原來的8位擴充套件為16位，而其他文化和語言的字元則全部重新統一編碼。由於"半形"英文符號只需要用到低8位，所以其高8位永遠是0，因此這種大氣的方案在儲存英文文字時會多浪費一倍的空間。

　　這時候，從舊社會裡走過來的程式設計師開始發現一個奇怪的現象：他們的strlen函式靠不住了，一個漢字不再是相當於兩個字元了，而是一個！是的，從 UNICODE 開始，無論是半形的英文字母，還是全形的漢字，它們都是統一的"一個字元"！同時，也都是統一的"兩個位元組"，請注意"字元"和"位元組"兩個術語的不同，“位元組”是一個8位的物理存貯單元，而“字元”則是一個文化相關的符號。在UNICODE 中，一個字元就是兩個位元組。一個漢字算兩個英文字元的時代已經快過去了。

　　從前多種字符集存在時，那些做多語言軟體的公司遇上過很大麻煩，他們為了在不同的國家銷售同一套軟體，就不得不在區域化軟體時也加持那個雙位元組字符集咒語，不僅要處處小心不要搞錯，還要把軟體中的文字在不同的字符集中轉來轉去。UNICODE 對於他們來說是一個很好的一攬子解決方案，於是從 Windows NT 開始，MS 趁機把它們的作業系統改了一遍，把所有的核心程式碼都改成了用 UNICODE 方式工作的版本，從這時開始，WINDOWS 系統終於無需要加裝各種本土語言系統，就可以顯示全世界上所有文化的字元了。

　　但是，UNICODE 在制訂時沒有考慮與任何一種現有的編碼方案保持相容，這使得 GBK 與UNICODE 在漢字的內碼編排上完全是不一樣的，沒有一種簡單的算術方法可以把文字內容從UNICODE編碼和另一種編碼進行轉換，這種轉換必須通過查表來進行。

　　如前所述，UNICODE 是用兩個位元組來表示為一個字元，他總共可以組合出65535不同的字元，這大概已經可以覆蓋世界上所有文化的符號。如果還不夠也沒有關係，ISO已經準備了UCS-4方案，說簡單了就是四個位元組來表示一個字元，這樣我們就可以組合出21億個不同的字元出來（最高位有其他用途），這大概可以用到銀河聯邦成立那一天吧！

　　UNICODE 來到時，一起到來的還有計算機網路的興起，UNICODE 如何在網路上傳輸也是一個必須考慮的問題，於是面向傳輸的眾多 UTF（UCS Transfer Format）標準出現了，顧名思義，UTF8就是每次8個位傳輸資料，而UTF16就是每次16個位，只不過為了傳輸時的可靠性，從UNICODE到UTF時並不是直接的對應，而是要過一些演算法和規則來轉換。

　　受到過網路程式設計加持的計算機僧侶們都知道，在網路裡傳遞資訊時有一個很重要的問題，就是對於資料高低位的解讀方式，一些計算機是採用低位先發送的方法，例如我們PC機採用的 INTEL 架構，而另一些是採用高位先發送的方式，在網路中交換資料時，為了核對雙方對於高低位的認識是否是一致的，採用了一種很簡便的方法，就是在文字流的開始時向對方傳送一個標誌符——如果之後的文字是高位在位，那就傳送"FEFF"，反之，則傳送"FFFE"。不信你可以用二進位制方式開啟一個UTF-X格式的檔案，看看開頭兩個位元組是不是這兩個位元組？

　　講到這裡，我們再順便說說一個很著名的奇怪現象：當你在 windows 的記事本里新建一個檔案，輸入"聯通"兩個字之後，儲存，關閉，然後再次開啟，你會發現這兩個字已經消失了，代之的是幾個亂碼！呵呵，有人說這就是聯通之所以拼不過移動的原因。

　　其實這是因為GB2312編碼與UTF8編碼產生了編碼衝撞的原因。

　　從網上引來一段從UNICODE到UTF8的轉換規則：

　　Unicode

　　UTF-8

　　0000 - 007F

　　0xxxxxxx

　　0080 - 07FF

　　110xxxxx 10xxxxxx

　　0800 - FFFF

　　1110xxxx 10xxxxxx 10xxxxxx

　　例如"漢"字的Unicode編碼是6C49。6C49在0800-FFFF之間，所以要用3位元組模板：1110xxxx 10xxxxxx 10xxxxxx。將6C49寫成二進位制是：0110 1100 0100 1001，將這個位元流按三位元組模板的分段方法分為0110 110001 001001，依次代替模板中的x，得到：1110-0110 10-110001 10-001001，即E6 B1 89，這就是其UTF8的編碼。

　　而當你新建一個文字檔案時，記事本的編碼預設是ANSI, 如果你在ANSI的編碼輸入漢字，那麼他實際就是GB系列的編碼方式，在這種編碼下，"聯通"的內碼是：

　　c1 1100 0001

　　aa 1010 1010

　　cd 1100 1101

　　a8 1010 1000

　　注意到了嗎？第一二個位元組、第三四個位元組的起始部分的都是"110"和"10"，正好與UTF8規則裡的兩位元組模板是一致的，於是再次開啟記事本時，記事本就誤認為這是一個UTF8編碼的檔案，讓我們把第一個位元組的110和第二個位元組的10去掉，我們就得到了"00001 101010"，再把各位對齊，補上前導的0，就得到了"0000 0000 0110 1010"，不好意思，這是UNICODE的006A，也就是小寫的字母"j"，而之後的兩位元組用UTF8解碼之後是0368，這個字元什麼也不是。這就是隻有"聯通"兩個字的檔案沒有辦法在記事本里正常顯示的原因。

　　而如果你在"聯通"之後多輸入幾個字，其他的字的編碼不見得又恰好是110和10開始的位元組，這樣再次開啟時，記事本就不會堅持這是一個utf8編碼的檔案，而會用ANSI的方式解讀之，這時亂碼又不出現了。

　　好了，終於可以回答NICO的問題了，在資料庫裡，有n字首的字串型別就是UNICODE型別，這種型別中，固定用兩個位元組來表示一個字元，無論這個字元是漢字還是英文字母，或是別的麼。

 

　　如果你要測試"abc漢字"這個串的長度，在沒有n字首的資料型別裡，這個字串是7個字元的長度，因為一個漢字相當於兩個字元。而在有n字首的資料型別裡，同樣的測試串長度的函式將會告訴你是5個字元，因為一個漢字就是一個字元。

 

1. ASCII碼

我們知道，在計算機內部，所有的資訊最終都表示為一個二進位制的字串。每一個二進位制位（bit）有0和1兩種狀態，因此八個二進位制位就可以組合出256種狀態，這被稱為一個位元組（byte）。也就是說，一個位元組一共可以用來表示256種不同的狀態，每一個狀態對應一個符號，就是256個符號，從0000000到11111111。

上個世紀60年代，美國製定了一套字元編碼，對英語字元與二進位制位之間的關係，做了統一規定。這被稱為ASCII碼，一直沿用至今。

ASCII碼一共規定了128個字元的編碼，比如空格“SPACE”是32（二進位制00100000），大寫的字母A是65（二進位制01000001）。這128個符號（包括32個不能打印出來的控制符號），只佔用了一個位元組的後面7位，最前面的1位統一規定為0。

2、非ASCII編碼

英語用128個符號編碼就夠了，但是用來表示其他語言，128個符號是不夠的。比如，在法語中，字母上方有注音符號，它就無法用ASCII碼錶示。於是，一些歐洲國家就決定，利用位元組中閒置的最高位編入新的符號。比如，法語中的é的編碼為130（二進位制10000010）。這樣一來，這些歐洲國家使用的編碼體系，可以表示最多256個符號。

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

至於亞洲國家的文字，使用的符號就更多了，漢字就多達10萬左右。一個位元組只能表示256種符號，肯定是不夠的，就必須使用多個位元組表達一個符號。比如，簡體中文常見的編碼方式是GB2312，使用兩個位元組表示一個漢字，所以理論上最多可以表示256x256=65536個符號。

中文編碼的問題需要專文討論，這篇筆記不涉及。這裡只指出，雖然都是用多個位元組表示一個符號，但是GB類的漢字編碼與後文的Unicode和UTF-8是毫無關係的。

3.Unicode

正如上一節所說，世界上存在著多種編碼方式，同一個二進位制數字可以被解釋成不同的符號。因此，要想開啟一個文字檔案，就必須知道它的編碼方式，否則用錯誤的編碼方式解讀，就會出現亂碼。為什麼電子郵件常常出現亂碼？就是因為發信人和收信人使用的編碼方式不一樣。

可以想象，如果有一種編碼，將世界上所有的符號都納入其中。每一個符號都給予一個獨一無二的編碼，那麼亂碼問題就會消失。這就是Unicode，就像它的名字都表示的，這是一種所有符號的編碼。

Unicode當然是一個很大的集合，現在的規模可以容納100多萬個符號。每個符號的編碼都不一樣，比如，U+0639表示阿拉伯字母Ain，U+0041表示英語的大寫字母A，U+4E25表示漢字“嚴”。具體的符號對應表，可以查詢unicode.org，或者專門的漢字對應表。

4. Unicode的問題

需要注意的是，Unicode只是一個符號集，它只規定了符號的二進位制程式碼，卻沒有規定這個二進位制程式碼應該如何儲存。

比如，漢字“嚴”的unicode是十六進位制數4E25，轉換成二進位制數足足有15位（100111000100101），也就是說這個符號的表示至少需要2個位元組。表示其他更大的符號，可能需要3個位元組或者4個位元組，甚至更多。

這裡就有兩個嚴重的問題，第一個問題是，如何才能區別unicode和ascii？計算機怎麼知道三個位元組表示一個符號，而不是分別表示三個符號呢？第二個問題是，我們已經知道，英文字母只用一個位元組表示就夠了，如果unicode統一規定，每個符號用三個或四個位元組表示，那麼每個英文字母前都必然有二到三個位元組是0，這對於儲存來說是極大的浪費，文字檔案的大小會因此大出二三倍，這是無法接受的。

它們造成的結果是：1）出現了unicode的多種儲存方式，也就是說有許多種不同的二進位制格式，可以用來表示unicode。2）unicode在很長一段時間內無法推廣，直到網際網路的出現。

5.UTF-8

網際網路的普及，強烈要求出現一種統一的編碼方式。UTF-8就是在網際網路上使用最廣的一種unicode的實現方式。其他實現方式還包括UTF-16和UTF-32，不過在網際網路上基本不用。重複一遍，這裡的關係是，UTF-8是Unicode的實現方式之一。

UTF-8最大的一個特點，就是它是一種變長的編碼方式。它可以使用1~4個位元組表示一個符號，根據不同的符號而變化位元組長度。

UTF-8的編碼規則很簡單，只有二條：

1）對於單位元組的符號，位元組的第一位設為0，後面7位為這個符號的unicode碼。因此對於英語字母，UTF-8編碼和ASCII碼是相同的。

2）對於n位元組的符號（n>1），第一個位元組的前n位都設為1，第n+1位設為0，後面位元組的前兩位一律設為10。剩下的沒有提及的二進位制位，全部為這個符號的unicode碼。

下表總結了編碼規則，字母x表示可用編碼的位。

Unicode符號範圍 | UTF-8編碼方式
(十六進位制) | （二進位制）
--------------------+---------------------------------------------
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

下面，還是以漢字“嚴”為例，演示如何實現UTF-8編碼。

已知“嚴”的unicode是4E25（100111000100101），根據上表，可以發現4E25處在第三行的範圍內（0000 0800-0000 FFFF），因此“嚴”的UTF-8編碼需要三個位元組，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然後，從“嚴”的最後一個二進位制位開始，依次從後向前填入格式中的x，多出的位補0。這樣就得到了，“嚴”的UTF-8編碼是“11100100 10111000 10100101”，轉換成十六進位制就是E4B8A5。

6. Unicode與UTF-8之間的轉換

通過上一節的例子，可以看到“嚴”的Unicode碼是4E25，UTF-8編碼是E4B8A5，兩者是不一樣的。它們之間的轉換可以通過程式實現。

在Windows平臺下，有一個最簡單的轉化方法，就是使用內建的記事本小程式Notepad.exe。開啟檔案後，點選“檔案”選單中的“另存為”命令，會跳出一個對話方塊，在最底部有一個“編碼”的下拉條。

裡面有四個選項：ANSI，Unicode，Unicode big endian 和 UTF-8。

1）ANSI是預設的編碼方式。對於英文檔案是ASCII編碼，對於簡體中文檔案是GB2312編碼（只針對Windows簡體中文版，如果是繁體中文版會採用Big5碼）。

2）Unicode編碼指的是UCS-2編碼方式，即直接用兩個位元組存入字元的Unicode碼。這個選項用的little endian格式。

3）Unicode big endian編碼與上一個選項相對應。我在下一節會解釋little endian和big endian的涵義。

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

選擇完”編碼方式“後，點選”儲存“按鈕，檔案的編碼方式就立刻轉換好了。

7. Little endian和Big endian

上一節已經提到，Unicode碼可以採用UCS-2格式直接儲存。以漢字”嚴“為例，Unicode碼是4E25，需要用兩個位元組儲存，一個位元組是4E，另一個位元組是25。儲存的時候，4E在前，25在後，就是Big endian方式；25在前，4E在後，就是Little endian方式。

這兩個古怪的名稱來自英國作家斯威夫特的《格列佛遊記》。在該書中，小人國裡爆發了內戰，戰爭起因是人們爭論，吃雞蛋時究竟是從大頭(Big-Endian)敲開還是從小頭(Little-Endian)敲開。為了這件事情，前後爆發了六次戰爭，一個皇帝送了命，另一個皇帝丟了王位。

因此，第一個位元組在前，就是”大頭方式“（Big endian），第二個位元組在前就是”小頭方式“（Little endian）。

那麼很自然的，就會出現一個問題：計算機怎麼知道某一個檔案到底採用哪一種方式編碼？

Unicode規範中定義，每一個檔案的最前面分別加入一個表示編碼順序的字元，這個字元的名字叫做”零寬度非換行空格“（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。這正好是兩個位元組，而且FF比FE大1。

如果一個文字檔案的頭兩個位元組是FE FF，就表示該檔案採用大頭方式；如果頭兩個位元組是FF FE，就表示該檔案採用小頭方式。

8. 例項

下面，舉一個例項。

開啟”記事本“程式Notepad.exe，新建一個文字檔案，內容就是一個”嚴“字，依次採用ANSI，Unicode，Unicode big endian 和 UTF-8編碼方式儲存。

然後，用文字編輯軟體UltraEdit中的”十六進位制功能“，觀察該檔案的內部編碼方式。

1）ANSI：檔案的編碼就是兩個位元組“D1 CF”，這正是“嚴”的GB2312編碼，這也暗示GB2312是採用大頭方式儲存的。

2）Unicode：編碼是四個位元組“FF FE 25 4E”，其中“FF FE”表明是小頭方式儲存，真正的編碼是4E25。

3）Unicode big endian：編碼是四個位元組“FE FF 4E 25”，其中“FE FF”表明是大頭方式儲存。

4）UTF-8：編碼是六個位元組“EF BB BF E4 B8 A5”，前三個位元組“EF BB BF”表示這是UTF-8編碼，後三個“E4B8A5”就是“嚴”的具體編碼，它的儲存順序與編碼順序是一致的。

  

二、編碼轉換

/** 中文字串轉UTF-8與GBK碼示例 
             */
         public static void tttt() throws Exception {
        String old = "手機銀行";
        
        //中文轉換成UTF-8編碼（16進位制字串)
        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轉換成中文值======" + new String(utf8Decode, "utf-8"));//-------手機銀行
        
        
        //中文轉換成GBK碼（16進位制字串)
        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轉換成中文值======" + new String(gbkDecode, "gbk"));//----------手機銀行
        
        
        //16進位制字串轉換成中文
        byte[] bb = HexString2Bytes(gbkStr.toString());
        bb = HexString2Bytes("CAD6BBFAD2F8D0D0000000000000000000000000");
        byte[] cc = hexToByte("CAD6BBFAD2F8D0D0000000000000000000000000", 20);
        String aa = new String(bb, "gbk");
        System.out.println("aa====" + aa);
    }

/**
     * 把16進位制字串轉換成位元組陣列
     * @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;
    }

    /**
     * 把位元組陣列轉換成16進位制字串
     * @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();
    }

 

 參考來源：

http://blog.csdn.net/iefreer/article/details/4836844

http://bbs.csdn.net/topics/360164725

http://www.hackbase.com/tech/2009-03-16/51640_1.html

http://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.html

 

 

 

轉自：http://blog.csdn.net/lvxiangan/article/details/8151670

請問URI和URL有什麼區別？
URL是全球資源定位符的英文所寫，您平時上網時在IE瀏覽器中輸入的那個地址就是URL。比如：網易 http://www.163.com就是一個URL。
URI是Web上可用的每種資源 - HTML文件、影象、視訊片段、程式,由一個通過通用資源標誌符(Universal Resource Identifier, 簡稱"URI")進行定位。 
URL的格式由下列三部分組成: 
第一部分是協議(或稱為服務方式);  
第二部分是存有該資源的主機IP地址(有時也包括埠號);  
第三部分是主機資源的具體地址。

URI一般由三部分組成: 
訪問資源的命名機制。  
存放資源的主機名。  
資源自身的名稱，由路徑表示。

URI 是從虛擬根路徑開始的
URL是整個連結
如
URL http://zhidao.baidu.com/question/68016373.html  
URI 是/question/68016373.html

 

常用URL編碼表

%0A：  linefeed（換行），很多手機url編碼後會自動在句末新增%0A,後端會無法識別導致報錯，因此需要把它去掉。

%20： space（空格）

只有

字母：a -> z、A -> Z

數字：0 -> 9

特殊符號：$-_.+!*'(), 

以及某些保留字，

才可以不經過編碼直接用於 URL。

 

一、問題的由來

URL就是網址，只要上網，就一定會用到。

 

一般來說，URL只能使用英文字母、阿拉伯數字和某些標點符號，不能使用其他文字和符號。比如，世界上有英文字母的網址 “http://www.abc.com”，但是沒有希臘字母的網址“http://www.aβγ.com”（讀作阿爾法-貝塔-伽瑪.com）。這是 因為網路標準RFC 1738 做了硬性規定：

"...Only alphanumerics [0-9a-zA-Z], the special characters "$-_.+!*'()," [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL."

“只有字母和數字[0-9a-zA-Z]、一些特殊符號“$-_.+!*'(),”[不包括雙引號]、以及某些保留字，才可以不經過編碼直接用於 URL。”

這意味著，如果URL中有漢字，就必須編碼後使用。但是麻煩的是，RFC 1738沒有規定具體的編碼方法，而是交給應用程式（瀏覽器）自己決定。這導致“URL編碼”成為了一個混亂的領域。

下面就讓我們看看，“URL編碼”到底有多混亂。我會依次分析四種不同的情況，在每一種情況中，瀏覽器的URL編碼方法都不一樣。把它們的差異解釋 清楚之後，我再說如何用Javascript找到一個統一的編碼方法。

二、情況1：網址路徑中包含漢字

開啟IE（我用的是8.0版），輸入網址“http://zh.wikipedia.org/wiki/春節 ”。 注意，“春節”這兩個字此時是網址路徑的一部分。

檢視HTTP請求的頭資訊，會發現IE實際查詢的網址是“http://zh.wikipedia.org/wiki/%E6%98%A5%E8%8A%82 ”。 也就是說，IE自動將“春節”編碼成了“%E6%98%A5%E8%8A%82”。

我們知道，“春”和“節”的utf-8編碼分別是“E6 98 A5”和“E8 8A 82”，因此，“%E6%98%A5%E8%8A%82”就是按照順序，在每個位元組前加上%而得到的。（具體的轉碼方法，請參考我寫的《字元編碼筆記》 。）

在Firefox中測試，也得到了同樣的結果。所以，結論1就是，網址路徑的編碼，用的是utf-8編碼。

三、情況2：查詢字串包含漢字

在IE中輸入網址“http://www.baidu.com/s?wd=春節 ”。注意，“春節”這兩個字此時 屬於查詢字串，不屬於網址路徑，不要與情況1混淆。

檢視HTTP請求的頭資訊，會發現IE將“春節”轉化成了一個亂碼。

切換到十六進位制方式，才能清楚地看到，“春節”被轉成了“B4 BA BD DA”。

我們知道，“春”和“節”的GB2312編碼（我的作業系統“Windows XP”中文版的預設編碼）分別是“B4 BA”和“BD DA”。因此，IE實際上就是將查詢字串，以GB2312編碼的格式傳送出去。

Firefox的處理方法，略有不同。它傳送的HTTP Head是“wd=%B4%BA%BD%DA”。也就是說，同樣採用GB2312編碼，但是在每個位元組前加上了%。

所以，結論2就是，查詢字串的編碼，用的是作業系統的預設編碼。

四、情況3：Get方法生成的URL包含漢字

前面說的是直接輸入網址的情況，但是更常見的情況是，在已開啟的網頁上，直接用Get或Post方法發出HTTP請求。

根據臺灣中興大學呂瑞麟老師的試驗 ，這時的編碼方法由網頁的編碼決定，也就是由HTML原始碼中字符集的設定決定。

　　<meta http-equiv="Content-Type" content="text/html;charset=xxxx">

如果上面這一行最後的charset是UTF-8，則URL就以UTF-8編碼；如果是GB2312，URL就以GB2312編碼。

舉例來說，百度是GB2312編碼，Google是UTF-8編碼。因此，從它們的搜尋框中搜索同一個詞“春節”，生成的查詢字串是不一樣的。

百度生成的是%B4%BA%BD%DA，這是GB2312編碼。

Google生成的是%E6%98%A5%E8%8A%82，這是UTF-8編碼。

所以，結論3就是，GET和POST方法的編碼，用的是網頁的編碼。

五、情況4：Ajax呼叫的URL包含漢字

前面三種情況都是由瀏覽器發出HTTP請求，最後一種情況則是由Javascript生成HTTP請求，也就是Ajax呼叫。還是根據呂瑞麟老師的 文章，在這種情況下，IE和Firefox的處理方式完全不一樣。

舉例來說，有這樣兩行程式碼：

　　url = url + "?q=" +document.myform.elements[0].value; // 假定使用者在表單中提交的值是“春節”這兩個字

　　http_request.open('GET', url, true);

那麼，無論網頁使用什麼字符集，IE傳送給伺服器的總是“q=%B4%BA%BD%DA”，而Firefox傳送給伺服器的總是“q=%E6%98 %A5%E8%8A%82”。也就是說，在Ajax呼叫中，IE總是採用GB2312編碼（作業系統的預設編碼），而Firefox總是 採用utf-8編碼。這就是我們的結論4。

六、Javascript函式：escape()

好了，到此為止，四種情況都說完了。

假定前面你都看懂了，那麼此時你應該會感到很頭痛。因為，實在太混亂了。不同的作業系統、不同的瀏覽器、不同的網頁字符集，將導致完全不同的編碼結 果。如果程式設計師要把每一種結果都考慮進去，是不是太恐怖了？有沒有辦法，能夠保證客戶端只用一種編碼方法向伺服器發出請求？

回答是有的，就是使用Javascript先對URL編碼，然後再向伺服器提交，不要給瀏覽器插手的機會。因為Javascript的輸出總是一致 的，所以就保證了伺服器得到的資料是格式統一的。

Javascript語言用於編碼的函式，一共有三個，最古老的一個就是escape()。雖然這個函式現在已經不提倡使用了，但是由於歷史原因， 很多地方還在使用它，所以有必要先從它講起。

實際上，escape()不能直接用於URL編碼，它的真正作用是返回一個字元的Unicode編碼值。比如“春節”的返回結果 是%u6625%u8282，也就是說在Unicode字符集中，“春”是第6625個（十六進位制）字元，“節”是第8282個（十六進位制）字元。

它的具體規則是，除了ASCII字母、數字、標點符號“@ * _ + - . /”以外，對其他所有字元進行編碼。在/u0000到/u00ff之間的符號被轉成%xx的形式，其餘符號被轉成%uxxxx的形式。對應的解碼函式是 unescape()。

所以，“Hello World”的escape()編碼就是“Hello%20World”。因為空格的Unicode值是20（十六進位制）。

還有兩個地方需要注意。

首先，無論網頁的原始編碼是什麼，一旦被Javascript編碼，就都變為unicode字元。也就是說，Javascipt函式的輸入和輸出， 預設都是Unicode字元。這一點對下面兩個函式也適用。

其次，escape()不對“+”編碼。但是我們知道，網頁在提交表單的時候，如果有空格，則會被轉化為+字元。伺服器處理資料的時候，會把+號處 理成空格。所以，使用的時候要小心。

七、Javascript函式：encodeURI()

encodeURI()是Javascript中真正用來對URL編碼的函式。

它著眼於對整個URL進行編碼，因此除了常見的符號以外，對其他一些在網址中有特殊含義的符號“; / ? : @ & = + $ , #”，也不進行編碼。編碼後，它輸出符號的utf-8形式，並且在每個位元組前加上%。

它對應的解碼函式是decodeURI()。

需要注意的是，它不對單引號'編碼。

八、Javascript函式：encodeURIComponent()

最後一個Javascript編碼函式是encodeURIComponent()。與encodeURI()的區別是，它用於對URL的組成部分 進行個別編碼，而不用於對整個URL進行編碼。

因此，“; / ? : @ & = + $ , #”，這些在encodeURI()中不被編碼的符號，在encodeURIComponent()中統統會被編碼。至於具體的編碼方法，兩者是一樣。

它對應的解碼函式是decodeURIComponent()。

PS1 ：

網頁裡的form編碼其實不完全取決於網頁編碼，form標記中有一個accept-charset屬性，在非ie瀏覽器種，如果將其賦值(比如 accept-charset="UTF-8")，則表單會按照這個值表示的編碼方式進行提交。
在ie下，我的相容解決辦法是：
form1.onsubmit=function(){
document.charset=this.getAttribute('accept-charset');
}