明輝手游網(wǎng)中心:是一個免費提供流行視頻軟件教程、在線學(xué)習(xí)分享的學(xué)習(xí)平臺!

Java Servlet/Jsp多語言處理方案(一)

[摘要]Java Servlet/Jsp多語言解決方案因為一直不信Java竟會有不能混排顯示多國語言的BUG,這個周末研究了一下Servlet、 Jsp的多國語言顯示的問題,也就是Servlet的多字符集問題,由于我對字符集的概念還 不是很清晰所以寫出的東西未必是準確的,我是這樣理解Java中的字符集的:...
Java Servlet/Jsp多語言解決方案

因為一直不信Java竟會有不能混排顯示多國語言的BUG,這個周末研究了一下Servlet、
Jsp的多國語言顯示的問題,也就是Servlet的多字符集問題,由于我對字符集的概念還
不是很清晰所以寫出的東西未必是準確的,我是這樣理解Java中的字符集的:在運行時
,每個字符串對象中存儲的都是編碼為UNICODE內(nèi)碼的(我覺得所有的語言中都是有相應(yīng)
編碼的,因為在計算機內(nèi)部字符串總是用內(nèi)碼來表示的,只不過一般計算機語言中的字
符串編碼時平臺相關(guān)的,而Java則采用了平臺無關(guān)的UNICODE)。
  Java從一個byte流中讀取一個字符串時,將把平臺相關(guān)的byte轉(zhuǎn)變?yōu)槠脚_無關(guān)的Un
icode字符串。在輸出時Java將把Unicode字符串轉(zhuǎn)變?yōu)槠脚_相關(guān)的byte流,如果某個Un
icode字符在某個平臺上不存在,將會輸出一個'?'。舉個例子:在中文Windows中,Jav
a讀出一個"GB2312"編碼的文件(可以是任何流)到內(nèi)存中構(gòu)造字符串對象,將會把GB2
312編碼的文字轉(zhuǎn)變?yōu)閁nicode編碼的字符串,如果把這個字符串輸出又將會把Unicode字
符串轉(zhuǎn)化為GB2312的byte流或數(shù)組:"中文測試"----->"\u4e2d\u6587\u6d4b\u8bd5"--
--->"中文測試"。
如下例程:
byte[] bytes = new byte[]{(byte)0xd6, (byte)0xd0, (byte)0xce, (byte)0xc4, (b
yte)0xb2, (byte)0xe2, (byte)0xca, (byte)0xd4};//GBK編碼的"中文測試"
java.io.ByteArrayInputStream bin = new java.io.ByteArrayInputStream(bytes);
java.io.BufferedReader reader = new java.io.BufferedReader(new java.io. Inpu
tStreamReader (bin,"GBK"));
String msg = reader.readLine();
System.out.println(msg)
  這段程序放到包含"中文測試"這四個字的系統(tǒng)(如中文系統(tǒng))中,可以正確地打印
出這些字。msg字符串中包含了正確的"中文測試"的Unicode編碼:"\u4e2d\u6587\u6d4
b\u8bd5",打印時轉(zhuǎn)換為操作系統(tǒng)的默認字符集,是否可以正確顯示依賴于操作系統(tǒng)的
字符集,只有在支持相應(yīng)字符集的系統(tǒng)中,我們的信息才能正確的輸出,否則得到的將
會是垃圾。
  話入正題,我們來看看Servlet/Jsp中的多語言問題。我們的目標是,任一國家的客
戶端通過Form向Server發(fā)送信息,Server把信息存入數(shù)據(jù)庫中,客戶端在檢索時仍然能
夠看到自己發(fā)送的正確信息。事實上,我們要保證,最終Server中的SQL語句中保存的時
包含客戶端發(fā)送文字的正確Unicode編碼;DBC與數(shù)據(jù)庫通訊時采用的編碼方式能包含客
戶端發(fā)送的文字信息,事實上,最好讓JDBC直接使用UNICODE/UTF8與數(shù)據(jù)庫通訊!這樣
就可以確保不會丟失信息;Server向客戶端發(fā)送的信息時也要采用不丟失信息的編碼方
式,也可以是Unicode/Utf8。
  如果不指定Form的Enctype屬性,F(xiàn)orm將把輸入的內(nèi)容依照當前頁面的編碼字符集u
rlencode之后再提交,服務(wù)器端得到是urlencoding的字符串。編碼后得到的urlencodi
ng字符串是與頁面的編碼相關(guān)的,如gb2312編碼的頁面提交"中文測試",得到的是"%D6
%D0%CE%C4%B2%E2%CA%D4",每個"%"后跟的是16進制的字符串;而在UTF8編碼時得到的
卻是"%E4%B8%AD%E6%96%87%E6%B5%8B%E8%AF%95",因為GB2312編碼中一個漢字是16位的
,而UTF8中一個漢字卻是24位的。中日韓三國的ie4以上瀏覽器均支持UTF8編碼,這種方
案肯定包涵了這三國語言,所以我們?nèi)绻孒tml頁面使用UTF8編碼那么將至少可以支持
這三國語言。
  但是,如果我們html/Jsp頁面使用UTF8編碼,因為應(yīng)用程序服務(wù)器可能不知道這種
情況,因為如果瀏覽器發(fā)送的信息不包含charset信息,至多Server知道讀到Accept-La
nguage請求投標,我們知道僅靠這個投標是不能獲知瀏覽器所采用編碼的,所以應(yīng)用程
序服務(wù)器不能正確解析提交的內(nèi)容,為什么?因為Java中的所有字符串都是Unicode16位
編碼的,HttpServletRequest.request(String)的功能就是把客戶端提交的Urlencode編
碼的信息轉(zhuǎn)為Unicode字符串,有些Server只能認為客戶端的編碼和Server平臺相同,簡
單地使用URLDecoder.decode(String)方法直接解碼,如果客戶端編碼恰好和Server相同
,那么就可以得到正確地字符串,否則,如果提交地字符串中包含了當?shù)刈址,那么?
會導(dǎo)致垃圾信息。
  在我提出的這個解決方案里,已經(jīng)指定了采用Utf8編碼,所以,可以避免這個問題
,我們可以自己定制出decode方法:
public static String decode(String s,String encoding) throws Exception {
StringBuffer sb = new StringBuffer();
for(int i=0; i<s.length(); i++) {
char c = s.charAt(i);
switch (c) {
case '+':
sb.append(' ');
break;
case '%':
try {
sb.append((char)Integer.parseInt(
s.substring(i+1,i+3),16));
}
catch (NumberFormatException e) {
throw new IllegalArgumentException();
}
i += 2;
break;
default:
sb.append(c);
break;
}
}
// Undo conversion to external encoding
String result = sb.toString();
byte[] inputBytes = result.getBytes("8859_1");
return new String(inputBytes,encoding);
}
  這個方法可以指定encoding,如果把它指定為UTF8就滿足了我們的需要。比如用它
解析:"%E4%B8%AD%E6%96%87%E6%B5%8B%E8%AF%95"就可以得到正確的漢字"中文測試"的
Unicode字符串。
現(xiàn)在的問題就是我們必須得到客戶端提交的Urlencode的字符串。對于method為get的fo
rm提交的信息,可以用HttpServletRequest.getQueryString()方法讀到,而對于post方
法的form提交的信息,只能從ServletInputStream中讀到,事實上標準的getParameter
方法被第一次調(diào)用后,form提交的信息就被讀取出來了,而ServletInputStream是不能
重復(fù)讀出的。所以我們應(yīng)在第一次使用getParameter方法前讀取并解析form提交的信息
。