jsp頁面js提交傳遞中文字符時亂碼處理

在js中通過encodeURI(encodeURI("要轉的字符"));

encodeURI說明:http://www.w3school.com.cn/js/jsref_encodeURI.asp

到後臺java方法中。通過

java.net.URLDecoder.decode(傳遞進來的數據,"UTF-8")

完成逆向解碼。

以下對其進行詳細說明: (摘抄自網絡,感謝此文共享者)

爲什麼要encodeURI(url)兩次纔不會出現亂碼?文章分類:Web前端

因爲Tomcat服務器會自動幫你做一次URLDecode,所以再加上你自己在代碼裏面寫的URLDecode,一共就是兩個Decode了,既然要兩次Decode,當然就需要兩次Encode了。或許你會問,乾脆只Encode一次,然後在java代碼裏不Decode,呵呵,這個也是不行的,這其實也就是爲什麼要進行Encode的原因吧

--------------------------------------------------------------------------------------------------------

一般情況下, 發送 encodeURIComponent(parmeName)+"="+encodeURIComponent(parmeValue);
接收時, 直接 String paramValue = request.getParameter(paramName); // 容器自動解碼.

我們知道 encodeURIComponent 使用的是 UTF-8 編碼規則來編的.
如果 request.getParameter(paramName) 時,容器也按 UTF-8 解的話,是正確的. 根本無須在客戶端
進行二次的 encodeURIComponent(...)


如果 request.getParameter(paramName),容器沒有按 UTF-8 解的話, 結果只有一個,就是亂碼!
容器按什麼編碼來解碼,決定於 request.setCharacterEncoding(***) 或者 服務器程序配置.

如果你在 jsp 程序中,能夠 request.setCharacterEncoding("UTF-8"), 並且 修改服務器配置,讓容器在解 GET 提交的參數時,使用 UTF-8.

客戶端提交前不用二次編碼, 接收時,也只要直接 request.getParameter(paramName) 即可

---------------------

爲什麼網上會有人提出在客戶端對字符串重複編碼兩次呢.
如果因爲項目需要,不能指定容器使用何種編碼規則來解碼提交的參數, 比如:需要接收來自不同頁面,不地編碼的參數內容時。 (又或者是開發人員被這有點複雜的東東搞得暈頭轉向,不懂得如何正確的去做好這接收參數的工作)
這個時候,在客戶端對參數進行二次編碼,可以有效的避開“提交多字節字符”的這個棘手問題。
因爲第一次編碼,你的參數內容便不帶有多字節字符了,成了純粹的 Ascii 字符串。(這裏把編第一次的結果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不帶有多字節字符的)
再編一次後,提交,接收時容器自動解一次 (容器自動解的這一次,不管是按 GBK 還是 UTF-8 還是 ISO-8859-1 都好,都能夠正確的得到 [STR_ENC1])
然後,再在程序中實現一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的參數的原值。


轉自:http://hi.baidu.com/aluan_blog/item/ddf580c758807662f7c95d18


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章