问题起因：
客户订购了一关键字为"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
。