# 背景：
看着别人项目代码看到一个PathUtils工具类，
里面只有一个方法，String rebuild(String Path)，将路径进行URLDecoder.decode解码，避免路径中因为中文乱码导致程序异常
上面的方法的用处是，获取到项目配置文件的路径，通过 rebuild 方法返回解码后的路径。
# 疑惑：
由于我不清楚Path变量是怎么样的情况，为什么要经过rebuild方法过滤一遍
就想测试下，如果是正常中文进行解码，解码后的字符串还是一样的吗？
String newPath = "Keywords=湿答答"; try { newPath = URLDecoder.decode(newPath, "UTF-8"); System.out.println(newPath); } catch (UnsupportedEncodingException e) { // TODO Auto-generated catch block e.printStackTrace(); }
结果中文没有发生变化。
接着我查看的 URLDecoder的decode方法， + 号和 % 开头的字符串才会进行解码
note：这里的编码解码也称 %百分号编码解码
# 深入学习：
接着，用百度搜索的下 “urldecoder 编码和解码”
发现url编码解码主要是应用于发送 http 的 get 请求时，对特定字符串进行编码，后台服务器会对get请求的url进行解码，以保证网络传输过程中数据的正常。
看到一篇文章 不同浏览器中URL的编码方式
不同浏览器对编码字符的编码方式是不同的，
如IE浏览器可以设置编码的方式
可以设置是否发送utf-8格式的url
浏览器对URL编码方式不一样可能会导致我们后台获取到的数据是错误的。
浏览器编码方式有gbk，utf-8,等等，
假设：浏览器使用gbk的编码方式编码中文参数。我们后台服务器接收到后会进行utf-8解码，因为解码方式不一样，就导致我们获取到的参数是乱码的
为了避免这个问题我们需要自己对get请求的参数进行url编码。
为什么要自己主动对参数进行编码呢，需要先大概看下编码解码过程
注意：url编码解码也称 %百分号编码解码
编码过程：
字母，特殊用户字符（/,:@-_.等。即斜杠，逗号，点，冒号，横线，下划线等）
会被直接跳过，不会进行编码处理，
其他的所有字符都要经过%xx编码处理。
encodeURI不编码字符有82个：!，#，$，&，'，(，)，*，+，,，-，.，/，:，;，=，?，@，_，~，0-9，a-z，A-Z
编码方法很简单，在该字节ascii码的的16进制字符前面加%
如 空格字符，ascii码是32，对应16进制是'20'，那么urlencode编码结果是 %20
由于JavaScript使用的是Unicode编码，也就是utf-8编码，所以编码函数也是使用utf-8编码，
所以js的encodeURI函数，编码中文，‘爱’ 是三个字节，编码后 %e7%88%b1 ，这3个十六进制就代表，爱
解码过程：
解码是编码的逆向，对匹配到的百分号编码进行反向解码，字母和特殊字符也会被跳过。java中会对+号字符进行特殊处理，直接用空格替换。
上面的编码和解码有一个值得注意的地方，浏览器不会对 + 号进行编码，而tomcat或jetty服务器会将这个加号使用空格替换。
如下面的get请求
http://localhost:8080/api/test?aa=zhang+san&p2=18
我们java中使用request.getParameter("aa")方法获取到的aa参数的值是zhang san
+ 号被替换成的空格
这是一种情况，用户输入，跟我们获取到的数据不一致
还有一种情况，服务器是以 & 符号进行分割参数的，如果我们把上面+号替换成&
http://localhost:8080/api/test?aa=zhang&san&p2=18
我们获取到aa的值是zhang
服务器会认为这个get请求有三个参数，以 & 为分隔符
分别是
aa=zhang
san=
p2=18
为了避免以上问题，我们都不应该让浏览器对参数进行编码，而是我们自己做编码