何时将空间编码为加号(+)或%20？

Question

何时将空间编码为加号(+)或%20？

有时,空格会将URL编码为+符号,有时则会%20.有什么区别,为什么会发生这种情况？

Answer 1

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

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

Run Code Online (Sandbox Code Playgroud)

在这个URL,参数名称是query name有空间和值是query value一个空间,但在路径的文件夹名是名副其实foo+bar,不是 foo bar.

%20是在这些上下文中的任何一个中编码空间的有效方法.因此,如果您需要对字符串进行URL编码以包含在URL的一部分中,则使用%20和替换空格始终是安全的%2B.这就是例如.encodeURIComponent()在JavaScript中.不幸的是,这不是urlencode在PHP中的作用(rawurlencode更安全).

另请参见 HTML 4.01规范应用程序/ x-www-form-urlencoded

@Sisir:没有JS函数可以进行URL表单编码.你可以自然地做`encodeURIComponent(s).replace(/%20/g,'+')`如果你真的需要`+` (21认同)
浏览器将使用`<input name ="查询名称"value ="查询值">"从表单创建`query + name = query + value`参数.它不会从表单创建`query%20name`,但是使用它可以完全安全,例如.如果你把一个表单提交到你自己的'XMLHttpRequest`.如果你有一个带有空格的URL,比如`<a rel="nofollow noreferrer" href="http://www.example.com/foo bar/">`,那么浏览器会将其编码为`%20`以便你修复你的错误,但这可能最好不要依赖. (9认同)
javascript上的什么函数使`foo bar`变为`foo + bar`？ (6认同)
我真的很困惑,我的问题是,当浏览器执行第一个表单时,以及何时执行第二个表单？ (4认同)
这是一个形式混淆的东西的非常非常令人困惑的例子。它与URL无关。 (2认同)

Answer 2

cer*_*ros 52

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

问号之前的部分必须使用%的编码(这样%20的空间),问号之后,你可以使用%20或+一空.如果您+在问号使用后需要实际使用%2B.

Google在其搜索网址中使用+'作为空格(https://www.google.com/#q=perl+equivalent+to+php+urlencode+spaces+as+%2B). (17认同)
因为这是错的.它是旧应用程序/ x-www-form-urlencoded媒体类型的一部分,不适用于URL.此外,`decodeURIComponent`不解码它. (9认同)
@DaveVandenEynde为什么不呢？ (6认同)
是的,它可能是从RFC 1630复制过来的,从来没有真正成为标准.http://tools.ietf.org/html/rfc3986是标准(再次为IPv6或其他东西更新).当然浏览器仍"支持"它,但这意味着什么？它是服务器或客户端代码,它读取查询字符串并对其进行解码,而不是浏览器.浏览器只是来回传递,因为`+`是*保留字符*,它将由浏览器保存. (3认同)
供参考:导轨还解码空间与'+'默认(```{FOO: '酒吧酒吧'}.to_query``` =>```富=栏+ bar```) (2认同)
@DaveVandenEynde（或任何可能知道的人）我倾向于同意你的看法——特别是基于我目前正在处理的一个问题——加号是`旧应用程序/x-www-form-urlencoded 媒体类型的一部分这不适用于 URLs`。但是知道为什么即使在最新的 Java（截至目前为 8 个）类 `java.net.URLEncoder` _` 中，空格字符“” 也被转换为加号“+”`_ ？还有其他情况，像 Java 语言这样的“高代表”软件强制执行反标准**而不是**实际标准（不是浏览器，因为它们支持 + 但也支持实际标准）？ (2认同)
"+"更好,因为URL查询更具可读性.与+相比,%20对普通人来说只是胡言乱语 (2认同)
“+”也比“%20”短2个字节。如果正在优化 URL，这可能很重要。 (2认同)

Answer 3

小智 36

所以,这里的答案都有点不完整.在RFC3986中明确定义了使用'%20'来编码URL中的空格,RFC3986定义了如何构建URI.在本说明书中没有提及使用'+'来编码空格 - 如果你完全按照这个规范,则空格必须编码为'%20'.

使用'+'来表示编码空间的提法来自HTML规范的各种形式 - 特别是在描述内容类型'application/x-www-form-urlencoded'的部分中.这用于发布表单数据.

现在,HTML 2.0规范(RFC1866)在8.2.2节中明确指出,GET请求的URL字符串的Query部分应编码为'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完全由RFC3986覆盖,这意味着空格应该转换为'%20'.如果您要请求HTML文档以外的任何内容,那肯定是这种情况.

Answer 4

Max*_*tin 8

最好始终将空格编码为%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 = ALPHA / DIGIT / "-" / "." / "_" / "~"

Run Code Online (Sandbox Code Playgroud)

在 .Net Framework 中，UrlEncode 在 QueryString 中使用“+”，但在现代 .Net Core 中使用 %20 (3认同)

归档时间：	15 年，6 月前
查看次数：	224555 次
最近记录：	7 年，9 月前