问题原由：
客户订购了一关键字为"e+h变送器" ， 在首页推荐广告中，会根据用户在search搜索过的关键字进行一个匹配投放。技术实现是UED经过JS获取cookie中的h_keys内容，拼装到 http://xxxxx/advert/ctp_advert.htm?num=4&keyword={keyword}。 这里取出来对应的cookie信息为中文，最后经过一个ajax发起一个ＧＥＴ请求。
因此针对最后的请求是：http://xxxxxx/advert/ctp_advert.htm?num=4&keyword=e+h变送器。 而在服务端接受到对应的请求参数时，发现参数为：e h变送器， +号没了。 初步怀疑跟ＵＲＬ规范相关，须要进行url encode。
问题分析：
查了下JS encode的相关内容， 总于发现+号的秘密。
html中由于一些非标准的作法，将+等同于空格进行处理（当Html的表单被提交时， 每一个表单域都会被Url编码以后才在被发送。因为历史的缘由，表单使用的Url编码实现并不符合最新的标准。例如对于空格使用 的编码并非%20，而是+号，若是表单使用的是Post方法提交的，咱们能够在HTTP头中看到有一个Content-Type的header，值为 application/x-www-form-urlencoded，大部分应用程序均能处理这种非标准实现的Url编码）。
在搜索引擎中作了下尝试：
keyword = e h变送器 , url =http: //www.google.cn/search?hl=zh-CN&newwindow=1&q=e+h变送器(空格被转化为+号)
keyword = e+ h变送器 , url = http: //www.google.cn/search?hl=zh-CN&newwindow=1&q=e%2Bh变送器 (+号被进行了转义为%2B，程序才能正常处理)
问题解决：
思路1:
1. 要想正常传输+号而不被转义为空格，须要进行进行编码为%2B。查了下几个编码函数，发现只有encodeURIComponent 才会对+号进行编码处理。
2. encodeURIComponent默认为采用UTF-8字符集，理论上只须要在原先的请求中添加_input_charset=utf-8(由 pipeline中的SetLocaleValve进行解析)，就能够获得正确的 e+h变送器。
在实施过程当中，发现结果并非预期的那样。 客户端经过js encode后，在服务端解析后一直是乱码。 查了下byte，发现服务端一直是用GBK在进行解析， 针对变送器的UTF-8编码的byte为{-27,-113,-104,-23,-128,-127}，客户端用GBK解析后变为{-27.-113.- 104.-23,-63,-63}，针对最后两byte由于字符不可见，致使所有被替换为-63。网上查了下，针对 utf-8 -> gbk -> utf-8 在必定状况下就会出现该问题(http://lingqi1818.iteye.com/blog/348953)。
思路2：
继续追查对应的_input_charset=utf-8未生效的缘由，DEBUG看到在SetLocaleValve中的确设置了request.setCharsetEncoding为utf-8。初步怀疑是否跟jboss server的配置有关，查了下跟URIEncoding 和useBodyEncodingForURI 设置有关。 目前公司所使用的jboss为4.05，对应俄tomact配置中只指定了对应的URIEncoding=GBK。正由于这样，致使设置的_input_charset针对GBK的提交没有效果，仍是按照GBK进行解析。
1. 考虑将请求由GET换成POST ， 这样就可使用_input_charset
但在实施过程当中，和UED沟经过程，针对POST的会引发一个跨域请求的问题。此方案又只能作罢
思路3 (实践成功)：
1. UED进行伪url encode的实现 , 将+号进行%2B的编码。 由于目前JS中没有现成的函数，这里只是经过replace(/\+/g, '%2B') 进行了转化。
总 结
针对+号的处理，针对不一样的业务场景须要不一样的处理方案，描述下几种场景:
1. 非Ajax 请求
能够直接使用Form表单的 GET ,POST的urlencode协议，自动实现+ => %2B 的转化
2. Ajax 请求
* GET请求 : 很无奈，只能使用方案3，人为进行+号转化。
* POST请求(同一应用，非跨域请 求) : 使用encodeURIComponent + _input_charset=utf-8 指定编码进行处理。
ps: 前面提的这几种方案，都是基于+号是正常的业务场景进行考虑。同时咱们也能够从业务层面进行一个梳理，+号处理是否有其必要性，能从业务数据入口直接规避 那就最好了。
背景知识：
URIEncoding和useBodyEncodingForURI
对于URL提交的数据和表单中GET方式提交的数据，在接收数据的JSP中设置request.setCharacterEncoding参数是不行的， 由于在Tomcat5.0中，默认状况下使用ISO- 8859-1对URL提交的数据和表单中GET方式提交的数据进行从新编码（解码），而不使用该参数对URL提交的数据和表单中GET方式提交的数据进行 从新编码（解码）。要解决该问题，应该在Tomcat的配置文件的Connector标签中设置useBodyEncodingForURI或者 URIEncoding属性，其中useBodyEncodingForURI参数表示是否用request.setCharacterEncoding 参数对URL提交的数据和表单中GET方式提交的数据进行从新编码，在默认情 况下，该参数为false（Tomcat4.0中该参数默认为true）； URIEncoding参数 指定对全部GET方式请求（包括URL提交的数据和表单中GET方式提交的数据）进行统一的从新编码（解码）的编码。URIEncoding和useBodyEncodingForURI区别是，URIEncoding是对全部GET方式的请求的数据进行统一的从新编码 （解码），而useBodyEncodingForURI则是根据响应该请求的页面的request.setCharacterEncoding参数对数 据进行的从新编码（解码），不一样的页面能够有不一样的从新编码（解码）的编码。因此对于URL提交的数据和表单中GET方式提交的数据，能够修改 URIEncoding参数为浏览器编码或者修改useBodyEncodingForURI为true，而且在得到数据的JSP页面中 request.setCharacterEncoding参数设置成浏览器编码。
为何须要Url编码
1. Url中有些字符会引发歧义 , =,&号等
2. Url的编码格式采用的是ASCII码，而不是Unicode，这也就是说你不能在Url中包含任何非ASCII字符，例如中文
哪些字符须要编码
RFC3986文档规定，Url中只容许包含英文字母（a-zA-Z）、数字（0-9）、-_.~4个特殊字符以及全部保留字符。
Url能够划分红若干个组件，协议、主机、路径等。RFC3986中指定了如下字符为保留字符： ! * ' ( ) ; : @ & = + $ , / ? # [ ]
如何对Url中的非法字符进行编码
Url编码一般也被称为百分号编码（Url Encoding，also known as percent-encoding），是由于它的编码方式很是简单，使用%百分号加上两位的字符——0123456789ABCDEF——表明一个字节的 十六进制形式。Url编码默认使用的字符集是US-ASCII。例如a在US-ASCII码中对应的字节是0x61，那么Url编码以后获得的就是%61，咱们在地址栏上输入http: //g.cn/search?q=%61%62%63，实际上就等同于在google上搜索abc了。又如@符号在ASCII字符集中对应的字节为0x40，通过Url编码以后获得的是%40。
Javascript中的escape,encodeURI和encodeURIComponent的区别
Javascript中提供了3对函数用来对Url编码以获得合法的Url，它们分别是escape / unescape,encodeURI / decodeURI和encodeURIComponent / decodeURIComponent。解码和编码的过程是可逆的.
兼容性不一样
escape函数是从Javascript1.0的时候就存在了，其余两个函数是在Javascript1.5才引入的。可是因为Javascript1.5已经很是普及了，因此实际上使用encodeURI和encodeURIComponent并不会有什么兼容性问题。
对Unicode字符的编码方式不一样
这三个函数对于ASCII字符的编码方式相同，均是使用百分号+两位十六进制字符来表示。可是对于Unicode字符，escape的编码方式是% uxxxx，其中的xxxx是用来表示unicode字符的4位十六进制字符。这种方式已经被W3C废弃了。可是在ECMA-262标准中仍然保留着 escape的这种编码语法。encodeURI和encodeURIComponent则使用UTF-8对非ASCII字符进行编码，而后再进行百分号 编码。这是RFC推荐的。所以建议尽量的使用这两个函数替代escape进行编码。
适用场合不一样
encodeURI被用做对一个完整的URI进行编码，而encodeURIComponent被用做对URI的一个组件进行编码。
安全字符不一样
可到这里查看具体方法的使用：http://www.w3school.com.cn/js/jsref_encodeURIComponent.asp
escape（69个） */@+-._0-9a-zA-Z
encodeURI（82个）!#$&'()*+,/:;=?@-._~0-9a-zA-Z
encodeURIComponent（71个）!'()*-._~0-9a-zA-Z (注意+ 号未在其安全字符里)
其余和Url编码相关的问题
对于包含中文的Url的处理问题，不一样浏览器有不一样的表现。例如对于IE，若是你勾选了高级设置“老是以UTF-8发送Url”，那么Url中的路径部分 的中文会使用UTF-8进行Url编码以后发送给服务端，而查询参数中的中文部分使用系统默认字符集进行Url编码。为了保证最大互操做性，建议全部放到 Url中的组件所有显式指定某个字符集进行Url编码，而不依赖于浏览器的默认实现。另外，不少HTTP监视工具或者浏览器地址栏等在显示Url的时候会自动将Url进行一次解码（使用UTF-8字符集），这就是为何当你在 Firefox中访问Google搜索中文的时候，地址栏显示的Url包含中文的缘故。但实际上发送给服务端的原始Url仍是通过编码的。你能够在地址栏 上使用Javascript访问location.href就能够看出来了。在研究Url编解码的时候千万别被这些假象给迷惑了。