何时编码空格加（+）或％20？
有时空格会将url编码为+符号，其他时间则为%20 。 有什么区别，为什么会这样呢？
+表示仅在application/x-www-form-urlencoded内容中的空格，例如URL的查询部分：
http://www.example.com/path/foo+bar/path?query+name=query+value
在这个URL中，参数名称是带有空格的query name ，值是带有空格的query value ，但path中的文件夹名称实际上是foo+bar 而不是 foo bar 。
%20是在这些上下文中编码空间的有效方法。 因此，如果您需要对URL中的string进行url编码，那么将空格replace为%20并使用%2B总是安全的。 这是例如。 encodeURIComponent()在JavaScript中执行。 不幸的是，这不是什么urlencode在PHP（ rawurlencode更安全）。
另请参见HTML 4.01规范应用程序/ x-www-form-urlencoded
http://www.example.com/some/path/to/resource?param1=value1
问号之前的部分必须使用％编码（因此%20为空格），问号后可以使用%20或+作为空格。 如果你需要一个实际的+问号后使用%2B 。
总是将空格编码为％20，而不是“+”。
它是RFC-1866（HTML 2.0规范），它指定空间字符应该在“application / x-www-form-urlencoded”内容types键值对中编码为“+”。 （见第8.2.1段第1项）。 这种编码forms数据的方法也在稍后的HTML规范中给出，查找关于application / x-www-form-urlencoded的相关段落。
以下是RFC-1866允许将空格编码为加号的URL中的这样一个string的示例：“http://example.com/over/there?name=foo+bar”。; 所以，只有在“？”之后，根据RFC-1866，空格可以被replace。 在其他情况下，空格应该被编码为％20。 但是由于很难确定上下文，因此最好不要将空格编码为“+”。
我build议百分比编码除RFC-3986，第2.3节中定义的“unreserved”之外的所有字符
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
有什么区别：请参阅其他答案。
当使用+而不是%20 ？ 使用+如果出于某种原因，您希望使URL查询string（ ?..... ）或哈希片段（ #.... ）更具可读性。 例如：你实际上可以阅读这个：
https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces（％2B = +）
但是下面的阅读很难：（至less对我来说）
我认为+不太可能破坏任何东西，因为Google使用了+ （参见上面的第一个链接），他们可能已经考虑过了。 我会用+自己只是因为可读性+谷歌认为它是好的。
所以这里的答案都是不完整的。 使用'％20'来对URL中的空格进行编码在RFC3986中明确定义， RFC3986定义了如何构buildURI。 在本规范中没有提及使用“+”来编码空格 – 如果你完全按照这个规范，一个空格必须被编码为“％20”。
提及使用“+”来表示编码空间来自HTML规范的各种版本 – 特别是在描述内容types“application / x-www-form-urlencoded”的章节中。 这用于发布表单数据。
现在，HTML 2.0规范（RFC1866）在第8.2.2节中明确指出，GET请求的URLstring的Query部分应该被编码为“application / x-www-form-urlencoded”。 这在理论上表明，在查询string的URL中（'？'后面）使用“+”是合法的。
但是…真的吗？ 请记住，HTML本身就是一个内容规范，带有查询string的URL可以与HTML以外的内容一起使用。 此外，尽pipeHTML规范的更高版本继续在'application / x-www-form-urlencoded'内容中将'+'定义为合法的，他们完全省略了将GET请求查询string定义为该types的部分。 实际上，在HTML 2.0规范之后，没有任何关于查询string编码的内容。
这留下了我们的问题 – 这是有效的吗？ 当然，在查询string中支持“+”的遗留代码很多，并且有很多代码也会生成它。 所以赔率是好的，你不会因为使用'+'而破坏。 （事实上，我最近做了所有的研究，因为我发现一个主要的网站在GET查询中没有接受'％20'作为一个空格，他们实际上没有解码任何百分比的编码字符。也可能是相关的。）
但是从规范的纯粹阅读中，如果没有将HTML 2.0规范中的语言结转到更高的版本中，则URL完全由RFC3986覆盖，这意味着空格应该被转换为“％20”。 而且，如果您要求HTML文档以外的其他应用程序，则应该是这种情况。
