URI, URL 및 URN의 차이점은 무엇입니까?

질문자 :Sean McMains

사람들은 URL , URI , URN 에 대해 서로 다른 것처럼 이야기하지만 육안으로는 동일하게 보입니다.

그들 사이의 구별 가능한 차이점은 무엇입니까?

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

예

• 로저 페이트

이것은 식별자인 내 이름입니다. URI와 비슷하지만 URL이 될 수 없습니다. 내 위치나 나에게 연락하는 방법에 대해 알려주지 않기 때문입니다. 이 경우 미국에서만 최소 5명의 다른 사람을 식별하는 일이 발생합니다.

• 4914 West Bay Street, 나소, 바하마

이것은 물리적 위치에 대한 식별자인 로케이터입니다. URL과 URI(모든 URL은 URI이기 때문에)와 같으며 간접적 으로 "..의 거주자"로 식별합니다. 이 경우 저를 고유하게 식별하지만 룸메이트가 생기면 변경됩니다.

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

대중의 혼란

위키피디아에서 :

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

이러한 일반적인 혼동으로 인해 많은 제품 및 설명서에서 다른 용어 대신 한 용어를 잘못 사용하거나 고유한 구분을 지정하거나 동의어로 사용합니다.

URN

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

현재 이 이름을 다른 사람들과 공유하고 있기 때문에 전 세계적으로 고유하지 않으며 URN으로 적합하지 않습니다. 그러나 다른 가족이 이 이름을 사용하지 않았더라도 나는 외할아버지의 이름을 따서 지었기 때문에 시간이 흘러도 여전히 고유하지 않습니다. 그리고 그것이 사실 이 아니더라도 내 후손의 이름을 따서 명명할 가능성이 있어 URN으로 적합하지 않습니다.

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

Roger Pate

RFC 3986에서 :

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

따라서 모든 URL은 URI이고 모든 URN은 URI입니다. 그러나 URN과 URL은 다르기 때문에 모든 URI가 URL이라고 말할 수는 없습니다.

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

Jon Skeet

URI -- 통일 자원 식별자

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

URL -- Uniform Resource Locator

해당 위치에서 리소스를 가져오는 방법에 대한 정보를 포함합니다. 예를 들어:

• 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 -- 통일 자원 인용

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

데이터 URI

인터넷에서 찾거나 이름을 지정하는 대신 데이터를 URI에 직접 배치할 수 있습니다. 예는 data:,Hello%20World 입니다.

---

자주 묻는 질문

더 이상 URL을 말하면 안 된다고 들었는데, 왜?

HTML에 대한 W3 사양 은 앵커 태그 href 가 URL뿐만 아니라 URI를 포함할 수 있다고 말합니다. <a href="urn:isbn:0451450523"> 와 같은 URN을 입력할 수 있어야 합니다. 그러면 브라우저가 해당 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를 URL, URN 및 URC와 같은 다른 유형으로 엄격하게 분할하는 것은 더 이상 유용하지 않습니다.

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

URN의 정의는 이제 위에서 언급한 것보다 느슨합니다. URI에 대한 최신 RFC는 "이름의 속성"이 있는 한 모든 URI가 이제 URN이 될 수 있다고 말합니다( urn: 즉, 리소스가 더 이상 존재하지 않거나 사용할 수 없게 되는 경우에도 전역적으로 고유하고 지속적입니다. http://www.w3.org/TR/html4/strict.dtd 와 같은 HTML 문서 유형에 사용되는 URI. 해당 URI는 w3.org 웹 사이트의 페이지가 삭제된 경우에도 계속해서 HTML4 전환 문서 유형의 이름을 지정합니다.

---

Stephen Ostermiller

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

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

urn:isbn:0-486-27557-4 로 식별할 수 있습니다.
그것은 URI이지만 더 구체적으로 URN * 입니다. 왜냐하면 그것이 text 의 이름을 지정 하기 때문입니다.

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

*균일한 리소스 이름

(내 예제는 Wikipedia에서 수정한 것임에 유의하십시오.)

Greg

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

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

URI - /some/page.html

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

URI는 현재 도메인의 리소스이므로 찾는 데 필요한 정보가 적습니다.

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

Phil Sturgeon

우선 혼란에서 벗어나 단순하게 생각하면 이해하게 될 것입니다.

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만

user7987783

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

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

Gustavo Mori

신원 = 이름과 위치

모든 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]
• urn: 및 : 스스로를 의미합니다.
• 예 :
• 항아리: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,file,man,info,whatis,ldap...
• 예:
• http://ip_server/path?쿼리
• ftp://ip_server/경로
• mailto:이메일 주소
• 뉴스:뉴스 그룹 이름
• 텔넷://ip_server/
• file://ip_server/path_segments
• ldap://hostport/dn?attributes?scope?filter?extensions

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

Premraj

이것은 내가 웹 전문가로서 만난 가장 혼란스럽고 아마도 관련이 없는 주제 중 하나입니다.

내가 이해하는 것처럼 URI는 허용된 형식에 따라 무언가에 대한 설명으로, 무언가 또는 그 위치의 고유한 이름(식별) 또는 둘 모두를 정의할 수 있습니다.

