人们谈论 URLs、URIs 和 URNs 好像它们是不同的东西，但它们看起来是一样的肉眼。
它们之间有什么区别？
【问题讨论】：
( URIs ( URLs ) )
URIs 识别 和 URLs 定位；但是，定位器也是标识符，所以每个 URL 也是一个 URI，但也有不是 URL 的 URI。
这是我的名字，这是一个标识符。 它就像一个 URI，但不能是一个 URL，因为它不会告诉你我的位置或如何联系我。 在这种情况下，仅在美国，它也恰好识别出至少 5 个其他人。
这是一个定位器，它是该物理位置的标识符。 它既像 URL 又像 URI（因为所有 URL 都是 URI），并且还将我 indirectly 标识为“...的居民”。 在这种情况下，它会唯一标识我，但如果我有室友，情况就会改变。
我说“喜欢”是因为这些示例不符合要求的语法。
来自Wikipedia：
在计算中，统一资源定位符 (URL) 是统一资源标识符 (URI) 的子集，它指定已识别资源的可用位置以及检索该资源的机制。 在流行用法以及许多技术文档和口头讨论中，它经常被错误地用作 URI 的同义词，... [强调我的]
由于这种常见的混淆，许多产品和文档错误地使用一个术语而不是另一个术语，指定它们自己的区别，或者将它们同义地使用。
我的名字，Roger Pate，可能类似于 URN（统一资源名称），除了 much more regulated 并且旨在空间和时间都是唯一的。
因为我目前与其他人共享此名称，所以它不是全球唯一的，也不适合作为 URN。不过，就算没有其他家族用过这个名字，我也是以我祖父的名字命名的，所以也不会随着时间的推移而独树一帜。即使那不是这样，以我的名字命名我的后代的可能性也使得它不适合作为 URN。
在这种严格的唯一性约束中，URN 与 URL 不同，尽管它们都共享 URI 的语法。
【讨论】：
URNs are different from URLs in this rigid uniqueness constraint 这是否意味着 URL 不能唯一标识一个位置？
来自RFC 3986：
URI 可以进一步分类为定位符、名称或两者。这 术语“统一资源定位器”（URL）指的是 URI 的子集 除了识别资源之外，还提供了一种方法 通过描述资源的主要访问机制来定位资源 （例如，它的网络“位置”）。术语“统一资源名称” (URN) 在历史上曾用于指代以下两个 URI “urn”方案[RFC2141]，要求保持全局唯一 即使资源不复存在或变为 不可用，以及具有名称属性的任何其他 URI。
所以所有的 URL 都是 URI，所有的 URN 都是 URI——但是 URN 和 URL 是不同的，所以你不能说所有的 URI 都是 URL。
如果您还没有阅读过Roger Pate's answer，我建议您也阅读一下。
【讨论】：
[ 或 ]，这是因为规范说“不应该”而不是“不应该”。
java.net.URI doc 本身说“每个 URL 都是一个 URI，抽象地说，但不是每个 URI 都是一个 URL”。而java.net.URL 做了一些奇怪的事情，比如通过将主机名解析为 IP 地址来检查 URL 的相等性（这似乎首先与 RFC 3986 sec 6 不一致，并破坏了 w 虚拟主机）。我认为这只是意味着 Java 标准库有一些不一致的类行为。
URI 是一种使用数字、字母和符号组成的短字符串来识别文档的标准。它们由RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax 定义。 URL、URN 和 URC 都是 URI 的类型。
包含有关如何从其位置获取资源的信息。例如：
http://example.com/mypage.htmlftp://example.com/download.zipmailto:user@example.comfile:///home/user/file.txttel:1-888-555-5555http://example.com/resource?foo=bar#fragment/other/link.html（相对 URL，仅在另一个 URL 的上下文中有用）URL 总是以协议 (http) 开头，通常包含网络主机名 (example.com) 和文档路径 (/foo/mypage.html) 等信息。 URL 可能有查询参数和片段标识符。
通过唯一且持久的名称标识资源，但不一定告诉您如何在 Internet 上找到它。它通常以前缀urn: 开头例如：
urn:isbn:0451450523 通过 ISBN 号识别一本书。urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 全局唯一标识符urn:publishing:book - 将文档标识为书籍类型的 XML 命名空间。URN 可以识别想法和概念。它们不限于识别文件。当 URN 确实表示文档时，它可以通过“解析器”转换为 URL。然后可以从 URL 下载该文档。
指向关于文档的元数据而不是文档本身。 URC 的一个示例是指向页面的 HTML 源代码，例如：view-source:http://example.com/
数据可以直接放入 URI 中，而不是在 Internet 上定位或命名。一个例子是data:,Hello%20World。
HTML 的 W3 规范说 href of an anchor tag 可以包含一个 URI，而不仅仅是一个 URL。您应该可以输入一个 URN，例如 <a href="urn:isbn:0451450523">。然后，您的浏览器会将该 URN 解析为 URL 并为您下载图书。
据我所知，现代网络浏览器确实实现了数据 URI 方案。
没有。相对 URL 和绝对 URL 都是 URL（和 URI）。
没有。带有和不带有查询参数的 URL 都是 URL（和 URI）。
没有。带有和不带有片段标识符的 URL 都是 URL（和 URI）。
没有。 URL 被定义为 URI 的严格子集。如果解析器允许 URL 中的字符但 URI 中不允许，则解析器中存在错误。规范详细说明了 URL 和 URI 的哪些部分允许使用哪些字符。某些字符可能只允许在 URL 的某些部分出现，但字符本身并不是 URL 和 URI 之间的区别。
是的。 W3C 意识到对此有很多困惑。他们发布了URI clarification document，表示现在可以互换使用术语 URL 和 URI（表示 URI）。将 URI 严格划分为 URL、URN 和 URC 等不同类型已不再有用。
URN 的定义现在比我上面所说的要宽松。 latest RFC on URIs 表示任何 URI 现在都可以是 URN（不管它是否以 urn: 开头），只要它具有“名称的属性”。也就是说：即使资源不再存在或变得不可用，它也是全局唯一且持久的。示例：HTML 文档类型中使用的 URI，例如 http://www.w3.org/TR/html4/strict.dtd。即使 w3.org 网站上的页面被删除，该 URI 仍将继续命名 HTML4 过渡文档类型。
【讨论】：
file:// 前缀。尽管浏览器通常会处理非 URL 格式的文件路径。 Mozilla publishes their test cases for file URLs.
【讨论】：
ISBN 0486275574 也为文本命名，因此有资格作为 URN。我选择一种我认为读者更熟悉的格式。
这些是一些写得很好但冗长的答案。以下是就 CodeIgniter 而言的区别：
网址 - http://example.com/some/page.html
URI - /some/page.html
简单地说，URL 是在任何地方识别任何资源的完整方法，并且可以有不同的协议，如 FTP、HTTP、SCP 等。
URI 是当前域上的资源，因此需要的信息较少。
在 CodeIgniter 使用 URL 或 URI 这个词的每一个例子中，这就是他们所说的区别，尽管在网络的宏伟计划中，它并不是 100% 正确的。
【讨论】：
/some/page.html 不是 URI。它是一个“relative-ref”，是一种“URI-reference”。结合基本 URI 上下文，它可以被解析为一个 URI，但它本身并不是一个 URI。见Section 4.1 of RFC 3986。 CodeIgniter 可能使用错误的术语，应该指出这一点； Q（当前编辑的）不是 CodeIgniter 特有的。
首先让你的头脑摆脱混乱，把它简单化，你就会明白。
URI => 统一资源标识符 标识资源的完整地址，即位置、名称或两者兼而有之。
URL => 统一资源定位符 标识资源的位置。
URN => 统一资源名称 标识资源的名称
示例
我们有地址https://www.google.com/folder/page.html，在哪里，
URI(统一资源标识符) => https://www.google.com/folder/page.html
URL(统一资源定位器) => https://www.google.com/
URN(统一资源名称) => /folder/page.html
URI => (URL + URN) 或仅 URL 或仅 URN
【讨论】：
对已经发布的答案的一个小补充，这是一个总结理论的维恩图（来自 Prateek Joshi 的美丽explanation）：
还有一个例子（也来自 Prateek 的网站）：
【讨论】：
#posts 片段标识符可能是 URL 的一部分
身份 = 名称和位置
每个 URL(Uniform Resource Locator) 都是一个 URI(Uniform Resource Identifier），抽象地说，但不是每个 URI 都是 URL。 URI还有一个子类是URN（Uniform Resource Name），它是一个命名资源，但没有指定如何定位他们，像mailto，news，ISBN是URIs。 Source
URN：
urn:[namespace identifier]:[namespace specific string]
arn:partition:service:region:account-id:resource
网址：
[scheme]://[Domain][Port]/[path]?[queryString]#[fragmentId]
类比：
联系一个人：驾驶（协议其他 SMS、电子邮件、电话）、地址（主机名、其他电话号码、电子邮件 ID）和人名（具有相对路径的对象名称）。
【讨论】：
mailto URL 关联的资源？
这是我作为网络专业人士遇到的最令人困惑且可能不相关的主题之一。
据我了解，URI 是对某事物的描述，遵循公认的格式，可以同时定义某事物的唯一名称（标识）或位置。
有两个基本子集：
我倾向于认为 URN 类似于 GUID。它们只是为事物提供唯一名称的标准化方法。就像在使用公司名称的命名空间声明中一样——它并不像在服务器上的某个地方有一个资源来对应那一行文本——它只是唯一地标识了一些东西。
我也倾向于完全避免使用 URI 一词，并且仅在适当的情况下使用 URL 或 URN 来讨论事物，因为它会引起很多混乱。我们真正应该尝试为人们回答的问题与其说是语义，不如说是在遇到这些术语时如何识别它们是否存在任何实际差异，从而改变编程情况的方法。例如，如果有人在对话中纠正我并说，“哦，那不是 URL，它是 URI”，我知道他们已经满了。如果有人说“我们使用 URN 来定义资源”，我更可能理解我们只是唯一地命名它，而不是在服务器上定位它。
如果我离基地很远，请告诉我！
【讨论】：
redirect_url 而不是 redirect_uri，会有人真正关心吗？
URI => http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
URL 是 URI 的子集（也包含 URN）。
基本上，URI 是一个通用标识符，其中 URL 指定位置，URN 指定名称。
【讨论】：
[ 和 ] 制作 vaid URL，但不能使用 URI。
在考虑 URI 时我喜欢使用的另一个示例是 XML 文档的 xmlns 属性：
<rootElement xmlns:myPrefix="com.mycompany.mynode">
<myPrefix:aNode>some text</myPrefix:aNode>
</rootElement>
在这种情况下，com.mycompany.mynode 将是一个 URI，它为在我的 XML 文档中使用它的所有元素唯一标识“myPrefix”命名空间。这不是一个 URL，因为它仅用于识别，而不是用于定位某些东西本身。
【讨论】：
They're the same thing。 URI 是 URL 的概括。最初，URI 计划分为 URL（地址）和 URN（名称），但后来 URL 和 URI 之间几乎没有区别，并且 http URI 被用作命名空间，即使它们实际上并没有找到任何资源。
【讨论】：
由于难以清楚地区分 URI 和 URL，据我所知，W3C 不再区分 URI 和 URL (http://www.w3.org/Addressing/)。
【讨论】：
URI、URL、URN
如上图所示，这里有三个不同的组件在起作用。在讨论此类问题时，通常最好找到源头，所以这里是 Tim Berners-Lee 等人的摘录。人。在 RFC 3986: Uniform Resource Identifier (URI): Generic Syntax:
统一资源标识符 (URI) 是一个紧凑的序列 标识抽象或物理资源的字符。
URI 可以进一步分类为定位符、名称或两者。这 术语“统一资源定位器”（URL）是指 URI 的子集 除了识别资源之外，还提供了一种方法 通过描述资源的主要访问机制来定位资源 （例如，它的网络“位置”）。
【讨论】：
URI 是 URL 和 URN 的超类。维基百科有一个关于它们的fine article，并带有指向正确 RFC 集的链接。
【讨论】：
网址
URL 是 URI 的一种特殊形式，它定义了特定资源的网络位置。与 URN 不同，URL 定义了如何获取资源。我们每天都使用http://example.com等形式的URL。但URL不一定是HTTP URL，也可以是ftp://example.com等。
URI
URI 通过位置、名称或两者来标识资源。大多数情况下，我们大多数人使用定义资源位置的 URI。在我看来，URI 可以通过名称和位置来识别资源这一事实导致了很多混乱。 URI 有两个特化，称为 URL 和 URN。
URL和URI的区别
URI 是某些资源的标识符，但 URL 为您提供获取该资源的特定信息。 URI 是一个 URL，正如一位评论者指出的那样，现在在描述应用程序时使用 URL 被认为是不正确的。通常，如果 URL 描述了资源的位置和名称，则使用的术语是 URI。由于我们大多数人每天都会遇到这种情况，因此 URI 是正确的术语。
【讨论】：
维基百科将在此处提供您需要的所有信息。引用http://en.wikipedia.org/wiki/URI:
URL 是一个 URI，它除了标识资源外，还通过描述资源的主要访问机制或网络“位置”来提供对资源进行操作或获取资源表示的方法。
【讨论】：
URI 通过位置、名称或两者来标识资源。大多数情况下，我们大多数人使用定义资源位置的 URI。在我看来，URI 可以通过名称和位置来识别资源这一事实导致了很多混乱。 URI 有两个特化，称为 URL 和 URN。
URL 是 URI 的一种特殊形式，它定义了特定资源的网络位置。与 URN 不同，URL 定义了如何获取资源。我们每天都使用http://stackoverflow.com等形式的URL。但URL不一定是HTTP URL，也可以是ftp://example.com等。
【讨论】：
【讨论】：
尽管术语 URI 和 URL 是严格定义的，但许多术语将其用于其他用途。
我们以 Apache 为例。如果从 Apache 服务器请求 http://example.com/foo，您将设置以下环境变量：
REDIRECT_URL: /foo
REQUEST_URI：/foo
启用 mod_rewrite 后，您还将拥有以下变量：
REDIRECT_SCRIPT_URL: /foo
REDIRECT_SCRIPT_URI: http://example.com/foo
SCRIPT_URL: /foo
SCRIPT_URI: http://example.com/foo
这可能是一些混乱的原因。
【讨论】：
通读帖子后，我发现了一些非常相关的 cmets。简而言之，URL 和 URI 定义之间的混淆部分是基于哪个定义取决于哪个定义，以及软件开发中 URI 一词的非正式使用。
根据定义，URL 是 URI [RFC2396] 的子集。 URI 包含 URN 和 URL。 URI 和 URL 都有自己的特定语法，赋予它们是 URI 或 URL 的状态。 URN 用于唯一标识资源，而 URL 用于定位资源。请注意，一个资源可以有多个 URL，但只能有一个 URN。[RFC2611]
作为 Web 开发人员和程序员，我们几乎总是关注 URL，因此也关注 URI。现在，一个 URL 被专门定义为包含所有部分 scheme:scheme-specific-part，例如 https://stackoverflow.com/questions。这是一个 URL，它也是一个 URI。现在考虑嵌入在页面中的相对链接，例如 ../index.html。根据定义，这不再是 URL。它仍然是所谓的“URI-reference”[RFC2396]。
我相信当使用 URI 这个词来指代相对路径时，“URI-reference”实际上就是我们所想到的。因此，非正式地，软件系统使用 URI 来指代相对路径，使用 URL 来指代绝对地址。所以从这个意义上说，相对路径不再是 URL，而是 URI。
【讨论】：
【讨论】：
这是我的简化：
URN：唯一的资源名称，即“what”（例如 urn:issn:1234-5678 ）。这是唯一的......因为没有两个不同的文档可以有相同的骨灰盒。有点像“uuid”
URL：“在哪里”可以找到它（例如 https://google.com/pub?issnid=1234-5678 .. 或 ftp://somesite.com/doc8.pdf)
URI：可以是 URN 或 URL。这个模糊的定义要归功于 W3C 和 IETF 产生的 RFC 3986。
URI 的定义多年来发生了变化，因此大多数人感到困惑是有道理的。但是，您现在可以放心，您可以将 http://somesite.com/something 引用为 URL 或 URI ...无论哪种方式，您都是正确的（至少目前是这样...）
【讨论】：
为了回答这个问题，我将依靠an answer I modified to another question。 URI 的一个很好的例子是您如何识别 Amazon S3 资源。让我们来：
s3://www-example-com/index.html [图。 1]
我作为缓存副本创建的
http://www.example.com/index.html [图。 2]
在亚马逊的 S3-US-West-2 数据中心中。
即使 StackOverflow 允许我超链接到 s3:// protocol 方案，它对您定位资源也没有任何好处。因为它标识一个资源，图。 1 是一个有效的 URI。它也是一个有效的 URN，因为 Amazon 要求存储桶（URI 的 authority 部分的术语）在数据中心中是唯一的。 对定位很有帮助，但它并不表示数据中心。因此它不能用作 URL。
那么，在这种情况下，URI、URL 和 URN 有何不同？
注意： RFC 3986 将 URI 定义为 scheme://authority/path?query#fragment
【讨论】：
URI 源于需要以统一和连贯的方式识别 Web 上的资源，和其他 Internet 资源，例如电子邮箱。因此，可以引入一种新类型的 widget: URI 来识别 widget 资源，或者使用 tel: URI 来让 Web 链接引起电话呼叫调用时进行。
有些 URI 提供信息来定位资源（例如 DNS 主机名和该机器上的路径），而有些则用作纯资源名称。 URL 是为 资源定位符 的标识符保留的，包括诸如 http://stackoverflow.com 之类的“http”URL，它标识了主机上给定路径的网页。另一个例子是 'mailto' URL，例如 mailto:fred@mail.org，它标识给定地址的邮箱。
URNs 是用作纯资源名称而非定位器的 URI。例如，URI：mid:0E4FC272-5C02-11D9-B115-000A95B55BC8@stackoverflow.com 是一个 URN，用于标识在其“消息 ID”字段中包含它的电子邮件。 URI 用于将该消息与任何其他电子邮件消息区分开来。但它本身并不提供消息在任何商店中的地址。
【讨论】：
我也在想同样的事情，我发现了这个：http://docs.kohanaphp.com/helpers/url。
您可以使用url::current() 方法看到一个清晰的示例。
如果你有这个 URL：http://example.com/kohana/index.php/welcome/home.html?query=string，那么使用 url:current() 会给你 URI，根据文档，它是：welcome/home
【讨论】：
最好的（技术）总结imo就是这个
IRI, URI, URL, URN and their differences 来自 Jan Martin Keil：
每个与语义网打交道的人都会反复遇到 IRI、URI、URL 和 URN 等术语。然而，我经常观察到它们的确切含义存在一些混淆。当然，其他人也注意到了这一点（参见例如 RFC3305 或在 Google 上搜索）。老实说，我什至一开始自己也很困惑。但实际上问题并没有那么复杂。让我们看一下上述术语的定义，看看有什么区别：
统一资源标识符是标识抽象或物理资源的紧凑字符序列。字符集仅限于 US-ASCII，不包括一些保留字符。允许字符集之外的字符可以使用百分比编码来表示。 URI 可以用作定位器、名称或两者兼而有之。如果 URI 是定位器，它描述了资源的主要访问机制。如果 URI 是一个名称，它通过给它一个唯一的名称来标识一个资源。 URI 的语法和语义的确切规范取决于使用的方案，该方案由第一个冒号之前的字符定义。 [RFC3986]
统一资源名称是方案骨灰盒中的 URI，旨在用作持久的、与位置无关的资源标识符。从历史上看，该术语也指任何 URI。 [RFC3986] URN 由命名空间标识符 (NID) 和命名空间特定字符串 (NSS) 组成： urn:: NSS 的语法和语义对每个 NID 都是特定的。除了已注册的 NID 之外，还有几个未经过正式注册过程的 NID。 [RFC2141]
统一资源定位符是一个 URI，它除了标识资源外，还通过描述资源的主要访问机制 [RFC3986] 来提供定位资源的方法。由于没有通过一组 Scheme 对 URL 进行准确定义，“URL 是一个有用但非正式的概念”，通常指的是不包含 URN [RFC3305] 的 URI 子集。
国际化资源标识符的定义类似于 URI，但字符集扩展为通用编码字符集。因此，它可以包含除保留字符之外的任何拉丁字符和非拉丁字符。代替扩展 URI 的定义，引入术语 IRI 是为了明确区分并避免不兼容。在支持通用编码字符集的情况下，IRI 旨在替换 URI 来识别资源。根据定义，每个 URI 都是一个 IRI。此外，IRI 到 URI 有一个定义的满射映射：每个 IRI 都可以映射到一个 URI，但不同的 IRI 可能映射到同一个 URI。因此，从 URI 到 IRI 的转换可能不会产生原始 IRI。 [RFC3987]
IRI is a superset of URI (IRI ⊃ URI)
URI is a superset of URL (URI ⊃ URL)
URI is a superset of URN (URI ⊃ URN)
URL and URN are disjoint (URL ∩ URN = ∅)
RDF 明确允许使用 IRI 来命名实体 [RFC3987]。这意味着我们可以使用实体名称中的几乎每个字符。另一方面，我们经常不得不处理早期状态的软件。因此，使用非 ASCII 字符不太可能遇到问题。因此，我建议避免实体的非 URI 名称，并建议使用 http URIs [LINKED-DATA]。简而言之：仅使用 URL 来命名您的实体。当然，我们可以引用由 URN 命名的现有实体。但是，我们应该避免新创建这种标识符。
【讨论】：
容易解释：
假设如下
URI 是你的名字
URL 是您的地址和您的姓名，以便与您交流。
我叫洛约拉
Loyola 是 URI
我的地址是 TN, Chennai 600001。
TN，Chennai 600 001，Loyola 是 URL
希望你能理解，
现在让我们看一个精确的例子
http://www.google.com/fistpage.html
在上面你可以与一个名为firstpage.html的页面进行通信 (URI) 使用以下 http://www.google.com/fistpage.html(URL)。
因此 URI 是 URL 的子集，反之则不然。
【讨论】：
我找到了：
一个统一的资源标识符 (URI) 代表了一个大图景。您可以拆分 URI / URI 可以分类为定位器（统一资源定位器 - URL）或名称（统一资源名称 - URN），或两者兼而有之。所以基本上，URN 的功能就像一个人的名字，而 URL 描述了那个人的地址。长话短说，一个URN定义了一个项目的身份，而URL提供了定义找到它的方法，最后封装这两个概念的是URI
【讨论】：
答案是模棱两可的。在 Java 中它经常以这种方式使用：
统一资源定位器 (URL) 是用于标识 Internet 资源的术语，包括方案（http、https、ftp、新闻等）。比如What is the difference between a URI, a URL and a URN?
统一资源标识符 (URI) 用于标识 Web 服务器中的单个文档：例如 /questions/176264/whats-the-difference-between-a-uri-and-a-url
在 Java servlet 中，URI 经常引用没有 Web 应用程序上下文的文档。
【讨论】：