response傳值亂碼問題.doc_第1頁
response傳值亂碼問題.doc_第2頁
response傳值亂碼問題.doc_第3頁
全文預(yù)覽已結(jié)束

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論