WEB開發中的JAVA字元編碼經驗總結

一、概要　　在JAVA應用程式特別是基於WEB的程式中，經常遇到字元的編碼問題。為了防止出現亂碼，首先需要瞭解JAVA是如何處理字元的，這樣就可以有目的地在輸入/輸出環節中增加必要的轉碼。其次，由於各種伺服器有不同的處理方式，還需要多做實驗，確保使用中不出現亂碼。二、基本概念 2．1 JAVA中字元的表達　　JAVA中有char、byte、String這幾個概念。char 指的是一個UNICODE字元，為16位的整數。byte 是位元組，字串在網路傳輸或儲存前需要轉換為byte數組。在從網路接收或從存放裝置讀取後需要將byte數群組轉換成String。String是字串，可以看成是由char組成的數組。String 和 char 為記憶體形式，byte是網路傳輸或儲存的序列化形式。舉例：英 String ying = “英”; char ying = ying.charAt(0); String yingHex = Integer.toHexString(ying); 82 F1 byte yingGBBytes = ying.getBytes(“GBK”); GB編碼的位元組數值 D3 A2 2．2 編碼方式的簡介　　String序列化成byte數組或還原序列化時需要選擇正確的編碼方式。如果編碼方式不正確，就會得到一些0x3F的值。常用的字元編碼方式有ISO8859_1、GB2312、GBK、UTF-8/UTF-16/UTF-32。 ISO8859_1用來編碼拉丁文，它由單位元組（0－255）組成。　　GB2312、GBK用來編碼簡體中文，它有單位元組和雙位元組混合組成。最高位為1的位元組和下一個位元組構成一個漢字，最高位為0的位元組是ASCII碼。　　UTF-8/UTF-16/UTF-32是國際標準UNICODE的編碼方式。 用得最多的是UTF-8，主要是因為它在對拉丁文編碼時節約空間。 UNICODE值 UTF-8編碼 U-00000000 - U-0000007F: 0xxxxxxx U-00000080 - U-000007FF: 110xxxxx 10xxxxxx U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 三、J2SE中相關的函數 String str =”英”; //取得GB2312編碼的位元組 byte[] bytesGB2312 = str.getBytes(“GB2312”); //取得平台預設編碼的位元組(solaris為ISO8859_1,windows為GB2312) byte[] bytesDefault = str.getBytes(); //用指定的編碼將位元組轉換成字串 String newStrGB = new String(bytesGB2312, “GB2312”); //用平台預設的編碼將位元組轉換成字串(solaris為ISO8859_1,windows為GB2312) String newStrDefault = new String(bytesDefault); //用指定的編碼從位元組流裡面讀取字元 InputStream in = xxx; InputStreamReader reader = InputStreamReader( in, “GB2312”); char aChar = reader.read(); 四、JSP、資料庫的編碼 4．1 JSP中的編碼 (1) 靜態聲明: CHARSET有兩個作用： JSP檔案的編碼方式：在讀取JSP檔案、產生JAVA類時，源JSP檔案中漢字的編碼 JSP輸出資料流的編碼方式：在執行JSP時，往response流裡面寫入資料的編碼方式 (2) 動態改變:在往response流裡面寫資料前可以調用response.setContentType()，設定正確的編碼類別型。 (3) 在TOMCAT中，由Request.getParameter() 得到的參數，編碼方式都是ISO8859_1。所以如果在瀏覽器輸入框內輸入一個漢字“英”，在伺服器端就得到一個ISO8859_1編碼的（0x00,0xD3,0x00,0xA2）。所以通常在接收參數時轉碼： String wrongStr = response.getParameter(“name”); String correctStr = new String(wrongStr.getBytes(“ISO8859_1”),”GB2312”); 在最新的SERVLET規範裡面，也可以在擷取參數之前執行如下代碼： request.setCharacterEncoding(“GB2312”); 4．2 資料庫的編碼 (1) 資料庫使用UTF-16 如果String中是UNICODE字元，寫入讀出時不需要轉碼 (2) 資料庫使用ISO8859_1 如果String中是UNICODE字元，寫入讀出時需要轉碼寫入：String newStr = new String(oldStr.getByte(“GB2312”), “ISO8859_1”); 讀出：String newStr = new String(oldStr.getByte(“ISO8859_1”),”GB2312”); 五、源檔案的編碼 5．1 資源檔資源檔的編碼方式和編輯平台相關。在WINDOWS平台下編寫的資源檔，以GB2312方式編碼。在編譯時間需要轉碼，以確保在各個平台上的正確性： native2ascii –encoding GB2312 source.properties 這樣從資源檔中讀出的就是正確的UNICODE字串。 5．2 源檔案源檔案的編碼方式和編輯平台相關。在WINDOWS平台下開發的源檔案，以GB2312方式編碼。在編譯的時候，需要指定源檔案的編碼方式： javac –encoding GB2312 JAVA編譯後產生的位元組檔案的編碼為UTF-8。 ①最新版TOMCAT4.1.18支援request.setCharacterEncoding(String enc) ②資源檔轉碼成company.name=/u82f1/u65af/u514b ③如果資料庫使用utf-16則不需要這部分轉碼 ④頁面上應有轉碼ⅰ: String s = new String (request.getParameter(“name”).getBytes(“ISO8859_1”),”GB2312”); 轉碼ⅱ: String s = new String(name.getBytes(“GB2312”),”ISO8859_1”); 轉碼ⅲ: String s = new String(name.getBytes(“ISO8859_1”),” GB2312”);