关于 URL 编码的知识

http://www.oschina.net/translate/what-every-web-developer-must-know-about-url-encoding

常见问题

    url 空格陷阱：http://stackoverflow.com/questions/17225146/java-net-urisyntaxexception-illegal-character-in-scheme-at-index-0

...........

URL常见陷阱

如果你正和URL打交道，了解下能够避免的常见陷阱绝对是值得的。现在我们给大家介绍下不仅限于此的一些常见陷阱。

使用哪类字符编码?

URL编码规范并没有定义使用何种字符编码形式去编码字节。一般的ASCII字母数字字符并不需要转义，但是ASCII之外的保留字需要(例如法语单词“nœud”中的"œ")。我们必须提出疑问，应该使用哪类字符编码来编码URL字节。

当然如果只有Unicode的话，这个世界就会清净很多。因为每个字符都包含其中，但是它只是一个集合，或者说是列表如果你愿意，它本身并不是一中编码。Unicode可以使用多种方式进行编码，譬如UTF-8或者UTF-16（也有其它格式），但是问题并没有解决：我们应该使用哪类字符来编码URL（通常也指URI）。

标准并没有定义一个URI应该以何种方式指定其编码，所以其必须从环境信息中进行推导。对于HTTP URL，它可以是HTML页面的编码格式，或HTTP头的。这通常会让人迷惑，也是许多错误的根源。事实上，最新版的URI标准 定义了新的URI scheme将采用UTF-8，host（甚至已有的scheme）也使用UTF-8，这让我更加怀疑：难道host和path真的可以使用不同的编码方式？

每一部分的保留字都是不同。

是的，他们是，是的，他们，是的，他们是。。。

对于一个httpd连接，路径片段部分中的空格被编码为"%20"（不，完全没有"+"）,而“+”字符在路径片段部分可以保持不编码。

现在，在查询部分，一个空格可能会被编码为“+”（为了向后兼容：不要试图在URI标准去搜索他）或者“%20”，当作为“+”字符（作为个统配符的结果）会被编译为“%2B”。

这意味着“blue+light blue”字串，如果在路径部分或者查询部分，将会有不同的编码。比如得到"http://example.com/blue+light%20blue?blue%2Blight+blue"这样的编码形式，这样我们不需从语法上分析url结构，就可以推导这个url的整个结构是可能

.............