URL、URI和<说明>URN说明>有什么区别?
它们是一样的。URI是URL的泛化。最初,URI被计划分为URL(地址)和URN(名称),但随后URL和URI之间几乎没有区别,超文本传输协议URI被用作命名空间,即使它们实际上没有定位任何资源。
从rfc3986:
URI可以进一步分类为定位器、名称或两者兼而有之。这个术语“统一资源定位符”(URL)指的是URI的子集除了识别资源之外,还提供了一种方法通过描述其主要访问机制来定位资源(例如,它的网络“位置”)。术语“统一资源名称”(URN)历来用于引用“urn”方案[RFC2141],需要保持全局唯一甚至当资源不再存在或成为不可用,以及任何其他具有名称属性的URI。
所以所有的URL都是URI,所有的URN都是URI——但是URN和URL是不同的,所以你不能说所有的URI都是URL。
如果你还没有读过Roger Pate的回答,我建议你也这样做。
维基百科将在此处提供您需要的所有信息。引用http://en.wikipedia.org/wiki/URI:
URL是一个URI,除了标识资源之外,它还通过描述其主要访问机制或网络“位置”来提供对资源进行操作或获取资源表示的方法。
URI=>http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
URL是URI的子集(也包含URN)。
基本上,URI是一个通用标识符,其中URL指定位置,URN指定名称。
URI是URL和URN的超类。维基百科有一个关于它们的好文章,并链接到正确的RFC集。
URI的标识和URL的位置;然而,定位器也是标识符,所以每个URL也是一个URI,但有一些URI不是URL。
这是我的名字,它是一个标识符。它就像一个URI,但不能是一个URL,因为它不会告诉你我的位置或如何联系我。在这种情况下,它也碰巧仅在美国就识别出至少5个人。
这是一个定位器,它是该物理位置的标识符。它既像URL又像URI(因为所有URL都是URI),并且还将我间接标识为“…的居民”。在这种情况下,它唯一地标识了我,但如果我有室友,情况就会改变。
我说“喜欢”是因为这些示例不遵循所需的语法。
从维基百科:
在计算中,统一资源定位器(URL)是统一资源标识符(URI)的子集,它指定了可识别资源的位置以及检索它的机制。在流行的用法以及许多技术文档和口头讨论中,它经常被错误地用作URI的同义词,…[强调我的]
由于这种常见的混淆,许多产品和留档错误地使用一个术语而不是另一个术语,分配自己的区别,或同义使用它们。
我的名字,罗杰·佩特,可以像URN(统一资源名称),除了那些是更加规范并且打算在两者空间和时间上是唯一的。
因为我目前与其他人共享这个名字,它不是全球唯一的,不适合作为URN。然而,即使没有其他家庭使用这个名字,我以我祖父的名字命名,所以它仍然不会在不同时间内是唯一的。即使不是这样,以我的名字命名我的后代的可能性使它不适合作为URN。
在这个严格的唯一性约束中,URN与URL不同,尽管它们都共享URI的语法。
见本文件。具体来说,
URL是一种URI,它通过其主要访问机制(例如,其网络“位置”)的表示来标识资源,而不是通过它可能具有的其他一些属性来标识资源。
这不是一个非常明确的术语,真的。
总结:一个URI标识,一个URL标识和定位。
考虑莎士比亚戏剧罗密欧与朱丽叶的特定版本,您的家庭网络上有一个数字副本。
您可以将文本标识为urn:isbn:0-486-27557-4。这将是一个URI,但更具体地说是<说明>URN说明>*,因为它命名文本。
urn:isbn:0-486-27557-4
您也可以将文本标识为file://hostname/sharename/RomeoAndJuliet.pdf。这也是一个URI,但更具体地说是url,因为它找到文本。
file://hostname/sharename/RomeoAndJuliet.pdf
*统一资源名称
(请注意,我的示例改编自维基百科
在考虑URI时,我喜欢使用的另一个例子是XML文档的xmlns属性:
<rootElement xmlns:myPrefix="com.mycompany.mynode"><myPrefix:aNode>some text</myPrefix:aNode></rootElement>
在这种情况下com.mycompany.mynode将是一个URI,它唯一地标识XML文档中使用它的所有元素的“myPre出任”命名空间。这不是一个URL,因为它仅用于标识,而不是定位某些东西本身。
URI通过位置或名称或两者来标识资源。我们大多数人通常使用定义资源位置的URI。URI可以通过名称和位置来标识资源这一事实在我看来导致了很多混淆。URI有两种专业化,称为URL和URN。
URL是URI的特化,它定义了特定资源的网络位置。与URN不同,URL定义了如何获得资源。我们每天都以http://stackoverflow.com等形式使用URL。但是URL不一定是HTTP URL,它可以是ftp://example.com等。
ftp://example.com
以下是一些写得很好但冗长的答案。以下是区别就CodeIgniter而言:
url-http://example.com/some/page.html
URI- /some/page.html
简单地说,URL是识别任何地方任何资源的完整方式,可以有不同的协议,如FTP、HTTP、SCP等。
URI是当前域上的资源,因此需要更少的信息才能找到。
在CodeIgniter使用URL或URI这个词的每个实例中,这就是他们所谈论的差异,尽管在Web的宏伟计划中,它不是100%正确的。
尽管术语URI和URL是严格定义的,但许多人将这些术语用于定义之外的其他事情。
让我们以Apache为例。如果从Apache服务器请求http://example.com/foo,您将设置以下环境变量:
REDIRECT_URL
/foo
REQUEST_URI
启用mod_rewrite后,您还将拥有这些变量:
REDIRECT_SCRIPT_URL
REDIRECT_SCRIPT_URI
http://example.com/foo
SCRIPT_URL
SCRIPT_URI
这可能是一些混乱的原因。
由于难以明确区分URI和URL,据我所知,W3C不再区分URI和URL(http://www.w3.org/Addressing/)。
我想知道同样的事情,我发现了这个:http://docs.kohanaphp.com/helpers/url。
您可以看到一个使用url::current()方法的清晰示例。如果你有这个url:http://example.com/kohana/index.php/welcome/home.html?query=string,那么使用url:current()会给你URI,根据留档,是:欢迎/回家
url::current()
http://example.com/kohana/index.php/welcome/home.html?query=string
url:current()
答案是模棱两可的。在Java它经常这样使用:
统一资源定位器(URL)是用于标识Internet资源的术语,包括方案(超文本传输协议、https、ftp、新闻等)。例如URI、URL和URN有什么区别?
统一资源标识符(URI)用于标识Web服务器中的单个文档:例如 /questions/176264/whats-the-difference-between-a-uri-and-a-url
在Javaservlet中,URI经常引用没有Web应用程序上下文的文档。
这是我作为网络专业人士遇到的最令人困惑且可能无关紧要的话题之一。
按照我的理解,URI是对某物的描述,遵循公认的格式,可以定义某物或其位置的唯一名称(标识)。
有两个基本子集:
我倾向于认为URN类似于GUID。它们只是为事物提供唯一名称的标准化方法论。就像使用公司名称的命名空间声明一样——它不像服务器上的某个资源与该行文本相对应——它只是唯一地标识某些东西。
我也倾向于完全避免使用URI这个术语,只在适当的时候用URL或URN来讨论事情,因为它会造成很多混乱。我们真正应该尝试为人们回答的问题不是语义学,而是如何在遇到这些术语时识别它们是否存在任何实际差异,这将改变处理编程情况的方法。例如,如果有人在谈话中纠正我说,“哦,那不是URL,这是一个URI”,我知道他们充满了它。如果有人说,“我们正在使用URN来定义资源”,我更有可能理解我们只是唯一地命名它,而不是在服务器上定位它。
如果我离开基地,请让我知道!
URI来源于以统一和连贯的方式识别Web上的资源和其他互联网资源(例如电子邮箱)的需要。因此,可以引入一种新型的小部件: URI来识别小部件资源,或者使用电话: URI使Web链接在调用时导致拨打电话。
一些URI提供用于定位资源的信息(例如DNS主机名和该机器上的路径),而另一些则用作纯资源名。url保留给是资源定位器的标识符,包括超文本传输协议URL,例如http://stackoverflow.com,它标识主机上给定路径的网页。另一个例子是邮件URL,例如邮件:fred@mail.org,它标识给定地址的邮箱。
URNs是用作纯资源名而不是定位器的URI。例如,URI:中期:0E4FC272-5C02-11D9-B115-000A95B55BC8@stackoverflow.com是一个URN,用于标识在其“Message-Id”字段中包含它的电子邮件。URI用于将该消息与任何其他电子邮件区别开来。但它本身不会在任何存储中提供消息的地址。
以下是我的简化:
urn:唯一的资源名称,即“什么”(例如urn:issn:1234-5678)。这意味着是唯一的…因为没有两个不同的文档可以拥有相同的urn。有点像“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…无论哪种方式,你都是对的(至少目前是这样…)
url
URL是URI的特化,它定义了特定资源的网络位置。与URN不同,URL定义了如何获得资源。我们每天都以http://example.com等形式使用URL。但是URL不一定是HTTP URL,它也可以是ftp://example.com等。
http://example.com
URI
URL和URI的区别
URI是某个资源的标识符,但URL为您提供了获取该资源的特定信息。URI是一个URL,正如一位评论者指出的那样,现在在描述应用程序时使用URL被认为是不正确的。通常,如果URL描述了资源的位置和名称,使用的术语是URI。由于这通常是我们大多数人每天遇到的情况,URI是正确的术语。
在阅读了这些帖子之后,我发现了一些非常相关的评论。简而言之,URL和URI定义之间的混淆部分是基于哪个定义取决于哪个定义,以及URI一词在软件开发中的非正式使用。
根据定义,URL是URI[RFC2396]的子集。URI包含URN和URL。URI和URL都有自己特定的语法,赋予它们URI或URL的状态。URN用于唯一标识资源,而URL用于定位资源。请注意,资源可以有多个URL,但只有一个URN。[RFC2611]
作为Web开发人员和程序员,我们几乎总是关注URL,因此关注URI。现在URL被专门定义为具有所有部分的方案:方案特定部分,例如https://stackoverflow.com/questions。这是一个URL,它也是一个URI。现在考虑嵌入页面中的相对链接,例如…/index.html.根据定义,这不再是一个URL。它仍然是所谓的“URI引用”[RFC2396]。
我相信当URI这个词被用来指代相对路径时,“URI引用”实际上就是人们所想到的。所以非正式地,软件系统使用URI指代相对路径和绝对地址的URL。所以从这个意义上说,相对路径不再是URL,而是URI。
我发现:
统一资源标识符(URI)代表了一个大画面。你可以拆分URI/URI,可以分为定位器(统一资源定位器-URL),或者作为名称(统一资源名称-URN),或者两者兼而有之。所以基本上,URN的功能就像一个人的名字,URL描述了那个人的地址。长话短说,URN定义了一个项目的身份,而URL提供定义了找到它的方法,最后封装这两个概念的就是URI
按照rfc3986,URI由以下部分组成:
scheme://authority/path?query
URI描述了用于访问服务器(权威性)上的资源(路径)或应用程序(查询)的协议。
所有的URL都是URI,所有的URN都是URI,但所有的URI都不是URL。
请参阅更多详情:
维基百科
除了已经发布的答案之外,这里还有一个维恩图来总结这个理论(来自Prateek Joshi美丽的解释):
举个例子(也来自Prateek的网站):
很容易解释:
让我们假设如下
URI是你的名字
URL是您的地址和您的姓名,以便与您沟通。
我叫洛约拉
洛约拉是URI
我的地址是TN, Chennai 600001。
TN,金奈600 001,洛约拉是URL
希望你能理解,
现在让我们看一个精确的例子
在上面,您可以与名为的页面进行通信firstpage.html(URI)使用以下(url)。
因此URI是URL的子集,而不是相反。
URI是使用简短的数字、字母和符号字符串识别文档的标准。它们由RFC 3986-统一资源标识符(URI):通用语法定义。URL、URN和URC都是URI的类型。
包含有关如何从其位置获取资源的信息。例如:
http://example.com/mypage.html
ftp://example.com/download.zip
mailto:user@example.com
file:///home/user/file.txt
tel:1-888-555-5555
http://example.com/resource?foo=bar#fragment
/other/link.html
URL总是以协议(http)开头,通常包含网络主机名(example.com)和文档路径(/foo/mypage.html)等信息。URL可能有查询参数和片段标识符。
http
example.com
/foo/mypage.html
通过唯一且持久的名称标识资源,但不一定告诉您如何在Internet上找到它。它通常以前缀urn:开头例如:
urn:
urn:isbn:0451450523
urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
urn:publishing:book
URN可以识别想法和概念。它们不仅限于识别文档。当URN确实代表文档时,它可以被“解析器”翻译成URL。然后可以从URL下载文档。
指向有关文档的元数据,而不是文档本身。URC的一个示例是指向页面的超文本标记语言源代码,例如:view-source:http://example.com/
view-source:http://example.com/
数据可以直接放入URI中,而不是在Internet上定位或命名它。一个例子是data:,Hello%20World。
data:,Hello%20World
超文本标记语言的W3规范说#0的锚标记可以包含URI,而不仅仅是URL。您应该能够输入像<a href="urn:isbn:0451450523">这样的URN。然后您的浏览器会将该URN解析为URL并为您下载本书。
<a href="urn:isbn:0451450523">
据我所知没有,但现代Web浏览器确实实现了数据URI方案。
不可以。相对URL和绝对URL都是URL(和URI)。
否。带有和不带查询参数的URL都是URL(和URI)。
不可以。带有和不带片段标识符的URL都是URL(和URI)。
不能。URL被定义为URI的一个严格子集。如果解析器允许在URL中使用某个字符,但不允许在URI中使用,则解析器中有一个bug。规范非常详细地说明了URL和URI的哪些部分允许使用哪些字符。有些字符可能只允许在URL的某些部分使用,但字符本身并不是URL和URI之间的区别。
是的。W3C意识到对此存在大量的困惑。他们发布了一个URI澄清文档,表示现在可以互换使用术语URL和URI(表示URI)。将URI严格划分为不同类型不再有用,例如URL、URN和URC。
URN的定义现在比我上面所说的更宽松。最新的URI RFC说任何URI现在都可以是URN(无论它是否以urn:开头),只要它具有“名称的属性”。也就是说:即使资源不再存在或变得不可用,它也是全局唯一和持久的。一个例子:在超文本标记语言doctype中使用的URI,例如http://www.w3.org/TR/html4/strict.dtd。即使w3.org网站上的页面被删除,该URI也会继续命名HTML4过渡doctype。
http://www.w3.org/TR/html4/strict.dtd
为了回答这个问题,我将依靠我修改了另一个问题的答案。URI的一个很好的例子是您如何识别Amazon S3资源。让我们采取:
s3://www-example-com/index.html[图1]
s3://www-example-com/index.html
我创建了一个缓存副本
http://www.example.com/index.html[图2]
http://www.example.com/index.html
在亚马逊的S3-US-West-2数据中心。
即使StackOverflow允许我超链接到s3://协议方案,它对资源定位也没有任何好处。因为它识别 a资源库,图1是一个有效的URI。它也是一个有效的URN,因为亚马逊要求存储桶(他们对URIauthority部分的术语)在数据中心之间是唯一的。定位它是有用,但它并没有指示数据中心。因此它不能作为URL工作。
s3://
authority
那么,在这种情况下,URI、URL和URN有什么不同呢?
注: RFC 3986将URI定义为scheme://authority/path?query#fragment
scheme://authority/path?query#fragment
身份=带位置的名称
每个URL(UniformResSourceLocator)抽象地说都是一个URI(UniformResSource我的标识符),但每个URI都不是一个URL。URI的另一个子类是URN(UniformResSourceName),它是一个命名资源,但没有指定如何定位它们,就像mail to、news、ISBN是URI。来源
URN:
urn:[namespace identifier]:[namespace specific string]
arn:partition:service:region:account-id:resource
URL:
[scheme]://[Domain][Port]/[path]?[queryString]#[fragmentId]
类比:到达一个人:驾驶(协议其他短信,电子邮件,电话),地址(主机名其他电话号码,电子邮件ID)和人名(具有相对路径的对象名称)。
不要忘记URN。URI和URL都是URN。URL有一个位置:
URI: fooURL: http://some.domain.com/fooURL: http://some.domain.com:8080/fooURL: ftp://some.domain.com/foo
它们都是URN。
URI, URL, URN
如上图所示,这里有三个不同的组成部分在起作用。在讨论这样的问题时,通常最好去源头,所以这是蒂姆·伯纳斯-李等人的练习 RFC 3986:统一资源标识符(URI):通用语法:
统一资源标识符(URI)是一个紧凑的标识抽象或物理资源的字符。URI可以进一步分类为定位器、名称或两者兼而有之。这个术语“统一资源定位符”(URL)指的是URI的子集除了识别资源之外,还提供了一种方法通过描述其主要访问机制来定位资源(例如,它的网络“位置”)。
统一资源标识符(URI)是一个紧凑的标识抽象或物理资源的字符。
URI可以进一步分类为定位器、名称或两者兼而有之。这个术语“统一资源定位符”(URL)指的是URI的子集除了识别资源之外,还提供了一种方法通过描述其主要访问机制来定位资源(例如,它的网络“位置”)。
首先,把你的头脑从混乱中解脱出来,把它变得简单,你就会明白。
URI=>统一资源标识符标识资源i-e位置、名称或两者的完整地址。
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
最好的(技术)总结imo是这个
简·马丁·凯尔:
每个接触语义网的人都会反复遇到IRI、URI、url、URN这几个术语,但是我经常观察到这些术语的确切含义存在一些混淆,当然也有其他人注意到(见RFC3305或在Google上搜索)。说实话,一开始我自己也有这种困惑,但其实问题并没有那么复杂。我们先来看看这些术语的定义,看看有什么区别:
统一资源标识符是标识抽象或物理资源的紧凑字符序列。字符集仅限于US-ASCII,不包括一些保留字符。允许字符集之外的字符可以使用百分比编码表示。URI可以用作定位器、名称或两者兼而有之。如果URI是定位器,它描述了资源的主要访问机制。如果URI是名称,它通过赋予资源唯一的名称来标识资源。URI的语法和义语学的确切规范取决于由第一个冒号之前的字符定义的使用方案。[RFC3986]
统一资源名称是方案urn中的URI,旨在作为持久的、位置无关的资源标识符。历史上,该术语也指任何URI。[RFC3986]URN由命名空间标识符(NID)和命名空间特定字符串(NSS)组成:urn:: NSS的语法和语义学对每个NID都是特定的。除了注册的NID之外,还有几个没有经过官方注册过程的NID。[RFC2141]
A统一资源定位器是一个URI,除了标识资源之外,还通过描述其主要访问机制提供了一种定位资源的方法[RFC3986]。由于没有通过一组模式对URL进行确切的定义,“URL是一个有用但非正式的概念”,通常指的是不包含URN的URI子集[RFC3305]。
国际化资源标识符的定义类似于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名称,并建议使用超文本传输协议URI[LINKED-DATA]。简单地说:只使用URL来命名你的实体。当然,我们可以引用由URN命名的现有实体。但是,我们应该避免新创建这种标识符。