编码空格字符的URL:+或%20？

Question

何时将URL中的空格编码为+,何时将其编码为%20？

Answer 1

来自维基百科(重点和链接添加):

当提交已输入HTML表单的数据时,表单字段名称和值将被编码并使用方法GET或POST在HTTP请求消息中发送到服务器,或者历史上通过电子邮件发送到服务器.默认使用的编码基于一般URI百分比编码规则的早期版本,具有许多修改,例如换行标准化和用"+"而不是"%20"替换空格.以这种方式编码的MIME类型的数据是application/x-www-form-urlencoded,并且它当前在HTML和XForms规范中定义(仍然以非常过时的方式).

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

Answer 2

这种混淆是因为到目前为止,URL仍然"被打破".

以" http://www.google.com "为例.这是一个URL.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之前?和+之后.

资源

Answer 3

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

Answer 4

总结一下这里的（有些矛盾的）答案，我认为可以归结为：

| standard      | +   | %20 |
|---------------+-----+-----|
| URL           | no  | yes |
| query string  | yes | yes |
| form params   | yes | no  |
| mailto query  | no  | yes |

所以从历史上看，我认为发生的事情是：

1. RFC 指定了关于 URL 的形式及其编码方式的非常清晰的标准。在这种情况下，查询只是一个“字符串”，没有规范如何对键/值对进行编码
2. HTTP 人员提出了如何在表单参数中对键/值对进行编码的标准，并借用了 URL 编码标准，但空格应编码为+.
3. 网络人员说：很酷，我们有一种方法来编码键/值对，让我们将其放入 URL 查询字符串中

结果：我们最终得到了两种不同的方法来对 URL 中的空格进行编码，具体取决于您所讨论的部分。但它甚至不违反 URL 标准。从 URL 的角度来看，“查询”只是一个黑匣子。如果您想使用百分比编码之外的其他编码：请自行淘汰。

但正如电子邮件示例所示，借用 URL 查询字符串的 form-params 实现可能会出现问题。因此，最终使用 %20 更安全，但可能没有开箱即用的库支持它。

Answer 5

空格只能在URL的"application/x-www-form-urlencoded"内容类型键值对查询部分中编码为"+".这是一个MAY,而不是必须.在其余的URL中,它编码为%20.

在我看来,总是将空格编码为%20,而不是"+",即使在URL的查询部分也是如此,因为它是HTML规范(RFC-1866),它指定空格字符应编码为" +"in"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 ".因此,根据HTML规范,只有在"？"之后,空格才能被加号替换.在其他情况下,空格应编码为%20.但由于很难正确地确定上下文,因此最好不要将空格编码为"+".

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

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

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

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