情景：在资料调剂中，起首用户须要选择工作目标，然后跟据选择的工作目标不合而选择不合的账号和ip。处理惩罚过程如下：点击选择账号，在js中获取工作目标对工作目标进行两次编码（encodeURI（encodeURI（gzmb））），在后台，对工作目标进行解码，然后构建URL。

      如下：

1 String gzmb = URLDecoder.decode（request.getParameter（gzmb）， UTF-8）;

2 Stringurl = /wlzh/queryPageList.action？accountO.zt=1&accountO.gzmb=+gzmbJiami+&accountO.accountIsYx=1;

      如图

      可知解码是成功的。然则最后获得的成果倒是将所有的账号全部选择出来，并没有选择对应工作目标的账号。查看后台。URL跳转获得的工作目标值如下所示的：

      在这里我立马想到URL中文乱码，于是我在后台进行解码操纵。然则不知道为什么，换了几种办法都不成以。在这里我想到了以前的办法，经由过程js两次编码，重构URL。所以在后台我将工作目标传递出来，然后经由过程js两次编码，从头构建URL。做到这里时我发明，这不就是一开端的么？既然如许，第一步为什么须要解码呢，直接传递过来不就可以了么？将第一步的解码去掉，还真的可以。在进行测试，ie7以上的、火狐、谷歌，唯独ie6不成以（这个原因不知道为什么？求申明）。在这里我只能想到一种解决办法了，应用form表单来进行处理惩罚。固然可以成功，然则这是万不得已的办法。

      “有些器材只要你放在心上，过段时候后你必然可以想到一种解决办法”。放工后在车上忽然想到了一种另类的办法—在后台对工作目标进行加密操纵，赋值给url，然后在别的一边进行解密操纵不就可以了。如下

1 //构建账号选择前提

2 

3         String gzmb= URLDecoder.decode（request.getParameter（gzmb） == null ？  : request.getParameter（gzmb）， utf-8）;

4        String gzmbJiami = DecodeUtils.getJiamiData（gzmb）;

5        Stringurl = /wlzh/queryPageList.action？accountO.zt=1&accountO.gzmb=+gzmbJiami+&accountO.accountIsYx=1;

       URL如下所示：

      在那边进行解密操纵

1 String gzmbJiemi = DecodeUtils.getJiemiData（accountO.getGzmb（））;

2 accountO.setGzmb（gzmbJiemi）;

3 PageResultInfo<Account_Bean>pageResultInfo = service.queryAccountPageResultBy（accountO ， pageInfo，user）;

      获得gzmb值如下所示

      注：DecodeUtils是一个功能很是强大的加密解密的对象类。

      这里所供给的并不是什么高深的技巧，只是供给一种另类的解决办法。这个工作告诉了我，没有做不到的工作，只有想不到的办法。