사람들은 URL , URI 및 URN에 대해 마치 다른 것처럼 이야기하지만 육안과 동일하게 보입니다.

그들 사이의 구별되는 차이점은 무엇입니까?

에서 RFC 3986 :

URI는 로케이터, 이름 또는 둘 다로 더 분류 될 수 있습니다. "Uniform Resource Locator"(URL)라는 용어는 리소스를 식별하는 것 외에 기본 액세스 메커니즘 (예 : 네트워크 "위치")을 설명하여 리소스를 찾는 방법을 제공하는 URI의 하위 집합을 나타냅니다. "URN (Uniform Resource Name)"이라는 용어는 역사적으로 "urn"체계 [RFC2141] 에서 두 URI를 모두 지칭하기 위해 사용되었으며 , 이는 자원이 존재하지 않거나 사용할 수 없게되었을 때에도 전 세계적으로 고유하고 지속적으로 유지되어야합니다. 이름의 속성을 가진 다른 URI에.

따라서 모든 URL은 URI이며 (실제로는 그렇지 않음) 모든 URN은 URI이지만 URN과 URL은 다르므로 모든 URI가 URL이라고 말할 수는 없습니다.

편집 : 이전에는 모든 URL이 유효한 URI라고 생각했지만 의견에 따라 :

"모든 URL이 URI"인 것은 아닙니다 . RFC의 해석에 따라 다릅니다. 자바 예를 들어, URI 파서는 아니 같은 않습니다 [또는 ]과 사양이 "해야하지"가 아니라 말한다의 때문 "안된다"를.

불행히도 물을 더 진흙으로 만듭니다.

Roger Pate의 답변을 아직 읽지 않았다면 그렇게하는 것이 좋습니다.

URI는 식별 하고 URL은 찾습니다 . 그러나 로케이터도 식별자 이므로 모든 URL도 URI이지만 URL이 아닌 URI가 있습니다.

예

• 로저 페이트

제 이름은 식별자입니다. URI와 비슷하지만 내 위치 나 연락 방법에 대해 알려주지 않으므로 URL이 될 수 없습니다. 이 경우 미국에서만 5 명 이상의 다른 사람들을 식별하는 것도 가능합니다.

• 4914 West Bay Street, 나 사우, 바하마

이 로케이터는 해당 물리적 ​​위치의 식별자입니다. URL과 URI 모두 같으며 (모든 URL이 URI이기 때문에) " 나의 거주자" 라고 간접적 으로 식별합니다 . 이 경우에는 나를 고유하게 식별하지만 룸메이트가 있으면 변경됩니다.

이 예제는 필요한 구문을 따르지 않기 때문에 "like"라고 말합니다.

인기있는 혼란

에서 위키 백과 :

컴퓨팅에서 URL (Uniform Resource Locator)은 식별 된 리소스를 사용할 수있는 위치와이를 검색하는 메커니즘을 지정하는 URI (Uniform Resource Identifier)의 하위 집합입니다. 대중적인 사용법과 많은 기술 문서와 구두 토론에서 종종 URI 와 동의어로 잘못 사용됩니다 . [강조]

이러한 혼동으로 인해 많은 제품과 문서에서 다른 용어 대신 한 용어를 잘못 사용하거나 고유 한 용어를 지정하거나 동의어로 사용합니다.

URN

내 이름은 로저 페이트는 같은 수 URN 사람들은 제외하고, (통일 자원 이름) 더 많은 규제 와에서 고유하도록 모두 공간과 시간.

현재이 이름을 다른 사람들과 공유하고 있기 때문에 전 세계적으로 고유하지 않으며 URN으로 적합하지 않습니다. 그러나 다른 가족 이이 이름을 사용하지 않더라도 나는 할아버지 할아버지의 이름을 따서 명명되었으므로 시간이 지나도 고유하지는 않습니다. 그리고 경우에도 그 사건이 아니었다, 나를 따라 내 후손의 이름을 지정할 수있는 가능성은 URN 등이 적합합니다.

