response傳值亂碼問(wèn)題.doc

Charset in J2EE Web Application運(yùn)行環(huán)境：Win2K Pro日文版，SUN J2SDK 1.4.2_04, Tomcat 4.1.27，JSPs由于在Tomcat下，從request中(比如通過(guò)request.getParameter(String)方法)取得的數(shù)據(jù)都是ISO8859_1對(duì)應(yīng)的Unicode字符串（我猜想整個(gè)過(guò)程應(yīng)該是這樣的：假設(shè)HTML的Encoding為Shift_JIS，那么IE將form中的Shift_JIS編碼的各input控件的值轉(zhuǎn)換成ISO8859_1編碼的數(shù)據(jù)流發(fā)送給Tomcat，然后Tomcat再將這些以ISO8859_1編碼的數(shù)據(jù)轉(zhuǎn)換成ISO8859_1對(duì)應(yīng)的Unicode數(shù)據(jù)并通過(guò)request對(duì)象傳遞給我們的JSPs；JSPs完成了自己的處理后，最后將Shift_JIS對(duì)應(yīng)的Unicode通過(guò)response對(duì)象傳遞給Tomcat，然后Tomcat再將這些數(shù)據(jù)轉(zhuǎn)換成ISO8859_1的數(shù)據(jù)流傳回給客戶端的IE，然后IE再將接收到的ISO8859_1編碼的數(shù)據(jù)轉(zhuǎn)換成Shift_JIS編碼的數(shù)據(jù)并最終顯示成HTML頁(yè)面。之所以要在客戶端與服務(wù)器端之間用ISO8859_1編碼來(lái)進(jìn)行通信，可能是為了防止雙字節(jié)字符的高8位被某些網(wǎng)絡(luò)服務(wù)器忽略從而造成數(shù)據(jù)丟失，因?yàn)镮SO8859_1編碼的字符只有8位長(zhǎng)，而Shift_JIS等雙字節(jié)字符集中的字符的高8位是有值的），所以我們?cè)贘SPs中取得請(qǐng)求數(shù)據(jù)后，一般要將該數(shù)據(jù)轉(zhuǎn)換后才不會(huì)出現(xiàn)亂碼情況。我們需要在JSPs中做類似下面的轉(zhuǎn)換：String reqParamA = new String(request.getParameter(txt_a).getBytes(ISO8859_1), Shift_JIS);但是在向客戶端輸出數(shù)據(jù)時(shí)，則不需要再做轉(zhuǎn)換，直接將Shift_JIS對(duì)應(yīng)的Unicode字符串向客戶端輸出即可。上面描述的是從客戶端向服務(wù)器發(fā)出請(qǐng)求到服務(wù)器端向客戶端發(fā)回響應(yīng)，客戶端接收到響應(yīng)并最終顯示HTML頁(yè)面的典型流程，但是也有些例外需要注意：通過(guò)調(diào)用response.sendRedirect(str_url)，在服務(wù)器端直接重定向到另一個(gè)URL時(shí)。假如str_url中包含了queryString(比如someUrl?paramA=包含雙字節(jié)字符的字符串mB=包含雙字節(jié)字符的字符串.)，那么必須對(duì)str_url做類似下面的轉(zhuǎn)換，否則映射到目的URL的JSPs取得的請(qǐng)求數(shù)據(jù)就都是亂碼（因?yàn)榫拖裆厦嫠f(shuō)的，它們所期望的請(qǐng)求數(shù)據(jù)應(yīng)該是ISO8859_1所對(duì)應(yīng)的Unicode字符串）：response.sendRediret(str_url.getBytes(Shift_JIS), ISO8859_1)；文件上傳。此時(shí)服務(wù)器端的JSPs所獲取的數(shù)據(jù)流的編碼形式就是該文件的字符集所對(duì)應(yīng)的Unicode數(shù)據(jù)流。比如在Win2K Pro日文版下，一個(gè).csv文件的編碼就是MS932，那么當(dāng)它被上傳到服務(wù)器端時(shí)，JSPs所獲取的數(shù)據(jù)流就是MS932對(duì)應(yīng)的Unicode數(shù)據(jù)流。假設(shè)此時(shí)的運(yùn)行環(huán)境為Win2K Pro日文版 + VOBSEnhydra 5.1SE，當(dāng)在客戶端JavaScript里通過(guò)window.showModalDialog()(該ModalDialog內(nèi)的HTML的Encoding為Shift_JIS)向服務(wù)器端發(fā)出請(qǐng)求時(shí)，服務(wù)器端接收到的請(qǐng)求數(shù)據(jù)卻是MS932對(duì)應(yīng)的Unicode字符串；但是假如使用Tomcat 4.1.27，則服務(wù)器端接收到的就是正常的ISO8859_1對(duì)應(yīng)的Unicode字符串），一直未能查出原因。我有一個(gè)建議，那就是在進(jìn)行字符集轉(zhuǎn)換時(shí)，最好明確地寫出源字符集和目的字符集，因?yàn)槿绻÷圆粚懙脑挘琂ava會(huì)采用系統(tǒng)默認(rèn)字符集來(lái)處理，而不同的OS的默認(rèn)字符集通常都是不一樣的，這樣就很可能會(huì)出現(xiàn)同一個(gè)J2EE Web App在WinNT/2K/XP下運(yùn)行正常，但是一移植到Unix/Linux下就出亂碼的問(wèn)題。推薦的寫法 ：String str = new String(str.getBytes(GB2312), ISO8859_1); /假設(shè)str的原始編碼就是GB2312，與OS無(wú)關(guān)不推薦的寫法：String str = new String(str.ge