關(guān)鍵字 ：Java 中文 Unicode 編碼轉(zhuǎn)換
一、Appetite
在進(jìn)行詳細(xì)的編碼轉(zhuǎn)換原理闡述之前，我們要作兩件事情：
1。首先檢查操作系統(tǒng)用的語(yǔ)言。以Windows 2003 Server為例，可以在“控制面板”中的“區(qū)域和語(yǔ)言設(shè)置”中選擇你的國(guó)家、語(yǔ)言，還有你的操作系統(tǒng)必須支持的語(yǔ)言。國(guó)籍＆語(yǔ)言的設(shè)定會(huì)影響JRE的判斷情況。也許適當(dāng)?shù)脑O(shè)定能夠幫你解決不少Java語(yǔ)言編碼的問(wèn)題。
2。更新新版本的JDK。因?yàn)樾掳姹镜腏DK往往能夠更好的支持新的特性，達(dá)到良好的語(yǔ)言遲遲效果。例如JDK5.0就已經(jīng)更形了JDK1.2中的很多語(yǔ)言問(wèn)題。
二、正餐
2.1 Unicode編碼
2.1.1 Unicode——Java默認(rèn)的編碼
毫無(wú)疑問(wèn)，Unicode作為容納全球所有語(yǔ)言字符的超級(jí)字符集，是Java的首選字符集。Unicode使用兩個(gè)字節(jié)作為編碼方式，總共容納有6萬(wàn)多個(gè)字符。因?yàn)槭褂?6位進(jìn)行字符編碼，所以也稱為UTF－16。然而即使這樣，UTF－16也并不能充分囊括所有全世界正在使用或者曾經(jīng)使用的字符，所以必須對(duì)其進(jìn)行擴(kuò)充。于是后來(lái)的Unicode版本已經(jīng)擴(kuò)充到了1,112,064個(gè)字符，這種規(guī)模已經(jīng)相當(dāng)大了。但是這樣仍然不能滿足Unicode在世界上的需求，所以必須進(jìn)行必要的擴(kuò)充。相比預(yù)Unicode1.0，后來(lái)的2.0版本已經(jīng)支持?jǐn)U展字符了，但是并沒(méi)有真正的加入擴(kuò)展字符集，這種狀況一直持續(xù)到了Unicode3.1版，才第一次在Unicode中引入了擴(kuò)展字符集。但是Unicode的發(fā)展腳步并沒(méi)有停滯，后來(lái)出現(xiàn)了Unicode4.0 標(biāo)準(zhǔn)，而這也正好是現(xiàn)在Java5.0版所必須而且已經(jīng)提供支持的字符集。
顯然“對(duì)增補(bǔ)字符的支持也可能會(huì)成為東亞市場(chǎng)的一個(gè)普遍商業(yè)要求。政府應(yīng)用程序會(huì)需要這些增補(bǔ)字符，以正確表示一些包含罕見(jiàn)中文字符的姓名。出版應(yīng)用程序可能會(huì)需要這些增補(bǔ)字符，以表示所有的古代字符和變體字符。中國(guó)政府要求支持 GB18030（一種對(duì)整個(gè) Unicode 字符集進(jìn)行編碼的字符編碼標(biāo)準(zhǔn)），因此，如果是 Unicode 3.1 版或更新版本，則將包括增補(bǔ)字符。臺(tái)灣標(biāo)準(zhǔn) CNS-11643 包含的許多字符在 Unicode 3.1 中列為增補(bǔ)字符。香港政府定義了一種針對(duì)粵語(yǔ)的字符集，其中的一些字符是 Unicode 中的增補(bǔ)字符。最后，日本的一些供應(yīng)商正計(jì)劃利用增補(bǔ)字符空間中大量的專用空間收入 50,000 多個(gè)日文漢字字符變體，以便從其專有系統(tǒng)遷移至基于 Java 平臺(tái)的解決方案。
因此，Java 平臺(tái)不僅需要支持增補(bǔ)字符，而且必須使應(yīng)用程序能夠方便地做到這一點(diǎn)。由于增補(bǔ)字符打破了 Java 編程語(yǔ)言的基礎(chǔ)設(shè)計(jì)構(gòu)想，而且可能要求對(duì)編程模型進(jìn)行根本性的修改，因此，Java Community Process 召集了一個(gè)專家組，以期找到一個(gè)適當(dāng)?shù)慕鉀Q方案。該小組被稱為 JSR-204 專家組，使用 Unicode 增補(bǔ)字符支持的 Java 技術(shù)規(guī)范請(qǐng)求的編號(hào)。從技術(shù)上來(lái)說(shuō)，該專家組的決定僅適用于 J2SE 平臺(tái)，但是由于 Java 2 平臺(tái)企業(yè)版 (J2EE) 處于 J2SE 平臺(tái)的最上層，因此它可以直接受益，我們期望 Java 2 平臺(tái)袖珍版 (J2ME) 的配置也采用相同的設(shè)計(jì)方法。”
UTF-16的編碼方式：
UTF-16 使用一個(gè)或兩個(gè)未分配的 16 位代碼單元的序列對(duì) Unicode 代碼點(diǎn)進(jìn)行編碼。值 0x0000 至 0xFFFF 編碼為一個(gè)相同值的 16 位單元。增補(bǔ)字符編碼為兩個(gè)代碼單元，第一個(gè)單元來(lái)自于高代理范圍（0xD800 至 0xDBFF），第二個(gè)單元來(lái)自于低代理范圍（U+DC00 至 U+DFFF）。這在概念上可能看起來(lái)類似于多字節(jié)編碼，但是其中有一個(gè)重要區(qū)別：值 0xD800 至 0xDFFF 保留用于 UTF-16；沒(méi)有這些值分配字符作為代碼點(diǎn)。這意味著，對(duì)于一個(gè)字符串中的每個(gè)單獨(dú)的代碼單元，軟件可以識(shí)別是否該代碼單元表示某個(gè)單單元字符，或者是否該代碼單元是某個(gè)雙單元字符的第一個(gè)或第二單元。這相當(dāng)于某些傳統(tǒng)的多字節(jié)字符編碼來(lái)說(shuō)是一個(gè)顯著的改進(jìn)，在傳統(tǒng)的多字節(jié)字符編碼中，字節(jié)值 0x41 既可能表示字母“A”，也可能是一個(gè)雙字節(jié)字符的第二個(gè)字節(jié)。
2.1.2 節(jié)省空間的UTF-8
“如果我只能吃一塊巧克力，我絕對(duì)不會(huì)買上一箱子的巧克力。”
是的，很多時(shí)候，特別是我們?cè)谔幚沓绦虻臅r(shí)候，所使用的并非是所有的Unicode字符，而僅僅是他們其中很小的一個(gè)部分，確切的說(shuō)，這個(gè)部分不會(huì)比 ASCII多上多少。但是因?yàn)槭褂肬TF－16，卻不得不為此付出很多的存儲(chǔ)空間來(lái)存儲(chǔ)這些字符，這是一種可恥的浪費(fèi)。因此，為了便于節(jié)省空間，無(wú)論是在存儲(chǔ)或者傳輸過(guò)程中，如果你只使用到了英文或者拉丁文，那么只需要8位來(lái)表示字符就足夠了。這就是UTF-8的設(shè)計(jì)思想。但是，如果是在漢字或者亞洲語(yǔ)言使用頻率很高的地方，UTF-16依然將是首選。
但是值得注意的是，因?yàn)閁nicode本身一直在進(jìn)行版本更新，UTF-8當(dāng)然也并非一成不變。對(duì)于經(jīng)修改的過(guò)得UTF-8編碼，在某些Java API的調(diào)用中會(huì)出現(xiàn)種種問(wèn)題，特別是要注意在開(kāi)發(fā)包含增補(bǔ)字符的文本與UTF-8進(jìn)行轉(zhuǎn)換的時(shí)候，可能會(huì)出現(xiàn)嚴(yán)重錯(cuò)誤。
雖然Java本身對(duì)官方修訂的UTF-8很熟悉，但是因?yàn)镴ava內(nèi)部含有一套使用規(guī)范編碼的機(jī)制，因此實(shí)際上，Java在使用UTF-8的時(shí)候，就并非使用的是Unicode的UTF-8，而是一種叫做“Java modified UTF-8”（經(jīng) Java 修訂的 UTF-8）或（錯(cuò)誤地）直接稱為“UTF-8”。而在J2SE5.0種，這種編碼被統(tǒng)稱為“modified UTF-8”（經(jīng)修訂的 UTF-8）。
“經(jīng)修訂的 UTF-8 和標(biāo)準(zhǔn) UTF-8 之間之所以不兼容，其原因有兩點(diǎn)。其一，經(jīng)修訂的 UTF-8 將字符 U+0000 表示為雙字節(jié)序列 0xC0 0x80，而標(biāo)準(zhǔn) UTF-8 使用單字節(jié)值 0x0。其二，經(jīng)修訂的 UTF-8 通過(guò)對(duì)其 UTF-16 表示法的兩個(gè)代理代碼單元單獨(dú)進(jìn)行編碼表示增補(bǔ)字符 。每個(gè)代理代碼單元由三個(gè)字節(jié)來(lái)表示，共有六個(gè)字節(jié)。而標(biāo)準(zhǔn) UTF-8 使用單個(gè)四字節(jié)序列表示整個(gè)字符。
Java 虛擬機(jī)及其附帶的接口（如 Java 本機(jī)接口、多種工具接口或 Java 類文件）在
java.io.DataInput
和
DataOutput
接口和類中使用經(jīng)修訂的 UTF-8 實(shí)現(xiàn)或使用這些接口和類 ，并進(jìn)行序列化。Java 本機(jī)接口提供與經(jīng)修訂的 UTF-8 之間進(jìn)行轉(zhuǎn)換的例程。而標(biāo)準(zhǔn) UTF-8 由
String
類、
java.io.InputStreamReader
和
OutputStreamWriter
類、
java.nio.charset
設(shè)施 (facility) 以及許多其上層的 API 提供支持。
由于經(jīng)修訂的 UTF-8 與標(biāo)準(zhǔn)的 UTF-8 不兼容，因此切勿同時(shí)使用這兩種版本的編碼。經(jīng)修訂的 UTF-8 只能與上述的 Java 接口配合使用。在任何其他情況下，尤其對(duì)于可能來(lái)自非基于 Java 平臺(tái)的軟件的或可能通過(guò)其編譯的數(shù)據(jù)流，必須使用標(biāo)準(zhǔn)的 UTF-8。需要使用標(biāo)準(zhǔn)的 UTF-8 時(shí)，則不能使用 Java 本機(jī)接口例程與經(jīng)修訂的 UTF-8 進(jìn)行轉(zhuǎn)換。”
UTF-8的編碼方式：
UTF-8 使用一至四個(gè)字節(jié)的序列對(duì)編碼 Unicode 代碼點(diǎn)進(jìn)行編碼。U+0000 至 U+007F 使用一個(gè)字節(jié)編碼，U+0080 至 U+07FF 使用兩個(gè)字節(jié)，U+0800 至 U+FFFF 使用三個(gè)字節(jié)，而 U+10000 至 U+10FFFF 使用四個(gè)字節(jié)。UTF-8 設(shè)計(jì)原理為：字節(jié)值 0x00 至 0x7F 始終表示代碼點(diǎn) U+0000 至 U+007F（Basic Latin 字符子集，它對(duì)應(yīng) ASCII 字符集）。這些字節(jié)值永遠(yuǎn)不會(huì)表示其他代碼點(diǎn)，這一特性使 UTF-8 可以很方便地在軟件中將特殊的含義賦予某些 ASCII 字符。
2.1.3 同胞兄弟——UTF32
如果要問(wèn)在Unicode家族誰(shuí)的肚量最大，毫無(wú)疑問(wèn)的是UTF-32。因?yàn)椴捎?2位編碼方式，所以會(huì)使得他的容量特別大！因?yàn)闀?huì)有2的32次方個(gè)字符！同樣的，會(huì)帶來(lái)相應(yīng)的問(wèn)題，就是UTF-32的空間浪費(fèi)的也比較嚴(yán)重。所以，比般情況下很少使用這種編碼。
UTF-32的編碼方式：
UTF-32 即將每一個(gè) Unicode 代碼點(diǎn)表示為相同值的 32 位整數(shù)。很明顯，它是內(nèi)部處理最方便的表達(dá)方式，但是，如果作為一般字符串表達(dá)方式，則要消耗更多的內(nèi)存。
2.1.4 三種編碼方式的比較
| Unicode 代碼點(diǎn) | U+0041 | U+00DF | U+6771 | U+10400 | ||||||||||
| 表示字形 | ||||||||||||||
| UTF-32 代碼單元 |
|
|
|
|
||||||||||
| UTF-16 代碼單元 |
|
|
|
|
||||||||||
| UTF-8 代碼單元 |
|
|
|
|
關(guān)于 Unicode 的編碼，參見(jiàn)“The Unicode Standard, Version 3.0”一書(shū)（Addison-Wesley 出版）。
關(guān)于 UTF-8 編碼，參見(jiàn)“Java I/O”一書(shū)的 399 頁(yè)（O'Reilly 出版）。
關(guān)于 Java Class File 的格式與 Constant Pool，參見(jiàn)“Java Virtual Machine”一書(shū)（O'Reilly出版）。
?
如果想要知道你的系統(tǒng)到底使用什么樣的字符集與字符打交道，可以使用如下代碼片斷得到字符集名稱：
|
String enc = System.getProperty"file.encoding");
System.out.println(enc ); |
可能會(huì)得到下列字符集的名稱：
GB2313：這是簡(jiǎn)體中文的標(biāo)準(zhǔn)。
GB18083：這是中文的擴(kuò)展字符集。
HZ：同樣是一種中文標(biāo)準(zhǔn)。
Big5：這是繁體中文標(biāo)準(zhǔn)。
CNS11643：臺(tái)灣的官方標(biāo)準(zhǔn)繁體中文編碼。
Cp937：繁體中文加上 6204 個(gè)使用者自定的字符
Cp948：繁體中文版 IBM OS/2 用的編碼方式。
Cp964：繁體中文版 IBM AIX 用的編碼方式。
EUC_TW：臺(tái)灣的加強(qiáng)版 Unicode。
ISO2022CN：編碼中文的一套標(biāo)準(zhǔn)。
ISO2022CN_CNS：編碼中文的一套標(biāo)準(zhǔn)，繁體版，襲自 CNS11643。
MS950 或 Cp950：ASCII + Big5，用于臺(tái)灣和香港的繁體中文 MS Windows操作系統(tǒng)。
2.2.2 問(wèn)題來(lái)源
在Javac編譯期間，也會(huì)先從OS中取得現(xiàn)在使用的字符集，此處設(shè)為A，之后把送入的字符串轉(zhuǎn)化為Unicode編碼，在編譯之后再?gòu)腢nicode轉(zhuǎn)化為A型字符集。因此：
- 當(dāng)你的操作系統(tǒng)國(guó)際設(shè)定錯(cuò)誤，編譯時(shí)就會(huì)產(chǎn)出錯(cuò)誤的字符集編碼。
- 一些比較lj的編譯器會(huì)按照預(yù)先設(shè)定的字符集，而非OS所使用的字符集進(jìn)行編碼。
- 原是文件存盤時(shí)使用的字符集與編譯器所使用的字符集無(wú)法匹配也會(huì)產(chǎn)生錯(cuò)誤。
對(duì)于1和2，很好理解。對(duì)于3，例如我們使用的OS時(shí)GB2312，但是存盤時(shí)使用的編碼字符集時(shí)UTF-8，這樣java編譯器編譯文件的時(shí)候，就把UTF－8字符集當(dāng)成GB2312字符集來(lái)處理，這樣當(dāng)然會(huì)出錯(cuò)。
可以使用一下代碼片斷來(lái)以制定的編碼方式編譯Java文件。
public OutputStreamWriter(OutputStream out, String encoding) throws UnsupportedEncodingException;
-
如果你不能確定你的數(shù)據(jù)來(lái)源或者流向，那么最好不使用Reader和Writer，因?yàn)檫@樣可能造成不必要的信息損失。與其這樣，不如保持其二進(jìn)制編碼的完整性，留作以后進(jìn)一步處理。
-
有時(shí)候，Reader和Writer之間進(jìn)行通信的時(shí)候也可能出現(xiàn)編碼錯(cuò)誤，原因在于他們之間直接或者間接的使用到了I/O流，這樣就可能導(dǎo)致編碼轉(zhuǎn)換時(shí)出現(xiàn)不統(tǒng)一的情況。
2.3.2 字符串與字節(jié)數(shù)組
Java的String類提供了非常豐富的功能借助與此，我們也能達(dá)到編碼轉(zhuǎn)換的功能。
常用的String構(gòu)造函數(shù)如下：
String(byte[] bytes, int offset, int length, String charset);
String(byte[] bytes, String charset);
以上方法可以通過(guò)byte數(shù)組創(chuàng)建指定字符集的字符串，而下面的方法：
byte[] getBytes(String charset)；
則可以將String轉(zhuǎn)化為指定字符集的byte數(shù)組。
此外，還可以通過(guò)ByteArrayInputStream 或 ByteArrayOutputStream 串接到 InputStreamReader 或 OutputStreamWriter，來(lái)達(dá)到轉(zhuǎn)碼的目的。
2.4 其他問(wèn)題和解決辦法
然而Java本身涉及到編碼的問(wèn)題不止這些。曾經(jīng)有位朋友編寫一個(gè)可視花的zip應(yīng)用程序。非常不幸的是，由于Java 本身的編碼問(wèn)題，使得他的程序在存儲(chǔ)文件時(shí)，如果文件名是含有中文的，那么存儲(chǔ)后的文件名不能夠正確顯示。這個(gè)問(wèn)題困擾了他很久，雖然使用了本文中所提到過(guò)的方法，但是依然不能夠解決問(wèn)題。無(wú)奈，在網(wǎng)絡(luò)上查找了相關(guān)資料，發(fā)現(xiàn)如果不用java自己的zip包而改用Apache的zip包問(wèn)題能夠得到解決。
這就提示我們說(shuō)，有的時(shí)候，當(dāng)你面臨Java的編碼問(wèn)題時(shí)，不妨利用第三方的工具包嘗試解決往往能夠收到不錯(cuò)的效果。
三 總結(jié)
綜上，本文討論的Java字符編碼問(wèn)題的來(lái)龍去脈，并且給出了相應(yīng)的解決方法。相信憑借著對(duì)問(wèn)題根源的了解，Java的字符編碼問(wèn)題一定能夠在實(shí)際中得到解決。
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號(hào)聯(lián)系： 360901061
您的支持是博主寫作最大的動(dòng)力，如果您喜歡我的文章，感覺(jué)我的文章對(duì)您有幫助，請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點(diǎn)擊下面給點(diǎn)支持吧，站長(zhǎng)非常感激您！手機(jī)微信長(zhǎng)按不能支付解決辦法：請(qǐng)將微信支付二維碼保存到相冊(cè)，切換到微信，然后點(diǎn)擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對(duì)您有幫助就好】元
