有时，空格会将URL编码为+符号，有时会将其编码为%20 。 有什么区别，为什么会发生这种情况？
#1楼
+表示仅在application/x-www-form-urlencoded内容中的空格，例如URL的查询部分：
http://www.example.com/path/foo+bar/path?query+name=query+value
在此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
#2楼
有什么区别：见其他答案。
使用+而不是%20 ？ 使用+如果由于某种原因，你想的网址查询字符串（ ?..... ）或哈希代码（ #.... ）更具可读性。 示例：您实际上可以阅读：
https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces （ %2B = +）
但以下内容更难阅读:(至少对我而言）
我认为+不太可能破坏任何东西，因为Google使用+ （参见上面的第一个链接）并且他们可能已经考虑过这个问题了。 我将使用+我自己只是因为可读+谷歌认为它没关系。
#3楼
最好始终将空格编码为％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 / "-" / "." / "_" / "~"
#4楼
所以，这里的答案都有点不完整。 在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文档以外的任何内容，那肯定是这种情况。
#5楼
http://www.example.com/some/path/to/resource?param1=value1
问号前面的部分必须使用％编码（因此空格为%20 ），问号后可以使用%20或+作为空格。 如果您在问号后需要实际+ ，请使用%2B 。
