URL 中的空格何时编码为+，何时编码为%20？
【问题讨论】：
标签： url url-encoding
来自Wikipedia（已添加重点和链接）：
当提交已输入 HTML 表单的数据时，表单字段名称和值将被编码并使用方法 GET 或 POST 或过去通过电子邮件在 HTTP 请求消息中发送到服务器。 默认使用的编码基于通用 URI 百分比编码规则的早期版本，带有 number of modifications，例如换行规范化和用“+”而不是“%20”替换空格。 以这种方式编码的数据的 MIME 类型是 application/x-www-form-urlencoded，目前在 HTML 和 XForms 规范中定义（仍然以非常过时的方式）。
因此，real 百分比编码使用 %20，而 URL 中的表单数据是使用 + 的修改形式。因此，您很可能只在 ? 之后的查询字符串中的 URL 中看到 +。
【讨论】：
multipart/form-data 使用 MIME 编码； application/x-www-form-urlencoded 使用 + 并且正确编码的 URI 使用 %20。
http://www.bing.com/search?q=hello+world和名称中带有空格的资源http://camera.phor.net/cameralife/folders/2012/2012-06%20Pool%20party/
mailto:support@example.org?subject=I%20need%20help。如果您尝试使用 +，电子邮件将使用 +es 而不是空格打开。
我会推荐%20。
你在硬编码吗？
不过，这在不同语言之间并不是很一致。
如果我没记错的话，PHP 中的urlencode() 将空格视为+，而Python 的urlencode() 将它们视为%20。
编辑：
看来我搞错了。 Python 的 urlencode()（至少在 2.7.2 中）使用 quote_plus() 而不是 quote()，因此将空格编码为“+”。
W3C 的建议似乎也是“+”，如下所示：http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1
事实上，您可以关注 Python 自己的问题跟踪器上关于使用什么来编码空格的有趣辩论：http://bugs.python.org/issue13866。
编辑#2：
我知道“”最常见的编码方式是“+”，但只是一个注释，可能只是我，但我觉得这有点混乱：
import urllib
print(urllib.urlencode({' ' : '+ '})
>>> '+=%2B+'
【讨论】：
URLEncoder.encode() 方法也将其转换为+。
这种混乱是因为 URL 直到今天仍然“损坏”。
来自a blog post：
以“http://www.google.com”为例。这是一个网址。 URL 是统一资源定位器，实际上是指向网页的指针（在大多数情况下）。自 1994 年第一个规范以来，URL 实际上具有非常明确的结构。
我们可以提取有关“http://www.google.com”网址的详细信息：
+---------------+-------------------+ | Part | Data | +---------------+-------------------+ | Scheme | http | | Host | www.google.com | +---------------+-------------------+如果我们查看更复杂的 URL，例如：
“https://bob:bobby@www.lunatech.com:8080/file;p=1?q=2#third”
我们可以提取以下信息：
+-------------------+---------------------+ | Part | Data | +-------------------+---------------------+ | Scheme | https | | User | bob | | Password | bobby | | Host | www.lunatech.com | | Port | 8080 | | Path | /file;p=1 | | Path parameter | p=1 | | Query | q=2 | | Fragment | third | +-------------------+---------------------+ https://bob:bobby@www.lunatech.com:8080/file;p=1?q=2#third \___/ \_/ \___/ \______________/ \__/\_______/ \_/ \___/ | | | | | | \_/ | | Scheme User Password Host Port Path | | Fragment \_____________________________/ | Query | Path parameter Authority每个部分的保留字符不同。
对于 HTTP URL，路径片段部分中的空格必须编码为“%20”（不是，绝对不是“+”），而路径片段部分中的“+”字符可以不编码。
现在在查询部分，空格可以编码为“+”（为了向后兼容：不要尝试在 URI 标准中搜索它）或“%20”，而“+”字符（作为结果这种歧义）必须转义为“%2B”。
这意味着“蓝色+浅蓝色”字符串必须在路径和查询部分进行不同的编码：
“http://example.com/blue+light%20blue?blue%2Blight+blue”。
从那里您可以推断，如果没有对 URL 结构的句法意识，编码完全构造的 URL 是不可能的。
这归结为：
您应该在? 之前和+ 之后有%20。
【讨论】：
key1=value1&key1=value2，其中键和值使用 encodeURIComponent 遵循的任何规则进行编码，但 AFAIK 查询部分的内容完全 100% 取决于应用程序。否则它只会转到第一个#，没有官方编码。
?，但在 ? 之后，它只是一个品味问题。看在上帝的份上，人们，总是使用基于百分号的编码，并为更重要的事情腾出一些大脑空间。
在 URL 的“application/x-www-form-urlencoded”内容类型键值对查询部分中，空格只能编码为“+”。在我看来，这是可能，而不是必须。在其余的 URL 中，它被编码为 %20。
在我看来，最好始终将空格编码为 %20，而不是“+”，即使在 URL 的查询部分也是如此，因为 HTML 规范 (RFC 1866) 指定空格字符应该是在“application/x-www-form-urlencoded”内容类型键值对中编码为“+”（参见第 8.2.1 段。第 1 小段）
这种编码表单数据的方式也在后面的 HTML 规范中给出。例如，在 HTML 4.01 规范中查找有关 application/x-www-form-urlencoded 的相关段落，等等。
以下是 URL 中的示例字符串，其中 HTML 规范允许将空格编码为加号：“http://example.com/over/there?name=foo+bar”。所以，只有在“?”之后，空格才可以用加号代替。在其他情况下，空格应编码为 %20。但由于很难正确确定上下文，因此最好不要将空格编码为“+”。
我建议对除RFC 3986 中定义的“未保留”之外的所有字符进行百分比编码，第 2.3 页
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
实现取决于您选择的编程语言。
如果您的 URL 包含国家字符，请先将它们编码为 UTF-8，然后对结果进行百分比编码。
【讨论】：