URN은 URI의 구문을 공유하지만이 엄격한 고유성 제약 조건에서 URL과 다릅니다.

URI- 균일 한 자원 식별자

URI는 짧은 숫자, 문자 및 기호 문자열을 사용하여 문서를 식별하는 표준입니다. RFC 3986-URI (Uniform Resource Identifier) ​​: 일반 구문에 의해 정의됩니다 . URL, URN 및 URC는 모두 모든 유형 의 URI입니다.

URL- 균일 한 리소스 로케이터

해당 위치에서 리소스를 가져 오는 방법에 대한 정보가 포함되어 있습니다. 예를 들면 다음과 같습니다.

• 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, 다른 URL의 상황에서만 유용합니다)

URL은 항상 프로토콜 ( http)로 시작 하며 일반적으로 네트워크 호스트 이름 ( example.com) 및 종종 문서 경로 ( /foo/mypage.html) 와 같은 정보를 포함합니다 . URL에는 쿼리 매개 변수 및 조각 식별자가있을 수 있습니다.

URN- 균일 한 자원 이름

고유하고 지속적인 이름으로 리소스를 식별하지만 인터넷에서 리소스를 찾는 방법을 반드시 알려주지는 않습니다. 일반적으로 접두사로 시작합니다. urn: 예를 들면 다음과 같습니다.

• urn:isbn:0451450523 ISBN 번호로 책을 식별합니다.
• urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 세계적으로 고유 한 식별자
• urn:publishing:book -문서를 장부 유형으로 식별하는 XML 네임 스페이스.

URN은 아이디어와 개념을 식별 할 수 있습니다. 문서 식별에만 국한되지 않습니다. URN이 문서를 나타내는 경우 "확인자"에 의해 URL로 변환 될 수 있습니다. 그런 다음 URL에서 문서를 다운로드 할 수 있습니다.

URC-균일 한 자원 인용

문서 자체가 아닌 문서에 대한 메타 데이터를 가리 킵니다. URC의 예는 다음과 같은 페이지의 HTML 소스 코드를 가리키는 것입니다.view-source:http://example.com/

데이터 URI

인터넷에서 찾거나 이름을 지정하지 않고 데이터를 URI에 직접 배치 할 수 있습니다. 예를 들면 다음과 같습니다 data:,Hello%20World.

자주 묻는 질문

더 이상 URL을 말하면 안된다는 이야기를 들었습니다. 왜 그렇습니까?

HTML에 대한 W3 사양에 따르면 href앵커 태그 의 URL은 URL뿐만 아니라 URI도 포함 할 수 있습니다. 와 같은 URN을 넣을 수 있어야합니다 <a href="urn:isbn:0451450523">. 그러면 브라우저가 해당 URN을 URL로 해석하고 책을 다운로드합니다.

실제로 브라우저는 URN으로 문서를 가져 오는 방법을 알고 있습니까?

내가 아는 것은 아니지만 최신 웹 브라우저는 데이터 URI 체계를 구현합니다.

URL과 URI의 차이가 상대적인지 아니면 절대적인 것과 관련이 있습니까?

아니요. 상대 및 절대 URL은 모두 URL (및 URI)입니다.

URL과 URI의 차이점은 쿼리 매개 변수가 있는지 여부와 관련이 있습니까?

아니요. 검색어 매개 변수가 있거나없는 URL은 모두 URL (및 URI)입니다.

URL과 URI의 차이점은 조각 식별자가 있는지 여부와 관련이 있습니까?

아니요. 조각 식별자가 있거나없는 URL은 모두 URL (및 URI)입니다.

URL과 URI의 차이점은 허용되는 문자와 관련이 있습니까?

