這個今天早上提供的一個生產問題。大體是說，改資料的時候，有個客戶的名字有生僻字，叫”劉”,保存之后就亂碼了，變成”劉?”
亂碼需要確認數據傳輸過程中編碼方式。
數據是通過jQuery的Ajax過來的，并且沒有提前處理數據(只有組裝了一個js對象)，所以是采用encodeURIComponent進行處理的，對于中文可以很粗糙的理解成UTF-8編碼過。這一點通過抓包工具是可以確認的。到了服務端之后會通過getParameter獲取參數，由于帶charsetEncoding的過濾器，并且是采用UTF-8的，那么這里拿到的字符串應該也是不會亂碼的。到了這里，代碼并沒有特別之處。按我的理解，只要字符集能夠支持這個生僻字，就不會出現亂碼。 難道保存到數據庫的時候亂碼了? 目前數據庫是用GBK的，我去查了一下GBK的字符表，的確是有這么個字的。
我在本機上測了一下這個字的各種功能編碼轉換，都是正常的。 難道又是IBM的坑? 后來我又在服務器上測試了各種情況的輸出，發現有另外一個字”?”,除了字體大小有點不一樣之外，幾乎一模一樣的。
下面整理了一個簡單的測試程序，來說明這個奇怪的問題。
首先要說明的是，這里有2個字,一小一大,還有它們對應的unicode和utf-8編碼。 測試結果是采用secureCRT的GB18030編碼顯示。
有兩個字: 小 大unicode /uE863 /u4dae瀏覽器(utf-8) %EE%A1%A3 %E4%B6%AE下面的測試代碼，為了編譯時不關心字符集，所以換成utf-8字節來生成字符串。
public class Test { public static void main(String[] args) throws java.io.UnsupportedEncodingException { new Test().test(); } public void test() throws java.io.UnsupportedEncodingException { byte[] bbs = {-18,-95,-93,-28,-74,-82}; String x = new String(bbs, "utf-8"); String utf8 = new String(x.getBytes("utf-8"), "iso-8859-1"); //byte[] bs = utf8.getBytes("iso-8859-1"); //test case 1 //byte[] bs = x.getBytes("GBK"); //test case 2 for(byte b : bs){ System.out.PRintln(b); } System.out.println(x); }}對于Test Case 1, 測試一下字符串是不是本來就亂了。測試結果顯示，2個字都正常，要輸出成GB18030才是可以的(secureCRT設置GB18030編碼)。
>/tools/jdk1.6.0_20/bin/java -Dfile.encoding=GBK Test-18-95-93-28-74-82??>/opt/IBM/WebSphere/AppServer/java/bin/java -Dfile.encoding=GBK Test-18-95-93-28-74-82??>/opt/IBM/WebSphere/AppServer/java/bin/java -Dfile.encoding=GB18030 Test-18-95-93-28-74-82?>/tools/jdk1.6.0_20/bin/java -Dfile.encoding=GB18030 Test-18-95-93-28-74-82?對于Test Case 2，主要測試一下轉換成GBK字節的情況,因為這是保存到數據庫的必要轉換。 測試結果顯示，ibm的jdk下，第一個字會編程亂碼(對應的是63)。
>/tools/jdk1.6.0_20/bin/java -Ddefault.client.encoding=GBK -Dfile.encoding=GBK Test-2-9763?>/opt/IBM/WebSphere/AppServer/java/bin/java -Ddefault.client.encoding=GBK -Dfile.encoding=GBK Test63-2-97?
規避方法，選擇輸入第二個字(大字，截圖中的第二個字，應該看不出有什么區別)。話說回來，感覺這是ibm的jdk的bug，字符對應錯了。
新聞熱點
疑難解答
