编码空格字符的URL：+或％20？

URL中的空格何时编码为+，何时编码为%20？

从维基百科（已添加重点和链接）：

提交已输入HTML表单的数据后，将使用GET或POST方法或历史上通过电子邮件的形式，以HTTP请求消息的形式对表单字段名称和值进行编码并发送到服务器。默认情况下，使用的编码基于URI百分比编码规则的早期版本，并进行了许多修改，例如换行符标准化和将空格替换为“ +”而不是“％20”。以这种方式编码的数据的MIME类型是application / x-www-form-urlencoded，并且当前已在HTML和XForms规范中定义（仍然以非常过时的方式）。

因此，URL中的表单数据采用use的修改形式时，实际百分比编码%20使用+。因此，您最有可能只+在查询字符串后的URL中看到?。

造成这种混乱的原因是，到目前为止，URL仍然“中断”。

以“ http://www.google.com ”为例。这是一个URL。URL是统一资源定位符，实际上是指向网页的指针（在大多数情况下）。自1994年发布第一个规范以来，URL实际上具有定义明确的结构。

我们可以提取有关“ http://www.google.com ” URL的详细信息：

+---------------+-------------------+
|      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”。

这意味着必须在路径和查询部分中对“ blue + light blue”字符串进行不同的编码：

“ http://example.com/blue+light%20blue?blue%2Blight+blue ”。

从那里您可以推断出，如果没有句法意识的URL结构，就不可能对完整构造的URL进行编码。

归结为：

您应该在%20之前?和+之后。

资源

我会推荐%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+'

在URL的“应用程序/ x-www-form-urlencoded”内容类型键值对查询部分中，只能将空格编码为“ +”。我认为这是5月，而不是必须。在其余的URL中，其编码为％20。

我认为，最好在URL的查询部分始终将空格编码为％20，而不是“ +”，因为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 ”。因此，只有在“？”之后，空格才能被pluses代替。在其他情况下，空格应编码为％20。但是，由于很难正确地确定上下文，因此最佳实践是永远不要将空格编码为“ +”。

我建议对所有字符进行百分比编码，但RFC-3986，p.2.3中定义的“未保留”除外

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

实现取决于您选择的编程语言。

如果您的URL包含国家字符，请先将其编码为UTF-8，然后对结果进行百分比编码。