两侧encodeURIComponent是因为第一次encodeURIComponent的时辰呈现了"％"，这个符号在解析参数的时辰是无法解析的，必须把"％"也进行编码，"％"编码后就是"％25"，如许就不会呈现题目了。

一般景象下， 发送 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"）） 就可以获得想提交的参数的原值。