关于编码（一）：url的编码和解码问题

刚刚在CSDN的在线编辑器上写了大概一千多字，查个资料的空文字突然消失了，瞬间体会到心碎的感觉，不用本地sublime绝对我今天犯得最大的错误。苍天可鉴，我以后一定用sublime编辑器写好再贴上去，谁不这么干谁是小狗啊喂！
文章主要是探讨我们日常编程中遇到url编码和解码问题，谈到这个问题就不免也想讨论一下ASCII码和UNICODE码，以及为什么后产生的UNICODE码会不兼容ASCII码产生ASCII码中不能识别的“定宽空格”，导致出现上一篇博文中遇到的?乱码问题。由于该死的CSDN在线编辑器，今天就只讨论url编码和解码问题。

情景再现

一个新手程序员常常会遇到这种问题，当他往url中拼入汉字或者其他特殊符号并且尝试在另一个地方对传入的信息进行读取和解析的时候，基本上一定会遇到乱码的问题。如果他求助于有经验的程序员或者无所不能搜索引擎，那么就会得到这么一个答案：先编码再放入URL；先解码再读取数据。
为什么要使用这样的处理方案呢？严格来说，这不是一个处理方案，而是RFC1738网络标准的规定：

“只有字母和数字[0-9a-zA-Z]、一些特殊符号”$-_.+!*’(),”[不包括双引号]、以及某些保留字，才可以不经过编码直接用于URL。”
这个规定限制了我们必须编码和解码才能在url中放入一些特定信息，但是=，=由于规定并没有限制使用什么的编码和解码标准去做这件事情，所以为我们带来了一些新的问题。

在网络传输中正确的使用编码和解码方法

在RFC1738规定中，浏览器可以对没有编码的符号进行编码。现在市面上的浏览器真·五花八门，如果我们放任浏览器去做前台编码的工作，那显然是不可能的，唯一的办法，就是抢在浏览器的前面，让javascript完成对符号的编码，再向服务器提交，js代码是我们自己编写或者事先约定的，那我们就可以很轻松的在后台使用相应的解码方法获取准确的信息。
在js中，现在用于对URL进行编码的函数是encodeURI()，对应的解码函数是decodeURI()。在提交信息的时候，用encodeURI()进行编码，在处理获取到信息的时候，使用decodeURI()处理。
与此对应，在后台传递或者使用信息的时候，我们也应该进行相同的编码和解码处理。在Java中方法名称是js一致，编码的方法是encodeURI(),解码方法是decodeURI()。我们只需要在争取的时候调用这两个方法，就不会遇到无法获取信息的问题。
应该要注意的是，在java中，如果要指定使用的编码方法（因为js的方法是UTF-8编码格式），需要在调用方法的时候写明编码名：
URLDecoder.decode(url, “utf-8”);
URLEncoder.encode(url, “utf-8”);

文字丢了实在重写不动，明天继续写字符编码问题。