아니요. URL은 엄격한 URI 하위 집합으로 정의됩니다. 구문 분석기가 URL에는 문자를 허용하지만 URI에는 문자를 허용하지 않으면 구문 분석기에 버그가 있습니다. 스펙은 URL 및 URI의 어느 부분에서 어떤 문자가 허용되는지에 대해 자세히 설명합니다. 일부 문자는 URL의 일부에서만 허용 될 수 있지만 문자만으로는 URL과 URI의 차이가 아닙니다.

그러나 W3C는 이제 URL과 URI가 같은 것이라고 말하지 않습니까?

예. W3C는 이것에 대해 많은 혼란이 있음을 깨달았습니다. 그들은 URL과 URI라는 용어를 서로 바꿔서 사용하는 것이 좋다고 말하는 URI 설명 문서 를 발행했습니다 ( URI 를 의미 함). 더 이상 URI를 URL, URN 및 URC와 같은 다른 유형으로 엄격하게 세그먼트 화하는 것은 더 이상 유용하지 않습니다.

URI가 URL과 URN이 될 수 있습니까?

URN의 정의는 이제 위에서 언급 한 것보다 느슨합니다. URI 의 최신 RFC에 따르면 urn:"이름의 속성"이 있는 한 모든 URI가 (시작 여부에 관계없이) URN이 될 수 있다고합니다 . 즉, 자원이 존재하지 않거나 사용할 수 없게 된 경우에도 전 세계적으로 독특하고 지속적입니다. 예 :와 같은 HTML doctypes에 사용되는 URI http://www.w3.org/TR/html4/strict.dtd. 해당 URI는 w3.org 웹 사이트의 페이지가 삭제 된 경우에도 HTML4 전환 doctype의 이름을 계속 지정합니다.

요약하면 : URI는 식별하고 URL은 식별하고 찾습니다.

셰익스피어의 희곡 로미오와 줄리엣 의 특정 판을 생각해 보자 . 홈 네트워크에 디지털 사본이있다.

텍스트를로 식별 할 수 urn:isbn:0-486-27557-4있습니다.
이는 URI이지만보다 구체적으로 텍스트 이름을 지정 하기 때문에 URN * 입니다.

텍스트를로 식별 할 수도 있습니다 file://hostname/sharename/RomeoAndJuliet.pdf.
그것은 또한 URI이지만, 더 구체적으로 는 텍스트를 찾기 때문에 URL 입니다.

* 균일 자원 이름

(내 예제는 Wikipedia 에서 수정되었습니다. )

이것들은 매우 잘 쓰여졌지만 오래 지속 된 답변입니다. CodeIgniter에 관한 한 차이점은 다음과 같습니다 .

URL - http : //example.com/some/page.html

URI- /some/page.html

간단히 말해 URL은 어디에서나 리소스를 식별 할 수있는 완벽한 방법이며 FTP, HTTP, SCP 등과 같은 다른 프로토콜을 가질 수 있습니다.

URI는 현재 도메인의 리소스이므로 찾을 정보가 더 적습니다.

CodeIgniter가 URL 또는 URI라는 단어를 사용하는 모든 경우에있어 이는 웹의 대 체계에서 100 % 정확하지는 않지만 그들이 말하는 차이점입니다.

우선 혼동을 피하고 간단하게 이해하면 이해하게됩니다.

URI => Uniform Resource Identifier 자원 의 전체 주소, 즉 위치, 이름 또는 둘 다를 식별합니다.

URL => Uniform Resource Locator 자원의 위치를 식별합니다.

URN => Uniform Resource Name 자원의 이름을 식별합니다

예

https://www.google.com/folder/page.html 주소가 있습니다 .

URI (Uniform Resource Identifier) ​​=> https://www.google.com/folder/page.html

URL (Uniform Resource Locator) => https://www.google.com/

URN (Uniform Resource Name) => /folder/page.html

URI => (URL + URN) 또는 URL 만 또는 URN 만

