为什么要使用urlencode？
我正在写一个Web应用程序，并学习如何urlencode的HTML链接…
所有的urlencode问题在这里（见下面的标签）是“如何…？ 的问题。
我的问题不是“如何？” 但为什么？”。
即使是维基百科的文章也只涉及它的机制：
http://en.wikipedia.org/wiki/Urlencode，但不是为什么我应该在我的应用程序中使用urlencode。
使用（或不使用）urlencode的安全含义是什么？
如何使用urlencode失败被利用 ？
什么样的错误或失败可以出现与未编码的url？
我问，因为即使没有urlencode，一个链接到我的应用程序开发网站，如下面的预期工作： http://myapp/my%20test/ée/ràé
为什么要使用urlencode？
或者另一种说法：
什么时候应该使用urlencode？ 在什么样的情况下？
更新：上面还有一个更好的解释（imo）：
一个URI被表示为一个字符序列，而不是一个八位字节序列。 这是因为URI可能是通过不通过计算机networking的方式“传输”的，例如印在纸上，通过收音机阅读等等。
和
对于包含非ASCII字符的原始字符序列，情况则更加困难。 传输意图表示字符序列的八位字节序列的因特网协议预期将提供某种方式来识别所使用的字符集，如果可能有多于一个[RFC2277]的话。 但是，目前在通用URI语法中没有规定来完成这个标识。 一个单独的URIscheme可能需要一个字符集，定义一个默认的字符集，或提供一种方式来指示所使用的字符集。
因为它是在RFC中陈述的：
2.4。 转义序列
如果数据没有使用未保留的字符，则数据必须被转义; 这包括不对应于US-ASCII编码字符集的可打印字符的数据，或者对应于不允许的任何US-ASCII字符的数据，如下所述。
和
2.4.2。 什么时候逃脱和Unescape
一个URI总是处于“转义”的forms，因为转义或撤销已完成的URI可能会改变它的语义。 通常，转义编码唯一可以安全的做法是从其组成部分创buildURI; 每个组件可能有自己的一组保留的字符，所以只有负责生成或解释该组件的机制才能确定转义字符是否会改变其语义。 同样，在这些组件中的转义字符可以被安全解码之前，URI必须被分离成其组件。
在某些情况下，可以用毫无保留的字符表示的数据可能会出现转义; 例如，一些未预留的“标记”字符被某些系统自动转义。 如果给定的URIscheme定义了一个规范化algorithm，那么根据该algorithm，未保留的字符可能会被取消。 例如，有时使用“％7e”而不是“〜”在http URLpath中，但这两个对于http URL是等同的。
由于百分号“％”字符总是具有作为转义指示符的保留目的，因此必须将其转义为“％25”才能用作URI内的数据。 实现者应该小心，不要多次转义或不使用同一个string，因为忽略已经转义的string可能会导致将数据字符百分比错误地解释为另一个转义字符，反之亦然（在转义已经转义的string的情况下）。
有RFC（ http://www.faqs.org/rfcs/rfc1738.html等）定义了URL的格式，浏览器/ Web服务器开发人员依赖这个作为解释数据的标准。 如果你不遵守，结果可能是不可预测的。
HTTP URL有它的规范，它指出实际上所有的非拉丁字符都需要被编码。
我能想到的两个理由：
- 这真的取决于你如何parsing你的查询服务器端。 例如，使用HTTP的GET请求传递参数将有问题，如果有一些参数内的字符。
- 它允许你以你想要的方式处理非ansi字符（你指定编码）。 否则，浏览器可能会以某种随机编码的方式传递它们（不要认为它是在任何标准中定义的;如果我错了，请纠正我的错误）。
你将如何区分你的两条路是这样的
http://myapp/my%20test/
和
http://myapp/my test/
注释空间＆％20是URL的一部分。
