有时，空格会将URL编码为+符号，有时会将其编码为%20。有什么区别以及为什么会发生这种情况？
答案 0 :(得分：427)
+表示application/x-www-form-urlencoded内容中仅的空格，例如网址的查询部分：
http://www.example.com/path/foo+bar/path?query+name=query+value
在此网址中，参数名称为query name，其中包含空格，值为query value，但空格为foo+bar，不是 foo bar。
%20是在这些上下文中编码空间的有效方法。因此，如果您需要对字符串进行网址编码以包含在网址的一部分中，则使用%20替换空格并使用%2B加上空格总是安全的。这就是例如。 encodeURIComponent()在JavaScript中有效。不幸的是，这不是urlencode在PHP中的作用（rawurlencode更安全）。
另见 HTML 4.01 Specification application/x-www-form-urlencoded
答案 1 :(得分：46)
http://www.example.com/some/path/to/resource?param1=value1
问号前面的部分必须使用％编码（因此%20用于空格），在问号后，您可以使用%20或+作为空格。如果问号后面需要实际+，请使用%2B。
答案 2 :(得分：26)
所以，这里的答案都有点不完整。在RFC3986中明确定义了使用'％20'来编码URL中的空格，该(RFC1866)定义了如何构建URI。在本规范中没有提及使用'+'来编码空格 - 如果你完全按照这个规范，一个空格必须编码为'％20'。
使用'+'来表示编码空间的提法来自HTML规范的各种形式 - 特别是在描述内容类型'application / x-www-form-urlencoded'的部分中。这用于发布表单数据。
现在，HTML 2.0规范Enterprise Events endpoint在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文档，那肯定是这种情况。
答案 3 :(得分：7)
最好始终将空格编码为％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中定义的“无保留”除外，第2.3页
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
答案 4 :(得分：2)
有什么区别：见其他答案。
使用+代替%20时？如果由于某种原因，您希望使URL查询字符串（+）或散列片段（?.....）更具可读性，请使用#....。示例：您实际上可以阅读：
https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces
（%2B = +）
但以下内容更难阅读:(至少对我而言）
我认为+不太可能破坏任何内容，因为Google使用+（请参阅上面的第一个链接）并且他们可能已经考虑过这个问题。我将自己使用+因为可读+谷歌认为没问题。