이미 게시 된 답변에 약간의 추가 사항이 있습니다. (Prateek Joshi의 아름다운 설명에서 ) 이론을 요약하는 Venn의 다이어그램이 있습니다 .

그리고 예 (Prateek의 웹 사이트에서도) :

이것은 웹 전문가로서 직면 한 가장 혼란스럽고 관련성이없는 주제 중 하나입니다.

내가 이해하는 것처럼 URI는 승인 된 형식에 따라 무언가에 대한 설명이며 무언가의 고유 이름 (식별)과 위치를 모두 정의 할 수 있습니다.

위치 (특히 웹 페이지를 찾으려고하는 브라우저의 경우)를 정의하는 URL과 고유 한 이름을 정의하는 URN의 두 가지 기본 하위 집합이 있습니다.

URN은 GUID와 비슷하다고 생각하는 경향이 있습니다. 그것들은 단순히 사물에 고유 한 이름을 제공하기위한 표준화 된 방법입니다. 회사 이름을 사용하는 네임 스페이스 선언에서와 같이, 해당 텍스트 줄에 해당하는 서버에 리소스가있는 것과 같지 않습니다. 단순히 무언가를 고유하게 식별합니다.

나는 또한 URI라는 용어를 완전히 피하고 URL이나 URN의 관점에서만 문제를 논의하는 경향이 있습니다. 혼동을 유발하기 때문입니다. 사람들에게 실제로 답해야 할 질문은 의미론이 아니라 프로그래밍 상황에 대한 접근 방식을 바꾸는 실질적인 차이가 있는지 여부를 발견 할 때 어떻게 식별해야 하는가입니다. 예를 들어, 누군가 대화에서 나를 수정하고 "오, 그것이 URL이 아닙니다"라고 말하면 그들이 가득하다는 것을 압니다. 누군가가 "자원을 정의하기 위해 URN을 사용하고있다"고 말하면 서버에서 찾지 않고 고유하게 이름을 지정한다는 것을 이해할 것입니다.

내가 기지에서 벗어나면 알려주세요!

신원 = 위치 이름

모든 URL ( U niform R esource L의 ocator)는 URI입니다 ( U niform R esource I , dentifier) 추상적으로 말할 수 있지만, 모든 URI는 URL이 아닙니다. URI의 또 다른 하위 범주 URN (이다가 U niform R esource N의 명명 된 자원이지만, 뉴스, 흔한처럼 그들을 찾는 방법을 지정하지 않은 AME가), ISBN은 URI에 있습니다. 출처

항아리:

• URN 형식 : urn:[namespace identifier]:[namespace specific string]
• 항아리 : 그리고 : 스스로를 상징합니다.
• 예 :
  • 항아리 : uuid : 6e8bc430-9c3a-11d9-9669-0800200c9a66
  • 항아리 : ISSN : 0167-6423
  • 항아리 : isbn : 096139210x
  • Amazon 리소스 이름 (ARN) 은 AWS 리소스를 고유하게 식별합니다.
    • ARN 형식 : arn:partition:service:region:account-id:resource

URL :

• URL 형식 : [scheme]://[Domain][Port]/[path]?[queryString]#[fragmentId]
• :, // ,? 그리고 # 스스로를 의미합니다.
• 체계는 https, ftp, gopher, mailto, news, telnet, 파일, 남자, 정보, whatis, ldap입니다 ...
• 예 :
  • http : // ip_server / path? query
  • ftp : // ip_server / 경로
  • mailto : 이메일 주소
  • 뉴스 : 뉴스 그룹 이름
  • telnet : // ip_server /
  • 파일 : // ip_server / path_segments
  • ldap : // hostport / dn? attributes? scope? filter? extensions

유추 :
사람에게 연락하기 : 운전 (프로토콜 기타 SMS, 이메일, 전화), 주소 (호스트 이름 다른 전화 번호, emailid) 및 사람 이름 (상대 경로가있는 객체 이름).

