问题标签 [percent-encoding]

Apache Tomcat (at least before Tomcat 6 ^{see footnote}) treats a percent-encoded slash (%2F) in a URI path just like a regular slash (i.e. as a path delimiter).

So e.g. the servlets example page of Tomcat can be accessed at

• http://localhost:8080/examples/servlets/ and at
• http://localhost:8080/examples%2Fservlets/

This does not make sense to me. The whole point of percent-encoding a reserved character like "/" is to avoid it being treated as a reserved character (in this case a path delimiter). In addition to this, this behaviour is (one) cause of the vulnerability CVE-2007-0450. However, I assume there must have been a reason for this.

• Is there any technical reason why Tomcat treats (ok, used to treat) %2F as a path delimiter?

• Is there some situation where this behaviour is helpful?

Footnote: I realize that due to CVE-2007-0450 Tomcat's default behaviour was changed to reject percent-encoded slashes in the path. However, if this check is disabled (ALLOW_ENCODED_SLASH), the old behavior remains.

结果是http://example.com/servlet?a=x%2520y，其中查询参数值与提供的值不同。奇怪，但这确实遵循 Javadoc：

“百分比字符 ('%') 总是被这些构造函数引用。”

我们可以传递解码后的字符串，a=x y然后我们得到一个合理的（？）结果a=x%20y。

但是如果查询参数值包含一个“&”字符呢？例如，如果值是带有查询参数的 URL 本身，就会发生这种情况。看看这个（错误的）查询字符串： a=b&c。& 符号必须在此处转义 ( a=b%26c)，否则可以将其视为查询参数a=b和一些垃圾 ( c)。如果我将它传递给 URI 构造函数，它会对其进行编码，并返回错误的 URL：...?a=b%2526c

这个问题似乎使 java.util.URI 无用。我在这里错过了什么吗？

答案摘要

java.net.URI 确实知道 URI 的查询部分的存在，但它不了解查询部分的内部结构，每个方案可能不同。例如 java.net.URI 不理解 HTTP 查询部分的内部结构。如果 java.net.URI 将查询视为一个不透明的字符串，并且没有改变它，这不会是一个问题。但它尝试应用一些通用的百分比编码算法，这会破坏 HTTP URL。

因此，我不能使用 URI 类从它的各个部分可靠地组装一个 URL，尽管它有构造函数。我还要提一下，从 Java 7 开始，相对化操作的实现非常有限，仅当一个 URL 是另一个 URL 的前缀时才有效。这两个功能（以及用于这些目的的更精简的界面）是我对 java.net.URI 感兴趣的原因，但它们都不适合我。

最后，我使用 java.net.URL 进行解析，并编写代码以从部分组装 URL 并将两个 URL 相对化。我还检查了 Apache HttpClient URIBuilder 类，虽然它确实了解 HTTP 查询字符串的内部结构，但从 4.3 开始，在处理整个查询部分时，它与 java.net.URI 之类的编码有同样的问题。

The best answers I was able to find for this issue are using XSLT, but I'm just not sure how to apply those answers to my problem.

Basically, DOMDocument is doing a fine job of escaping URLs (in href attributes) that are passed in, but I'm actually using it to build a Twig/Django style template, and I'd rather it leave them alone. Here's a specific example, illustrating the "problem":

Which outputs the following:

Is it possible to NOT percent-encode the href attribute?

If it's not possible directly, can you suggest a concise and reliable workaround? I'm doing other processing, and the DOMDocument usage will have to stay. So perhaps a pre/post processing trick?

我有一个默认值，其中包含一个“%”，我也将其插入到我的论点的帮助文档中。例如：

parse_args() 上的 argparse 错误

当我做：

它返回：

据此： http: //www.degraeve.com/reference/urlencoding.php

字符：ú应该是%FA，但它%C3%BA为什么会这样，我如何解决这个问题而不必做很多字符串替换？

