編碼歷史與區別

---恢復內容開始---

 一直對字符的各類編碼方式懵懵懂懂，什麼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。

二、非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」就是「嚴」的具體編碼，它的存儲順序與編碼順序是一致的。

  

2、編碼轉換

         /** 中文字符串轉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();
}

---恢復內容結束---

 一直對字符的各類編碼方式懵懵懂懂，什麼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。

二、非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」就是「嚴」的具體編碼，它的存儲順序與編碼順序是一致的。

  

2、編碼轉換

         /** 中文字符串轉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();
}