问题标签 [rfc3986]

人们谈论URL、URI和URN就好像它们是不同的东西，但在肉眼看来它们是一样的。

它们之间有什么可区分的区别？

我需要测试一些现有的 http://URL 解析代码是否符合RFC 3986。

我不想重新发明轮子并碰到各种角落案例。

是否有一些现有的综合测试套件？

我没有指定我使用的语言，因为我希望测试套件足够通用以适应。不过，我愿意接受任何理智的事情。

哪些字符使 URL 无效？

这些是有效的 URL 吗？

• example.com/file[/].html
• http://example.com/file[/].html

RFC 3986 URI：通用语法规范将分号列为保留（子分隔符）字符：

“;”的保留用途是什么 URI 中的分号？就此而言，其他子分隔符的用途是什么（我只知道“&”、“+”和“=”的用途）？

我试图在相关的 RFC，IETF RFC 3986中找到它，但无法弄清楚。

HTTP 的 URI 是否允许 Unicode 或任何类型的非 ASCII？

您能否引用支持您的答案的部分和 RFC。

注意：对于那些可能认为这与编程无关的人来说——确实如此。它与我正在构建的 ISAPI 过滤器有关。

附录

我已经阅读了 RFC 3986 的第 2.5 节。但我认为是当前 HTTP 协议的 RFC 2616 早于 3986，因此我认为它不能与 3986 兼容。此外，即使或当 HTTP RFC已更新，仍然存在合理化问题 - 换句话说，HTTP URI 是否支持所有 RFC3986 附带条件，包括适合包含非 US-ASCII 字符的任何内容？

在 PHP 中，我想比较两个相对 URL 是否相等。问题：URL 的百分比编码可能不同，例如

• /dir/file+file对比/dir/file%20file
• /dir/file(file)对比 /dir/file%28file%29
• /dir/file%5bfile对比 /dir/file%5Bfile

根据RFC 3986，服务器应该以相同的方式对待这些 URI。但如果我==用来比较，我会以不匹配而告终。

所以我正在寻找一个 PHP 函数，它将接受两个字符串并返回它们是否代表相同的 URI（在编码字符中TRUE区分相同字符的编码/解码变体、大写/小写十六进制数字，以及+与%20空格），以及FALSE它们是否不同。

我事先知道这些字符串中只有 ASCII 字符——没有 unicode。

我正在构建一个 JS 库，它需要查看 form[action] 和 a[href] 值并将它们解析为绝对 URL。

例如，我在 http://a/b/c/d;p?q 上遇到“../g”的 href 值（假设没有 <base> 元素）。得到的绝对值是：http://a/b/g。

是否已经有一个 JS 库可以做到这一点？我不得不相信。

有关所需内容的更多信息，请参阅规范： https ://www.rfc-editor.org/rfc/rfc3986#section-5.4

是否有一个类可以String按照 RFC 3986 规范对泛型进行编码？

即："hello world"=>"hello%20world" 不是（RFC 1738）："hello+world"

谢谢

我需要生成href一个 URI。除了需要百分比编码的保留字符之外，一切都很容易，例如链接/some/path;element应该显示为<a href="/some/path%3Belement">（我知道它path;element代表单个实体）。

最初我正在寻找一个可以执行此操作的 Java 库，但我最终自己编写了一些东西（请看下面的 Java 失败的原因，因为这个问题不是 Java 特定的）。

因此，RFC 3986确实建议何时不编码。当我读到它时，当角色属于unreserved (ALPHA / DIGIT / "-" / "." / "_" / "~")班级时，这应该发生。到现在为止还挺好。但是相反的情况呢？RFC 只提到百分比 ( %) 总是需要编码。但是其他人呢？

问题：假设所有非保留的内容都可以/应该进行百分比编码是否正确？例如，左括号(不一定需要编码，但分号需要;。如果我不对其进行编码，我最终会在关注时寻找/first* <a href="/first;second">。但是，正如预期的那样，<a href="/first(second">我总是最终会寻找。/first(second让我感到困惑的是，就 RFC 而言，两者(都;属于同一sub-delims类。正如我想象的那样，对所有非保留的内容进行编码是一个安全的选择，但是对于本地化 URI 而言，SEOability 和用户友好性又如何呢？

现在，Java 库失败了。我试过这样做，
new java.net.URI("http", "site", "/pa;th", null).toASCIISTring()
但这http://site/pa;th并不好。观察到类似的结果：

• javax.ws.rs.core.UriBuilder
• Spring的UriUtils - 我已经尝试encodePath(String, String)过encodePathSegment(String, String)

[*]是点击时在服务器端/first调用的结果HttpServletRequest.getServletPath()<a href="/first;second">

编辑：我可能需要提到这种行为是在 Tomcat 下观察到的，并且我检查了 Tomcat 6 和 7 的行为方式相同。

首先，一些快速的背景知识...作为与第三方供应商集成的一部分，我有一个 C# .Net Web 应用程序，它接收一个 URL，其中包含查询字符串中的一堆信息。该 URL 使用 MD5 哈希和共享密钥进行签名。基本上，我拉入查询字符串，删除它们的哈希，对剩余的查询字符串执行我自己的哈希，并确保我的与提供的匹配。

我正在通过以下方式检索 Uri ......

我的问题源于包含特殊字符（如变音符号（ü））的查询字符串。供应商正在计算基于 RFC 2396 表示的哈希值，即%FC. 我的 C# .Net 应用程序正在根据 RFC 3986 表示计算它的哈希值，即%C3%BC. 不用说，我们的哈希值不匹配，我抛出了我的错误。

奇怪的是，.Net 中 Uri 类的文档说它应该遵循 RFC 2396，除非另外设置为 RFC 3986，但我的web.config文件中没有他们说这种行为所需的条目。

如何强制 Uri 构造函数使用 RFC 2396 约定？

如果做不到这一点，是否有一种简单的方法可以将 RFC 3986 八位字节对转换为 RFC 2396 八位字节？