我需要与此链接href="file://attachments/aaaa_#_aaaa.msg" 显然以这种方式不起作用，因为哈希字符#用于锚点。

所以我尝试将其更改为：href="file://attachments/aaaa_%23_aaaa.msg" 但是当我在 IE 中打开 url 时，浏览器正在尝试打开它：href="file://attachments/aaaa_%2523_aaaa.msg" IE is encoding the %character to%25

如何将文件名放在 URL 中以编码和读取#所有浏览器中的哈希字符以下载文件？

我无法更改文件名来删除这个字符，所以我需要一种方法来处理这个问题。

我正在尝试将用户提供的字符串作为 Flask URL 参数传递。 url_for(func_name, param="string with spaces")或类似的生成带有空格的 URL。

如果用户输入带有空格的字符串，则生成的 url 带有空格，它似乎可以工作。

此外，如果我输入一个 URL，%20它似乎会重定向到一个带空格的 url。我认为带有空格的 URL 是个坏主意。

如何让它正常工作（url_for和重定向）？还是我应该接受它？

PS 将用户提供的字符串作为参数传递是否安全？如果不是，我应该如何清理用户输入字符串？

我们已调整旧网站以使用语义 URL，并且 - 由于多种原因 - 无法使用 a/作为分隔符。相反，我们将|其用作分隔符。

例如：

一切正常，只有一个小问题。Google Chrome 和 IE 将 URL 显示为：

我们正在使用对分隔符|进行编码|，但 Chrome 和 IE 仍然用%7C.

Firefox 和 Safari 正确显示 URL！

在研究了 Google 和 SO 之后，对此似乎存在相互矛盾的意见。

我们遇到了 Google Chrome 将|分隔符替换为的问题%7C，而 Firefox 和 Safari 则没有。

这是一个例子：

在为语义 URL 选择分隔符时是否有任何严格的规则要遵循，并且是否有任何强烈的反对（或解决方法时）使用|？

根据RFC 3986，以下字符是保留的，需要进行百分比编码才能在 URI 中使用，而不是作为保留用途： :/?#[]@!$&'()*+,;=

此外，它指定了一些特别未保留的字符：a-zA-Z0-9\-._~

似乎很清楚，通常应该对保留字符进行编码（以防止误解）而不是对未保留的字符进行编码（为了便于阅读），但是不属于任一类别的字符应该如何处理呢？例如{并且}不在任一列表中出现，但它们是标准的 ASCII 字符。

向现代浏览器寻求指导，似乎它们有时具有不同的行为。例如，考虑将 URL 粘贴https://www.google.com/search?q={到 Web 浏览器的地址栏中：

• Chrome 34.0.1847.116 m 不会改变它。
• Firefox 28.0 没有改变它。
• Internet Explorer 9.0 不会改变它。
• Safari 5.1.7 将其更改为https://www.google.com/search?q=%7B

但是，如果粘贴https://www.google.com/#q={（删除“搜索”并将 更改?为 a #，使字符成为片段/哈希的一部分而不是查询字符串），我们会发现：

• Chrome 34.0.1847.116 m 将其更改为https://www.google.com/#q=%7B（通过 JavaScript）
• Firefox 28.0 没有改变它。
• Internet Explorer 9.0 不会改变它。
• Safari 5.1.7 将其更改为https://www.google.com/#q=%7B（在执行 JavaScript 之前）

此外，当使用 JavaScript 异步执行请求时（即使用这个 MDN 示例修改为使用 的 URL ?q={），URL 不会自动进行百分比编码。（我猜这是因为 XMLHttpRequest API 假设 URL 是预先编码/转义的。）

我想（出于与奇怪的客户要求相关的原因）在 URL 的文件名部分中使用{和，而不会（1）破坏事物，理想情况下也不会（2）在现代网络面板中创建难看的百分比编码条目}浏览器的网络检查器/调试器。