有时空格会将URL编码为+号,有时则为%20。有什么不同?为什么会发生这种情况?


当前回答

有什么不同?请看其他答案。

什么时候我们应该用+代替%20?如果出于某种原因,您希望使URL查询字符串(?.....)或散列片段(#....)更具可读性,则使用+。例子:你可以这样读:

https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces (%2B = +)

但下面的内容就很难读了(至少对我来说):

https://www.google.se/#q=google%20doesn%27t%20oops%20:%20%20this%20text%20%2B%20is%20different%20spaces

我认为+不太可能破坏任何东西,因为谷歌使用+(见上面的第一个链接),他们可能已经考虑过这一点。我将使用+ myself,因为readable +谷歌认为这是可以的。

其他回答

+表示只在application/x-www-form- urlenencoded内容中出现空格,例如URL的查询部分:

http://www.example.com/path/foo+bar/path?query+name=query+value

在这个URL中,参数名称是带空格的查询名称,值是带空格的查询值,但是路径中的文件夹名称是字面上的foo+bar,而不是foo bar。

%20是在这两种上下文中编码空格的有效方法。因此,如果您需要对字符串进行URL编码以包含在URL的一部分中,那么用%20替换空格,用%2B替换加号总是安全的。这就是JavaScript中encodeURIComponent()所做的。不幸的是,这不是urlencode在PHP中所做的(rawurlencode更安全)。

另请参阅

HTML 4.01规范应用程序/x-www-form-urlencoded

出于兼容性考虑,最好总是将空格编码为“%20”,而不是“+”。

它是RFC 1866 (HTML 2.0规范),它规定空格字符应该在“application/x-www-form-urlencoded”内容类型的键-值对中编码为“+”。(见第8.2.1段。第(1)。这种编码表单数据的方式也在后面的HTML规范中给出了,寻找有关application/x-www-form-urlencoded的相关段落。

下面是一个URL字符串的例子,RFC 1866允许编码空格作为加号:"http://example.com/over/there?name=foo+bar"。因此,根据RFC 1866,只有在"?"后面,空格才能被加号取代。在其他情况下,空格应该编码为%20。但是由于很难确定上下文,所以最好不要将空格编码为“+”。

我建议对除RFC 3986, p.2.3中定义的“unreserved”之外的所有字符进行百分比编码。

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

当您希望将空格编码为“+”(一个字节)而不是“%20”(三个字节)时,唯一的情况是您确定如何解释上下文,并且当查询字符串的大小非常重要时。

http://www.example.com/some/path/to/resource?param1=value1

问号前面的部分必须使用%编码(因此%20表示空格),问号后面可以使用%20或+表示空格。如果需要在问号后面加一个+,请使用%2B。

所以,这里的答案都有点不完整。使用“%20”来编码url中的空格在RFC 3986中明确定义,它定义了如何构建URI。在这个规范中没有提到使用'+'来编码空格——如果只使用这个规范,空格必须被编码为'%20'。

使用“+”作为编码空间的说法来自于HTML规范的各种版本——特别是在描述内容类型“application/x-www-form-urlencoded”的部分。这用于发布表单数据。

现在,HTML 2.0规范(RFC 1866)在8.2.2节中明确指出,GET请求的URL字符串的查询部分应该编码为'application/x-www-form-urlencoded'。从理论上讲,这表明在查询字符串的URL中(在'?'之后)使用'+'是合法的。

但是…真的吗?请记住,HTML本身就是一种内容规范,带有查询字符串的url可以用于HTML以外的内容。此外,虽然HTML规范的后续版本继续将“+”定义为“application/x-www-form-urlencoded”内容中的合法类型,但它们完全省略了将GET请求查询字符串定义为该类型的部分。事实上,在HTML 2.0规范之后的任何规范中都没有提到查询字符串编码。

这给我们留下了一个问题——它有效吗?当然,有很多遗留代码支持查询字符串中的'+',也有很多代码生成它。所以如果你使用'+',你就不会崩溃。(事实上,我最近做了所有关于这方面的研究,因为我发现一个主要站点无法接受GET查询中的'%20'作为空间。他们实际上无法解码任何百分比编码的字符。所以你使用的服务也可能是相关的。)

但是从规范的纯粹阅读来看,没有将HTML 2.0规范中的语言带入后期版本,url完全由RFC 3986覆盖,这意味着空格应该转换为'%20'。当然,如果你请求的不是HTML文档,就应该是这种情况。

有什么不同?请看其他答案。

什么时候我们应该用+代替%20?如果出于某种原因,您希望使URL查询字符串(?.....)或散列片段(#....)更具可读性,则使用+。例子:你可以这样读:

https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces (%2B = +)

但下面的内容就很难读了(至少对我来说):

https://www.google.se/#q=google%20doesn%27t%20oops%20:%20%20this%20text%20%2B%20is%20different%20spaces

我认为+不太可能破坏任何东西,因为谷歌使用+(见上面的第一个链接),他们可能已经考虑过这一点。我将使用+ myself,因为readable +谷歌认为这是可以的。