Java在中文環境中亂碼無處不在,而且出現的時間和位置也包涵廣泛,具體的解決方法也是千奇百怪。
但是如果能理清其中的脈絡,理解字符處 理的過程,對于解決問題很有指導意義,不至于解決了問題也不知道為什么。
其實,原因不外乎出在String輸入時和輸出時。
首先,Java中的任何String都是以UNICODE格式存在的。
很多人因為在GBK環境中使用String,會誤以為String是GBK格式,實際上Java的String類中并沒有存儲CharSet信息的字段, 所有String中的字符只會以UNICODE的2字節形式存在。
String在構造時會逐一把字符按指定編碼(默認值為系統編碼GBK),轉換為UNICODE字符,存入一個Char(無符號16位)數組中。
如:
new String(bytes,"gbk");
并不是說,生成一個GBK編碼的字符串,而是按GBK逐一辨認字節數組bytes中的字符轉化為UNICODE。
假設,bytes本是按GB編碼的,構造方法在發現一個最高位為0的byte就作為ascii字符處理,最高位為1就和后面的一個byte合成中文字符, 再轉換編碼。
可以看出,在這個過程中,編碼選擇錯誤就會導致程序按錯誤方法辨認bytes,亂碼就出現了。
在這里產生的亂碼,很多時候還可以通過.getByte()方法修復,還沒有后面的嚴重。
如:
"中".getBytes("iso-8859-1");
因為iso-8859-1中沒有中文,所以"中"的值被替換成63,顯示'?',無法判斷以前是什么值。
所以如下String將被破壞掉:
new String("中文".getBytes("iso-8859-1"),"iso-8859-1");
如果目標編碼方式支持中文,就不會損壞String:
new String("中文".getBytes("utf-8"),"utf-8");
Java在顯示字符時,還需要進行一次轉換,把UNICODE字符轉換成用于顯示的字符編碼形式。
很多時候,這個過程是自動的,會按系統的默認編碼(一般是GBK)轉換String。
如果和頁面編碼不一樣,就會出現亂碼,雖然在Java的程序中只有一種編碼,輸出卻可以有不同的編碼。
有時候,我們需要用 iso-8859-1格式分解String的中文,以便在不支持中文的系統中存儲:
new String("中文".getBytes("GBK"),"iso-8859-1");
先通過GBK等支持中文的編碼方式分解為byte數組,再做為iso-8859-1字符組成字符串,就避免了被替換為Char(63)。
=========================================================================
示例程序
public static void main(String[] args) { String str = "中國"; printBytes("中國的UNICODE編碼：", str.getBytes(Charset.forName("unicode"))); printBytes("中國的GBK編碼：", str.getBytes(Charset.forName("GBK"))); printBytes("中國的UTF-8編碼：", str.getBytes(Charset.forName("UTF-8"))); } public static void printBytes(String title, byte[] data) { System.out.println(title); for (byte b : data) { System.out.print("0x" + toHexString(b) + " "); } System.out.println(); } public static String toHexString(byte value) { String tmp = Integer.toHexString(value & 0xFF); if (tmp.length() == 1) { tmp = "0" + tmp; } return tmp.toUpperCase(); } |
上例的輸出結果為：
中國的UNICODE編碼：
0xFE 0xFF 0x4E 0x2D 0x56 0xFD
中國的GBK編碼：
0xD6 0xD0 0xB9 0xFA
中國的UTF-8編碼：
0xE4 0xB8 0xAD 0xE5 0x9B 0xBD