두 가지 기본 하위 집합이 있습니다.

• 위치를 정의하는 URL(특히 웹페이지를 조회하려는 브라우저) 및
• 무언가의 고유한 이름을 정의하는 URN.

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

나는 또한 URI라는 용어를 완전히 피하고 URL이나 URN의 관점에서 적절하게만 논의하는 경향이 있습니다. 왜냐하면 너무 많은 혼란을 야기하기 때문입니다. 우리가 사람들을 위해 정말로 대답하려고 시도해야 하는 질문은 의미론이 아니라 프로그래밍 상황에 대한 접근 방식을 변경할 실제적인 차이점이 있는지 여부를 용어를 만날 때 식별하는 방법입니다. 예를 들어, 누군가가 대화 중에 나를 수정하고 "오, 그건 URL이 아니라 URI입니다"라고 말한다면 그들이 가득 차 있다는 것을 압니다. 누군가가 "URN을 사용하여 리소스를 정의하고 있습니다"라고 말하면 서버에서 위치를 찾지 않고 고유하게 이름을 지정한다는 것을 이해할 가능성이 더 큽니다.

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

Kevin Lowe

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

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

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

Craig Wilson

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

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

이 경우 com.mycompany.mynode는 내 XML 문서 내에서 사용하는 모든 요소에 대해 "myPrefix" 네임스페이스를 고유하게 식별하는 URI가 됩니다. 이것은 URL이 아닙니다. 그 자체로 무언가를 찾는 것이 아니라 식별하는 데만 사용되기 때문입니다.

D.C.

그들은 같은 것 입니다. URI는 URL의 일반화입니다. 원래 URI는 URL(주소)과 URN(이름)으로 나눌 예정이었으나 URL과 URI의 차이가 거의 없었고 실제로 리소스를 찾지는 못했지만 http URI를 네임스페이스로 사용했습니다.

Mark Cidade

