在 URL 中，空格应该使用 %20 还是 + 编码？ [复制]答案

【问题标题】：In a URL, should spaces be encoded using %20 or +? [duplicate]在 URL 中，空格应该使用 %20 还是 + 编码？ [复制]
【发布时间】：2010-11-15 17:21:16
【问题描述】：

在 URL 中，我应该使用%20 还是+ 对空格进行编码？比如下面这个例子，哪一个是正确的？

www.mydomain.com?type=xbox%20360
www.mydomain.com?type=xbox+360

我们公司倾向于前者，但使用Java方法URLEncoder.encode(String, String)和"xbox 360"（和"UTF-8"）returns the latter。

那么，有什么区别呢？

【问题讨论】：

为了 .net 开发者的利益：HttpUtility.UrlPathEncode 使用 '%20' HttpUtility.UrlEncode 使用 '+.'来源：msdn.microsoft.com/en-us/library/…
@MetaByter 我认为将问题表述为“在 URL 中，我是否应该在 URL 的查询部分使用 %20 或 + 对空格进行编码？”因为虽然您显示的示例仅在查询部分包含空格，但所有读者可能都不清楚答案取决于。或者，您可以提出问题，“在下面的特定 URL 示例中，我应该编码...”

标签： url urlencode url-encoding

【解决方案1】：

这应该不重要，就像将字母 A 编码为 %41 一样。

但是，如果您正在处理的系统无法识别一种形式，那么无论“规范”怎么说，您似乎都只需要给它期望的东西。

【讨论】：

【解决方案2】：

表单数据（用于 GET 或 POST）通常编码为 application/x-www-form-urlencoded：这指定 + 表示空格。

URL 编码为RFC 1738，它指定%20。

理论上我认为你应该在 ? 之前和 + 之后有 %20：

example.com/foo%20bar?foo+bar

【讨论】：

电子邮件链接除外，因为在 ? 后面使用 +es将导致电子邮件打开，+es 仍然在那里。所以：mailto:support@example.org?subject=I%20need%20help

【解决方案3】：

根据W3C（它们是这些东西的官方来源），查询字符串中的空格字符（仅在查询字符串中）可以编码为“%20”或“@987654325 @"。从“建议”下的“查询字符串”部分：

在查询字符串中，加号保留为空格的简写符号。因此，必须对真正的加号进行编码。此方法用于使查询 URI 更容易在不允许空格的系统中传递。

根据RFC2396 的第 3.4 节，这是一般关于 URI 的官方规范，“查询”组件是依赖于 URL 的：

3.4。查询组件查询组件是要被解释的信息字符串资源。
   query         = *uric
在查询组件中，字符“;”、“/”、“?”、“:”、“@”、 "&"、"="、"+"、"," 和 "$" 是保留的。

因此，如果其他软件不接受编码为“+”字符的查询字符串中带有空格的 URL，则它是一个错误。

至于你问题的第三部分，修复URLEncoder.encode() 的输出的一种方法（虽然有点难看）是在返回值上然后call replaceAll("\\+","%20")。

【讨论】：

不要使用编码为 application/x-www-form-urlencoded 的 URLEncoder，而是使用 java.net.URI，它以真正的百分比编码进行编码。

【解决方案4】：

您可以使用任何一种 - 这意味着大多数人选择“+”，因为它更易于阅读。

【讨论】：

【解决方案5】：

对查询值进行编码时，无论是形式、加号还是百分比 20，均有效；但是，由于互联网的带宽不是无限的，您应该使用 plus，因为它少了两个字节。

【讨论】：

过早优化....?
投了赞成票，因为它让我发笑
我会说使用 plus 的一个更好的理由是它比 %20 更适合人类阅读。反正对我来说是这样。

【解决方案6】：

这种混乱是因为 URL 直到今天仍然“损坏”

以“http://www.google.com”为例。这是一个网址。网址是统一资源定位器，实际上是指向网页的指针（在大多数情况下）。 URLs 实际上有一个非常明确的结构自 1994 年第一个规范以来。

我们可以提取关于“http://www.google.com”的详细信息网址：

+---------------+-------------------+   
|      Part     |      Data         |   
+---------------+-------------------+   
|  Scheme       | http              |   
|  Host address | www.google.com    |   
+---------------+-------------------+

如果我们看更多复杂的 URL，例如 “https://bob:bobby@www.lunatech.com:8080/file;p=1?q=2#third”我们可以提取以下信息：

+-------------------+---------------------+
|        Part       |       Data          |
+-------------------+---------------------+
|  Scheme           | https               |
|  User             | bob                 |
|  Password         | bobby               |
|  Host address     | www.lunatech.com    |
|  Port             | 8080                |
|  Path             | /file               |
|  Path parameters  | p=1                 |
|  Query parameters | q=2                 |
|  Fragment         | third               |
+-------------------+---------------------+

每个部分的保留字符不同

对于 HTTP URL，路径片段部分中的空格必须编码为 “%20”（不是，绝对不是“+”），而路径中的“+”字符片段部分可以不编码。

现在在查询部分，空格可以编码为“+”（对于向后兼容性：不要尝试在 URI 中搜索它标准）或“%20”，而“+”字符（因此歧义）必须转义为“%2B”。

这意味着必须对“蓝色+浅蓝色”字符串进行编码在路径和查询部分有所不同： “http://example.com/blue+light%20blue?blue%2Blight+blue”。从那里你可以推断编码一个完全构造的 URL 是不可能的没有 URL 结构的句法意识。

这归结为

你应该在?之前有%20，在之后有+

Source

【讨论】：