【发布时间】：2011-01-07 17:31:31
【问题描述】：
我想更好地理解 RFC 2396 和整个 URL / URI 的东西，并且由于 Cocoa 的 NSURL 基于 RFC 2396，我寻找一个概述。 RFC 本身对我来说太难阅读了。
【问题讨论】：
-
您可能会在这里找到愿意回答您不理解的具体问题的人。
-
反正 RFC 2396 五年前就被 RFC 3986 淘汰了。
【发布时间】：2011-01-07 17:31:31
【问题描述】：
RFC 3305 可能会有所帮助：
本文档 [...] 解决并试图阐明与 URI 相关的问题。本文档阐述了 URI 空间是如何划分的，以及 URI、URL 和 URN 之间的关系，描述了 URI 方案和 URN 命名空间 id 的注册方式，并提出了有关该主题的继续工作的建议。
【讨论】：
-
+1 - 我希望我知道该文档存在，我已经多次给出了这个解释
我假设您真正的问题是关于整个 URI / URL / URN 拆分。我首先要说这只是术语，在许多情况下它们是可以互换的。
URL 是统一资源定位符：它标识访问“方案”，例如 http:，并包含足够的信息以定位使用该方案的资源.它不一定包含足够的信息来访问该资源：例如，一个 HTTP URL 将带您进入一个页面，但该页面可能有访问的身份验证要求。
URN 是统一资源名称：它也以“方案”开头，然后包含适合该方案的任意信息。 URN 令人困惑，因为虽然有几个预定义的方案，例如“uuid”，但这些方案没有指定用途（与 HTTP 不同）。这不一定是坏事：我喜欢将 URN 用于 XML 命名空间之类的东西，我不希望有任何暗示您可以实际检索与该命名空间相关的内容。
URI 是一个统一资源标识符：一个包含 URL、URN 和一些其他标识符类型的超集。 RFC 提到了 URL 和 URN，但没有详细说明。这是因为它关注的是 URI 的物理构造（一般格式、应该如何编码等），而不是用法。
为挑剔者编辑：假设当我说“以方案开头”时，有文本“（可能由当前上下文暗示）”。
【讨论】：
对于概述，实际 RFC 的摘要和介绍就足够了。您可以挑选出您想要更好地理解的 RFC 的特定部分。
基本上，要更好或更彻底地理解RFC 2396 - 这就是您所要求的（以及概述..），老实说，您不能比阅读 RFC 本身做得更好。对我来说似乎合乎逻辑。
【讨论】：