URI와 URL을 명확하게 구별하는 것이 어렵기 때문에 W3C는 더 이상 URI와 URL( http://www.w3.org/Addressing/ )을 구분하지 않습니다.

manuel aldana

URI, URL, URN

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

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

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

Adiii

URI는 일종의 URL 및 URN의 수퍼 클래스입니다. Wikipedia에는 올바른 RFC 세트에 대한 링크와 함께 이에 대한 훌륭한 기사가 있습니다.

André

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

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

Peter Boughton

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

Sujit

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

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

Swapnil

RFC 3986에 따라 URI는 다음 부분으로 구성됩니다.

 scheme://authority/path?query

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

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

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

위키피디아

Prashanth Sams

URI와 URL이라는 용어는 엄격하게 정의되어 있지만 많은 사람들이 정의된 것과 다른 용도로 용어를 사용합니다.

아파치를 예로 들어보자. 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

이것이 일부 혼란의 이유일 수 있습니다.

Gumbo

글을 읽어보니 관련성 높은 댓글이 몇 개 보입니다. 요컨대, 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:scheme-specific-part를 갖도록 특별히 정의됩니다. 이것은 URL이며 URI이기도 합니다. 이제 ../index.html과 같은 페이지에 포함된 상대 링크를 고려하십시오. 이것은 더 이상 정의에 따른 URL이 아닙니다. 여전히 "URI-참조"[RFC2396]라고 하는 것입니다.

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

paul r

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

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

사실 아주 명확한 용어는 아닙니다.

avpx

내 단순화는 다음과 같습니다.

URN: 고유한 리소스 이름, 즉 "무엇"(예: 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로 참조할 수 있다는 사실에 위안을 얻을 수 있습니다. 어느 쪽이든 옳을 것입니다(적어도 당분간은 .. .)

jjolla

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

일부 URI는 리소스를 찾기 위한 정보(예: DNS 호스트 이름 및 해당 시스템의 경로)를 제공하지만 일부는 순수한 리소스 이름으로 사용됩니다. URL 은 호스트의 지정된 경로에서 웹 페이지를 식별하는 http://stackoverflow.com 과 같은 'http' URL을 포함하여 리소스 로케이터 인 식별자용으로 예약되어 있습니다. 또 다른 예로는 mailto:fred@mail.org 와 같은 'mailto' URL이 있으며, 이는 주어진 주소에서 메일함을 식별합니다.

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

dpant

나는 같은 것에 대해 궁금해하고 이것을 찾았습니다 : http://docs.kohanaphp.com/helpers/url .

url::current() 메서드를 사용하면 명확한 예를 볼 수 있습니다. URL 이 http://example.com/kohana/index.php/welcome/home.html?query=string 경우 url:current() 사용하면 문서에 따르면 다음과 같은 URI 가 제공됩니다. welcome /집

Community Wiki

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

s3://www-example-com/index.html _{[그림. 1]}

캐시된 사본으로 만든

http://www.example.com/index.html _{[그림. 2]}

Amazon의 S3-US-West-2 데이터 센터에 있습니다.

s3:// 프로토콜 체계에 대한 하이퍼링크를 허용하더라도 리소스 를 찾는 데 아무런 도움이 되지 않습니다. 리소스를 식별 하기 때문에 , 그림. 1 은 유효한 URI입니다. authority 부분에 대한 용어)이 데이터 센터에서 고유해야 하기 때문에 유효한 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

Bruno Bronosky

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

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

IRI, URI, URL, URN 및 차이점

Semantic Web을 다루는 모든 사람은 IRI , URI , URL 및 URN 이라는 용어를 반복적으로 접하게 됩니다. 그럼에도 불구하고 나는 그 정확한 의미에 대해 약간의 혼란이 있음을 자주 목격합니다. 그리고 물론 다른 사람들도 이를 알아차렸습니다(예: RFC3305 참조 또는 Google 검색). 솔직히 나도 처음에는 어리둥절했다. 그러나 실제로 문제는 그렇게 복잡하지 않습니다. 차이점이 무엇인지 확인하기 위해 언급된 용어의 정의를 살펴보겠습니다.

URI

UID(Uniform Resource Identifier) 는 추상 또는 물리적 리소스를 식별하는 간결한 문자 시퀀스입니다. 문자 집합은 일부 예약 문자를 제외하고 US-ASCII로 제한됩니다. 허용된 문자 집합을 벗어난 문자는 백분율 인코딩을 사용하여 나타낼 수 있습니다. URI는 로케이터, 이름 또는 둘 다로 사용할 수 있습니다. URI가 로케이터인 경우 리소스의 기본 액세스 메커니즘을 설명합니다. URI가 이름인 경우 고유한 이름을 지정하여 리소스를 식별합니다. URI 구문 및 의미의 정확한 사양은 첫 번째 콜론 이전의 문자로 정의되는 사용된 Scheme에 따라 다릅니다. [RFC3986]

항아리

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

URL

Uniform Resource Locator 는 리소스를 식별하는 것 외에도 기본 액세스 메커니즘을 설명하여 리소스를 찾는 수단을 제공하는 URI입니다[RFC3986]. 일련의 체계를 통해 URL에 대한 정확한 정의가 없기 때문에 "URL은 유용하지만 비공식적인 개념"이며 일반적으로 URN을 포함하지 않는 URI의 하위 집합을 나타냅니다[RFC3305].

아이리

Internationalized Resource Identifier 는 URI와 유사하게 정의되지만 문자 집합은 Universal Coded Character Set으로 확장됩니다. 따라서 예약된 문자를 제외한 모든 라틴 및 비 라틴 문자를 포함할 수 있습니다. URI의 정의를 확장하는 대신 IRI라는 용어를 도입하여 명확한 구분을 허용하고 비호환성을 방지했습니다. IRI는 Universal Coded Character Set이 지원되는 상황에서 리소스를 식별할 때 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 URI [LINKED-DATA]를 사용하는 것이 좋습니다. 간단히 말해서 URL을 사용하여 엔티티의 이름을 지정하십시오. 물론 URN으로 명명된 기존 엔터티를 참조할 수 있습니다. 그러나 이러한 종류의 식별자를 새로 만드는 것은 피해야 합니다.

Mischa

설명하기 쉬움:

다음을 가정하자

URI는 당신의 이름입니다

URL은 귀하와 통신하기 위해 귀하의 이름과 함께 귀하의 주소입니다.

• 내 이름은 로욜라

  로욜라는 URI입니다

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

TN, Chennai 600 001, Loyola는 URL입니다.

이해 바랍니다.

이제 정확한 예를 보자

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

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

따라서 URI는 URL의 하위 집합이지만 그 반대의 경우도 마찬가지입니다.

loyola

나는 발견했다:

---

URI(Uniform Resource Identifier)는 큰 그림을 나타냅니다. URI를 분할할 수 있습니다. URI는 로케이터(균일 리소스 로케이터-URL), 이름(균일 리소스 이름-URN) 또는 둘 다로 분류될 수 있습니다. 따라서 기본적으로 URN은 사람의 이름과 같은 기능을 하고 URL은 그 사람의 주소를 나타냅니다. 간단히 말해서 URN은 항목의 ID를 정의하고 URL은 항목을 찾는 방법을 정의합니다. 마지막으로 이 두 개념을 캡슐화하는 것이 URI입니다.

Rakeeb Rajbhandari

대답은 모호합니다. Java에서는 다음과 같이 자주 사용됩니다.

URL(Uniform Resource Locator)은 체계(http, https, ftp, news 등)를 포함하는 인터넷 리소스를 식별하는 데 사용되는 용어입니다. 예를 들어 URI, URL 및 URN의 차이점은 무엇입니까?

URI(Uniform Resource Identifier)는 웹 서버에서 단일 문서를 식별하는 데 사용됩니다. 예: /questions/176264/whats-the-difference-between-a-uri-and-a-url

Java 서블릿에서 URI는 웹 애플리케이션 컨텍스트가 없는 문서를 자주 참조합니다.

Freeman

출처 : 여기를 클릭하세요

출처 : http:www.stackoverflow.com/questions/176264/what-is-the-difference-between-a-uri-a-url-and-a-urn