在 URL 中,我应该使用 %20还是 +对空格进行编码?例如,在下面的例子中,哪一个是正确的?
%20
+
www.mydomain.com?type=xbox%20360 www.mydomain.com?type=xbox+360
我们公司倾向于前者,但是使用带有 "xbox 360"(和 "UTF-8") 返回后者的 Java 方法 URLEncoder.encode(String, String)。
"xbox 360"
"UTF-8"
URLEncoder.encode(String, String)
那有什么区别呢?
它 不应该的问题,任何超过如果你编码的字母 A 为% 41。
然而,如果您正在处理一个不能识别一种形式的系统,那么似乎不管“规范”说什么,您都必须给它所期望的。
表单数据(用于 GET 或 POST)通常编码为 application/x-www-form-urlencoded: 这指定了空格的 +。
application/x-www-form-urlencoded
URL 被编码为指定 %20的 RFC 1738。
理论上我认为你应该在 ?之前和之后有% 20:
?
example.com/foo%20bar?foo+bar
根据 W3C(它们是这些东西的官方来源) ,查询字符串中的空格字符(只在查询字符串中)可以编码为“ %20”或“ +”。来自“建议”下的“查询字符串”部分:
在查询字符串中,加号保留为空格的简写符号。因此,必须对实加号进行编码。此方法用于使查询 URI 在不允许空格的系统中更容易传递。
根据 RFC2396第3.4节(一般而言,这是有关 URI 的官方规格) ,“查询”组件是与 URL 有关的:
3.4. 查询组件 查询组件是要由 资源。 query = *uric 在查询组件中,字符“ ;”、“/”、“ ?”、“ :”、“@”、, 保留“ &”、“ =”、“ +”、“”和“ $”。
3.4. 查询组件 查询组件是要由 资源。
query = *uric
在查询组件中,字符“ ;”、“/”、“ ?”、“ :”、“@”、, 保留“ &”、“ =”、“ +”、“”和“ $”。
因此,如果其他软件不接受在查询字符串中编码为“ +”字符的空格的 URL,那么它就是一个错误。
至于问题的第三部分,修复 URLEncoder.encode()输出的一种方法(尽管有点难看)是在返回值上修复 打电话 replaceAll("\\+","%20")。
URLEncoder.encode()
replaceAll("\\+","%20")
你可以使用任意一种——这意味着大多数人选择“ +”,因为它更具人类可读性。
当编码查询值时,无论是形式(plus)还是百分比 -20,都是有效的; 但是,由于互联网的带宽不是无限的,因此应该使用 plus,因为它少了两个字节。
这种混淆是因为 URL 至今仍然是“破碎的”
以“ http://www.google.com”为例,这是一个 URL 是一个统一资源定位符,实际上是一个指向网页的指针 (在大多数情况下)。 URL 实际上有一个非常明确的结构 从1994年第一个规范开始。 我们可以提取关于“ http://www.google.com”的详细信息 网址:
以“ http://www.google.com”为例,这是一个 URL 是一个统一资源定位符,实际上是一个指向网页的指针 (在大多数情况下)。 URL 实际上有一个非常明确的结构 从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”(不,绝对不是“ +”) ,而路径中的“ +”字符 片段部分可以不编码。 现在在查询部分,空格可以编码为“ +”(for 向后兼容性: 不要尝试在 URI 中搜索它 标准)或“% 20”,而“ +”字符(因此 必须转义为“% 2B”。 这意味着必须对“ blue + light blue”字符串进行编码 不同的路径和查询部分: “ http://example.com/blue+light%20blue?blue%2Blight+blue”从那里开始 您可以推断,编码一个完全构造的 URL 是不可能的 没有 URL 结构的语法意识。
每个部分的保留字符都不同
对于 HTTP URL,必须将路径片段部分中的空格编码为 “% 20”(不,绝对不是“ +”) ,而路径中的“ +”字符 片段部分可以不编码。
现在在查询部分,空格可以编码为“ +”(for 向后兼容性: 不要尝试在 URI 中搜索它 标准)或“% 20”,而“ +”字符(因此 必须转义为“% 2B”。
这意味着必须对“ blue + light blue”字符串进行编码 不同的路径和查询部分: “ http://example.com/blue+light%20blue?blue%2Blight+blue”从那里开始 您可以推断,编码一个完全构造的 URL 是不可能的 没有 URL 结构的语法意识。
归根结底就是
你应该有 %20之前的 ?和 +之后
来源