在 URL 中,空格应该使用 %20 还是 + 编码? [复制]
Posted
技术标签:
【中文标题】在 URL 中,空格应该使用 %20 还是 + 编码? [复制]【英文标题】:In a URL, should spaces be encoded using %20 or +? [duplicate] 【发布时间】: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 示例中,我应该编码...” 【参考方案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
【讨论】:
以上是关于在 URL 中,空格应该使用 %20 还是 + 编码? [复制]的主要内容,如果未能解决你的问题,请参考以下文章
HTTP 冷知识 | HTTP 请求中,空格应该被编码为 %20 还是 + ?