一般情況下, 發(fā)送 encodeURIComponent(parmeName)+"="+encodeURIComponent(parmeValue); 接收時(shí), 直接 String paramValue = request.getParameter(paramName); // 容器自動(dòng)解碼.
我們知道 encodeURIComponent 使用的是 UTF-8 編碼規(guī)則來編的. 如果 request.getParameter(paramName) 時(shí),容器也按 UTF-8 解的話,是正確的. 根本無須在客戶端 進(jìn)行二次的 encodeURIComponent(...)
如果 request.getParameter(paramName),容器沒有按 UTF-8 解的話, 結(jié)果只有一個(gè),就是亂碼! 容器按什么編碼來解碼,決定于 request.setCharacterEncoding(***) 或者 服務(wù)器程序配置.
如果你在 jsp 程序中,能夠 request.setCharacterEncoding("UTF-8"), 并且 修改服務(wù)器配置,讓容器在解 GET 提交的參數(shù)時(shí),使用 UTF-8.
客戶端提交前不用二次編碼, 接收時(shí),也只要直接 request.getParameter(paramName) 即可
---------------------
為什么網(wǎng)上會(huì)有人提出在客戶端對(duì)字符串重復(fù)編碼兩次呢. 如果因?yàn)轫?xiàng)目需要,不能指定容器使用何種編碼規(guī)則來解碼提交的參數(shù), 比如:需要接收來自不同頁(yè)面,不地編碼的參數(shù)內(nèi)容時(shí)。 (又或者是開發(fā)人員被這有點(diǎn)復(fù)雜的東東搞得暈頭轉(zhuǎn)向,不懂得如何正確的去做好這接收參數(shù)的工作) 這個(gè)時(shí)候,在客戶端對(duì)參數(shù)進(jìn)行二次編碼,可以有效的避開“提交多字節(jié)字符”的這個(gè)棘手問題。 因?yàn)榈谝淮尉幋a,你的參數(shù)內(nèi)容便不帶有多字節(jié)字符了,成了純粹的 Ascii 字符串。(這里把編第一次的結(jié)果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不帶有多字節(jié)字符的) 再編一次后,提交,接收時(shí)容器自動(dòng)解一次 (容器自動(dòng)解的這一次,不管是按 GBK 還是 UTF-8 還是 ISO-8859-1 都好,都能夠正確的得到 [STR_ENC1]) 然后,再在程序中實(shí)現(xiàn)一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的參數(shù)的原值。 |