在使用JSP的過程中
最使人頭疼的一個問題就是中文亂碼問題
以下是我在軟件開發中遇到的亂碼問題以及解決方法
POST提交表單是亂碼
常見的情況為:頁面都正常
但新插入的數據全是亂碼
這種情況
就是因為提交的數據被程序接收後就是亂碼
這個亂碼又插入數據庫了
所以顯示不正常
解決方案:
a 修改配制來完成
修改tomcat的配制文件server
xml中的連接器
加上URIEncoding=
GB
就OK了
b 自己寫編碼轉換程序
b
a 在與表單交換數據的時候
做轉換
這種方式靈活
每一個頁面請求寫一個轉換
或者寫一個公共的類
在接收的時候
都做一下轉移
代碼如下:
public static String ISOGBChange(String s)
{
return EncodeChange(s
ISO
GB
);
}
public static String EncodeChange(String s
String source_encode
String dest_encode)
{
if(s==null)
return null;
try
{
byte[] tmpbyte = s
getBytes(source_encode); s = new String(tmpbyte
dest_encode);
return s;
}
catch (Exception e)
{
return
ERROR
;
}
}
b
b 使用tomcat的web
xml中定義的過濾器filter來轉換所有的請求編碼
這個需要自己去研究一下過濾器的寫法
再具體的轉換編碼
還是b
a中的代碼進行編碼轉換的
只是轉移不用再寫在每個程序中了
數據庫中本來就是亂碼
就是說數據庫裡面的數據本來就是亂碼
無論您用什麼編碼連接數據庫
查看到的都是亂碼
如何確定數據庫中本來就是亂碼呢?(其實也不太容易確定
我們僅給出一個大概的判斷)
您用客戶端連接數據庫的時候
一定要選擇連接編碼為GB
UTF
ISO
等常見的編碼格式
連接並查看您的表中內容是不是正常的
若沒有一種情況是正常的
應該就可以判定為亂碼了
當然
這個判定並不標准
甚至問題很多
但在國內
我想
%以上都用這幾種編碼
所以我認為這個判定准確性是可以被接受的
解決方案:您用客戶端連接數據庫的時候
一定要選擇連接編碼為GB
或者GBK
然後於重新執行數據庫腳本
保證數據庫裡保存的是正常的字符
而不是亂碼
從數據庫提取出來就是亂碼
數據庫裡本來是正常的
但用JAVA連接後
一經提取
就全亂了
解決方案:修改JAVA連接數據庫的URL
加上或者修改URL中的編碼為UTF
characterEncoding=UTF
若是hibernate的配置問題
jdbc連接url不能有&符號
會導致出錯或者後面不生效
我用&代替就好了
不要以為用的是GB
這裡就指定為GB
(個人認為若指定為GB
驅動又多做了一次編碼轉換
所以就又成了亂碼了)
當然
也可能驅動太舊等情況
上面只說了常見的幾種
亂碼問題
%以上的應該都是上面講到的
還有很多情況
就需要您自己慢慢分析了
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26633.html