URI => http://en.wikipedia.org/wiki/Uniform_Resource_Identifier

URL은 URI의 하위 집합입니다 (URN도 포함).

기본적으로 URI는 일반 식별자이며 URL은 위치를 지정하고 URN은 이름을 지정합니다.

URI를 생각할 때 사용하고 싶은 또 다른 예는 XML 문서의 xmlns 속성입니다.

<rootElement xmlns:myPrefix="com.mycompany.mynode">
    <myPrefix:aNode>some text</myPrefix:aNode>
</rootElement>

이 경우 com.mycompany.mynode는 내 XML 문서에서이를 사용하는 모든 요소의 "myPrefix"네임 스페이스를 고유하게 식별하는 URI입니다. URL은 고유 한 것이 아니라 식별하기 위해서만 사용되므로 URL이 아닙니다.

URI와 URL을 명확하게 구별하기가 어렵 기 때문에 W3C가 URI와 URL을 더 이상 다르게 만들지 않는다는 것을 기억 하십시오 ( http://www.w3.org/Addressing/ ).

그들은 같은 것 입니다. URI는 URL의 일반화입니다. 원래 URI는 URL (주소)과 URN (이름)으로 나누어 지려고했지만 실제로는 리소스를 찾지 못하더라도 URL과 URI와 http URI간에 차이가 거의 없었습니다.

URI, URL, URN

위의 이미지에서 알 수 있듯이 여기에는 세 가지 구성 요소가 있습니다. 일반적으로 이와 같은 문제를 논의 할 때 소스를 방문하는 것이 가장 좋습니다. 따라서 Tim Berners-Lee 등의 발췌문이 있습니다. 알. 에서 RFC 3986 :이 URI (Uniform Resource Identifier) : 일반 구문 :

URI (Uniform Resource Identifier)는 추상 또는 물리적 자원을 식별하는 간단한 문자 시퀀스입니다.

URI는 로케이터, 이름 또는 둘 다로 더 분류 될 수 있습니다. "Uniform Resource Locator"(URL)라는 용어는 리소스를 식별하는 것 외에 기본 액세스 메커니즘 (예 : 네트워크 "위치")을 설명하여 리소스를 찾는 방법을 제공하는 URI의 하위 집합을 나타냅니다.

URI는 URL과 URN의 수퍼 클래스입니다. Wikipedia에는 올바른 RFC 세트에 대한 링크 가 포함 된 훌륭한 기사 가 있습니다.

Wikipedia는 여기에 필요한 모든 정보를 제공합니다. http://en.wikipedia.org/wiki/URI 에서 인용 :

URL은 리소스를 식별 할뿐만 아니라 기본 액세스 메커니즘 또는 네트워크 "위치"를 설명하여 리소스에 대한 작업을 수행하거나 리소스의 표현을 얻는 수단을 제공하는 URI입니다.

URL

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가 올바른 용어입니다.

당으로 RFC 3986 , URI는 다음과 같은 부분으로 구성되어 있습니다 :

scheme://authority/path?query

URI 는 서버 ( authority ) 의 리소스 ( path ) 또는 응용 프로그램 ( query )에 액세스하기위한 프로토콜을 설명합니다 .

모든 URL은 URI이고 모든 URN은 URI이지만 모든 URI는 URL이 아닙니다.

자세한 내용은 다음을 참조하십시오 :

위키 백과

URI는 위치 또는 이름 또는 둘 다로 리소스를 식별합니다. 대부분의 경우, 대부분의 경우 리소스의 위치를 ​​정의하는 URI를 사용합니다. URI가 이름과 위치로 자원을 식별 할 수 있다는 사실은 제 생각에는 많은 혼란을 초래했습니다. URI에는 URL과 URN이라는 두 가지 전문 분야가 있습니다.

URL은 특정 리소스의 네트워크 위치를 정의하는 URI의 특수화입니다. URN과 달리 URL은 리소스를 얻는 방법을 정의합니다. 우리는 매일 http://stackoverflow.com 등 의 형태로 URL을 사용합니다 . 그러나 URL은 HTTP URL 일 필요는 없습니다 ftp://example.com.

URI와 URL이라는 용어는 엄격하게 정의되어 있지만 많은 용어가 정의 된 것 이외의 용어를 사용합니다.

아파치를 예로 들어 봅시다. 경우 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

이것이 혼란의 원인 일 수 있습니다.

이 문서를 참조하십시오 . 구체적으로 특별히,

URL은 다른 속성이 아닌 기본 액세스 메커니즘 (예 : 네트워크 "위치")을 통해 리소스를 식별하는 URI 유형입니다.

정말 명확한 용어는 아닙니다.

게시물을 읽은 후 매우 관련성이 높은 의견이 있습니다. 간단히 말해, URL과 URI 정의 사이의 혼동은 소프트웨어 개발에서 URI라는 단어를 비공식적으로 사용하는 것에 따라 어떤 정의가 어느 정의에 의존하는지에 따라 결정됩니다.

정의상 URL은 URI [RFC2396]의 하위 집합입니다. URI는 URN과 URL을 포함합니다. URI와 URL에는 각각 고유 한 구문이있어 URI 또는 ​​URL 상태를 부여합니다. URN은 리소스를 고유하게 식별하기위한 것이고 URL은 리소스를 찾기위한 것입니다. 리소스는 둘 이상의 URL을 가질 수 있지만 단일 URN 만 가질 수 있습니다. [RFC2611]

웹 개발자 및 프로그래머로서 우리는 거의 항상 URL과 URI에 관심을 가질 것입니다. 이제 URL은 https://stackoverflow.com/questions 와 같이 모든 부품 구성표 : Scheme-specific-part를 갖도록 구체적으로 정의됩니다 . 이것은 URL이며 URI이기도합니다. 이제 페이지에 포함 된 상대 링크 (예 : ../index.html)를 고려하십시오. 더 이상 정의상 URL이 아닙니다. 여전히 "URI 기준"[RFC2396]이라고합니다.

URI라는 단어가 상대 경로를 나타내는 데 사용될 때 "URI-reference"가 실제로 생각되고 있다고 생각합니다. 따라서 비공식적으로 소프트웨어 시스템은 URI를 사용하여 절대 주소에 대한 상대 경로 및 URL을 참조합니다. 따라서 이러한 의미에서 상대 경로는 더 이상 URL이 아니라 여전히 URI입니다.

다음은 단순화입니다.

URN : 고유 한 리소스 이름, 즉 "what"(예 : urn : issn : 1234-5678) 이것은 두 개의 다른 문서에서 같은 항아리를 가질 수 없기 때문에 독특합니다. "uuid"와 같은 비트

URL : "where"(예 : 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로 참조 할 수 있다는 사실에 위안을 느낄 수 있습니다 ... 어쨌든 어느 쪽이든 옳을 것입니다. .)

나는 똑같은 것을 궁금해하고 이것을 발견했다 : 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

URI는 웹상의 리소스 와 전자 사서함과 같은 다른 인터넷 리소스를 균일하고 일관된 방식 으로 식별해야 할 필요성에서 비롯 되었습니다. 따라서 새로운 유형의 위젯 : URI를 도입하여 위젯 자원 을 식별 하거나 tel : URI를 사용 하여 웹 링크를 사용 하여 호출 할 때 전화를 걸 수 있습니다.

일부 URI는 리소스 (예 : DNS 호스트 이름 및 해당 컴퓨터의 경로)를 찾는 데 필요한 정보를 제공하고 일부는 순수한 리소스 이름으로 사용됩니다. URL은 식별자 예약되어 리소스 로케이터입니다 같은 'HTTP'URL을 포함, http://stackoverflow.com 호스트상의 지정된 경로에 웹 페이지를 식별합니다. 다른 예는 mailto : fred@mail.org 와 같은 ' mailto'URL 입니다.이 주소는 주어진 주소에서 메일 함을 식별합니다.

URN 은 로케이터가 아닌 순수한 리소스 이름으로 사용되는 URI입니다 . 예를 들어 URI : mid : 0E4FC272-5C02-11D9-B115-000A95B55BC8@stackoverflow.com 은 'Message-Id'필드에이를 포함하는 전자 메일 메시지를 식별하는 URN입니다. URI는 해당 메시지를 다른 전자 메일 메시지와 구별하는 역할을합니다. 그러나 자체 저장소에 메시지 주소를 제공하지는 않습니다.

이 질문에 답하기 위해 다른 질문으로 수정 한 답변에 의지 하겠습니다 . URI의 좋은 예는 Amazon S3 리소스를 식별하는 방법입니다. 해 보자:

s3://www-example-com/index.html _{[무화과. 1]}

캐시 된 복사본으로 생성 한

http://www.example.com/index.html _{[무화과. 2]}

아마존의 S3-US-West-2 데이터 센터.

StackOverflow를 사용하여 s3:// 프로토콜 체계 에 하이퍼 링크 할 수 있다고해도 리소스 를 찾는 데 아무런 도움이되지 않습니다 . 이 때문에 식별 자원 , 그림을. 1 은 유효한 URI입니다. Amazon은 버킷 ( authorityURI 부분에 대한 용어 )이 데이터 센터에서 고유 해야하므로 유효한 URN이기도합니다 . 그것은입니다 도움 을 위치에 있지만 데이터 센터를 나타내지 않습니다. 따라서 URL로 작동하지 않습니다.

그렇다면이 경우 URI, URL 및 URN은 어떻게 다릅니 까?

• 무화과. 1 은 URI입니다
• 무화과. 1 은 URN입니다
• 무화과. 2 는 URI입니다
• 무화과. 2 는 URL입니다
• 그림 의 URL 1 은 http://www-example-com.s3-website-us-west-2.amazonaws.com/
  • 또한 http://www-example-com.s3.amazonaws.com/index.html
  • 그러나 http://www-example-com.s3.amazonaws.com/ 아님 (데이터 센터가없고 파일 이름이 Amazon S3에 너무 일반적이지 않음)

참고 : RFC 3986은 URI를 다음과 같이 정의합니다.scheme://authority/path?query#fragment

설명하기 쉽다 :

다음을 가정하자

URI는 당신의 이름입니다

URL은 귀하와 통신하기 위해 귀하의 이름을 가진 귀하의 주소입니다.

• 내 이름은로 y 라

  Loyola는 URI입니다

• 내 주소는 TN, Chennai 600001입니다.

TN, Chennai 600001, Loyola는 URL입니다

이해 하시길 바랍니다.

이제 정확한 예를 보자

http://www.google.com/fistpage.html

위에서 http://www.google.com/fistpage.html ( URL )을 사용하여 firstpage.html ( URI ) 페이지와 통신 할 수 있습니다 .

따라서 URI는 URL의 하위 집합이지만 그 반대는 아닙니다.

URI (Uniform Resource Identifier)는 인터넷 리소스를 식별하는 문자열입니다.

가장 일반적인 URI는 인터넷 도메인 주소를 식별하는 URL (Uniform Resource Locator)입니다. 일반적이지 않은 URI의 또 다른 유형은 URI (Universal Resource Name)입니다.

나는 찾았다 :

URI (Uniform Resource Identifier)는 큰 그림을 나타냅니다. URI를 분할 할 수 있습니다 / URI는 로케이터 (uniform resource locators-URL) 또는 이름 (uniform resource name-URN) 또는 둘 다로 분류 될 수 있습니다. 따라서 기본적으로 URN은 사람의 이름과 같은 기능을하며 URL은 해당 사람의 주소를 나타냅니다. 간단히 말해 URN은 아이템의 아이덴티티를 정의하고, URL은 아이템을 찾는 방법을 정의하며, 마지막으로이 두 가지 개념을 캡슐화하는 것은 URI입니다

최고의 (기술적) 요약 imo 는 이것입니다

IRI, URI, URL, URN 및 Jan Martin Keil 과의 차이점 :

IRI, URI, URL, URN 및 차이점

시맨틱 웹을 다루는 모든 사람들은 IRI , URI , URL 및 URN 이라는 용어를 반복해서 사용합니다 . 그럼에도 불구하고, 나는 그들의 정확한 의미에 대해 약간의 혼란이 있다는 것을 자주 관찰한다. 물론 다른 사람들도 그 사실을 알아 차 렸습니다 (예 : RFC3305 또는 Google 검색 참조). 솔직히, 나는 처음부터 나 자신도 혼란 스러웠다. 그러나 실제로 문제는 그렇게 복잡하지 않습니다. 언급 된 용어의 정의를 살펴보고 차이점이 무엇인지 살펴 보겠습니다.

URI

통일 자원 식별자는 추상적 또는 물리적 자원을 식별 문자의 소형 순서입니다. 문자 세트는 일부 예약 문자를 제외하고 US-ASCII로 제한됩니다. 허용 된 문자 집합 이외의 문자는 퍼센트 인코딩을 사용하여 표현할 수 있습니다. URI는 로케이터, 이름 또는 둘 다로 사용될 수 있습니다. URI가 로케이터 인 경우 리소스의 기본 액세스 메커니즘을 설명합니다. URI가 이름 인 경우 고유 한 이름을 지정하여 리소스를 식별합니다. URI의 구문 및 의미의 정확한 사양은 첫 번째 콜론 앞의 문자로 정의 된 사용 된 체계에 따라 다릅니다. [RFC3986]

항아리

범용 리소스 이름 계획 항아리에 URI가 지속적 위치 독립적 인 리소스 식별자 역할을하기위한 것입니다. 역사적으로이 용어는 모든 URI를 가리 킵니다. [RFC3986] URN은 NID (Namespace Identifier)와 NSS (Namespace Specific String)로 구성됩니다. urn :: NSS의 구문과 의미는 각 NID에 따라 다릅니다. 등록 된 NID 외에 공식 등록 절차를 거치지 않은 NID가 몇 개 더 있습니다. [RFC2141]

URL

범용는 리소스를 식별하는 외에, 그 기본 액세스 메커니즘 [RFC3986]을 설명함으로써 자원을 위치시키는 수단을 제공하는 URI이다. 스킴 세트에 의한 URL의 정확한 정의가 없기 때문에, "URL은 유용하지만 비공식적 인 개념"이며, 일반적으로 URN을 포함하지 않는 URI의 서브 세트를 말합니다 [RFC3305].

IRI

국제화 자원 식별자 는 URI와 유사하게 정의되지만, 문자 세트는 범용 코딩의 문자 세트로 확장됩니다. 따라서 예약 문자를 제외한 라틴 및 비 라틴 문자를 포함 할 수 있습니다. URI의 정의를 확장하는 대신, IRI라는 용어가 명확하게 구분되고 비 호환성을 피하기 위해 도입되었습니다. IRI는 범용 코드화 문자 세트가 지원되는 상황에서 자원을 식별 할 때 URI를 대체하기위한 것입니다. 정의상 모든 URI는 IRI입니다. 또한 URI에 대한 IRI의 정의 된 매핑 매핑이 있습니다. 모든 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 URI [LINKED-DATA]를 사용하는 것이 좋습니다. 간단히 말해 : 엔티티 이름을 지정할 때는 URL 만 사용하십시오. 물론 URN으로 명명 된 기존 엔터티를 참조 할 수 있습니다. 그러나 이런 종류의 식별자를 새로 만들지 않아야합니다.