통합 자원 식별자

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사
- 2.1. 개념
- 2.2. 발전
3. 설계
4. 스킴(Scheme)
- 4.1. 공식 등록된 스킴
- 4.2. 일반적인 비등록 스킴
5. 프로그래밍 지원
참조

1. 개요

통합 자원 식별자(URI)는 자원을 식별하는 데 사용되는 문자열로, URL(Uniform Resource Locator)과 URN(Uniform Resource Name)을 포함한다. 1990년 팀 버너스 리의 하이퍼텍스트 제안에서 URL 개념이 처음 등장했으며, 이후 IETF에서 URI 구문이 정의되었다. URI는 스키마, 권한, 경로, 쿼리, 프래그먼트 등의 구성 요소로 이루어져 있으며, 예약 문자는 퍼센트 인코딩을 통해 표현된다. IANA에 공식 등록된 다양한 스킴이 존재하며, 프로그래밍 언어에서도 URI를 다루기 위한 클래스 라이브러리를 제공한다.

더 읽어볼만한 페이지

URL - URL 단축
URL 단축은 긴 URL 주소를 짧게 변환하여 가독성과 공유를 용이하게 하는 기술 또는 서비스로, 소셜 미디어나 메시징 플랫폼에서 유용하며 QR 코드 최적화, 데이터 분석 등의 기능을 제공하지만 악용될 가능성과 링크 부패의 위험성도 존재한다.
URL - URL 리다이렉션
URL 리다이렉션은 사용자를 다른 웹 페이지로 자동 이동시키는 기술이며, HTTP 상태 코드를 통해 구현되고 보안, URL 축약, 장치 타겟팅 등 다양한 목적으로 활용되지만, 보안 문제와 피싱 공격에 악용될 위험도 존재한다.
시맨틱 웹 - 시맨틱 네트워크
시맨틱 네트워크는 개념 간의 관계를 표현하는 지식 표현 방법으로, 노드와 링크를 사용하여 지식을 구조화하며 인공지능, 언어학 등 다양한 분야에서 활용된다.
시맨틱 웹 - 웹 온톨로지 언어
웹 온톨로지 언어(OWL)는 시맨틱 웹 구축을 위한 지식 표현 언어로, W3C 웹 표준이며, 온톨로지 명시적 표현을 통해 데이터 공유 및 재사용을 가능하게 하고, 기술 논리에 기반하여 표현력 수준에 따라 다양한 종류를 제공한다.
응용 계층 프로토콜 - 실시간 전송 프로토콜
실시간 전송 프로토콜(RTP)은 스트리밍 미디어의 실시간 전송을 위해 설계된 프로토콜로, IP 네트워크에서 오디오/비디오 전송의 표준으로 사용되며, 멀티미디어 데이터 전송, 타임스탬프, 순서 제어, QoS 피드백 등을 제공한다.
응용 계층 프로토콜 - D-Bus
D-Bus는 2002년에 시작된 프로세스 간 통신 시스템으로, 시스템 버스와 세션 버스를 통해 정보 공유, 모듈성, 권한 격리를 제공하며, 일대일 요청-응답 및 발행/구독 통신 방식을 지원한다.

통합 자원 식별자
개요
명칭	통합 자원 식별자 (URI)
영어 명칭	Uniform Resource Identifier
약어	URI
관련 RFC	RFC 3986
기술 정보
개발 시작 연도	2005년
최초 게시일	2005년 1월
관련 단체	RFC
작성자	팀 버너스-리 로이 토머스 필딩 래리 매신터
관련 분야	월드 와이드 웹
웹사이트	RFC 3986
상세 내용
설명	웹 또는 인터넷 리소스의 이름을 식별하는 데 사용되는 문자열
관련 용어	URL (Uniform Resource Locator)

2. 역사

URI와 URL은 역사를 공유한다. 1994년 팀 버너스 리가 하이퍼텍스트를 제안하면서 하이퍼링크의 대상이 되는 자원을 대표하는 짧은 문자열로 URL의 개념을 암묵적으로 도입하였다. 당시 사람들은 이를 "하이퍼텍스트 이름" 또는 "문서 이름"으로 불렀다. 이후 3년 반 동안, 월드 와이드 웹의 핵심 기술인 HTML, HTTP, 웹 브라우저가 발전하면서, 자원의 주소를 제공하는 문자열과 단순히 자원을 명명하는 문자열을 구별해야 할 필요성이 생겨났다. URL과 URN을 정의하는 과정에서, 두 용어가 담고 있는 개념이 자원 ''식별''이라는 근본적이고 포괄적인 개념의 측면에 불과하다는 것이 명백해졌다.

1994년 12월, IETF는 상대 및 절대 URL을 공식적으로 정의하고, 일반 URL 구문을 다듬었으며, 상대 URL을 절대 형식으로 해석하는 방법을 정의하고, 당시 사용되던 URL 스키마를 더 자세히 열거했다. URN의 합의된 정의와 구문은 1997년 5월 IETF RFC 2141 발표까지 기다려야 했다.

2001년, 월드 와이드 웹 컨소시엄(W3C) 기술 아키텍처 그룹(TAG)은 주어진 리소스의 여러 버전을 게시하기 위한 모범 사례 및 표준 URI에 대한 가이드를 발표했다.^[5]

2002년 8월, IETF는 "URL"이라는 용어가 거의 쓸모없게 되었으며, 네트워크 접근성을 암시하는 스키마를 가지고 있어 실제로 사용 여부와 관계없이 주소 역할을 하는 일부 URI를 상기시키는 역할만 한다고 지적했다. 자원 기술 프레임워크와 같은 URI 기반 표준에서 분명히 알 수 있듯이, 리소스 식별은 인터넷을 통한 리소스 표현의 검색을 암시할 필요가 없으며, 네트워크 기반 리소스를 전혀 암시할 필요도 없다.

시맨틱 웹은 문서와 개념을 모두 식별하기 위해 HTTP URI 스키마를 실용적인 용도로 사용하며, 이로 인해 둘을 구별하는 방법에 대한 혼란이 발생했다. ''TAG''는 2005년에 이 문제에 대한 해결책을 담은 이메일을 발표했는데, 이는 ''httpRange-14 해결책''으로 알려지게 되었다.^[6] W3C는 이후 콘텐츠 협상과 HTTP 303 리디렉션 응답 코드를 더 자세히 설명하는 "시맨틱 웹을 위한 멋진 URI"라는 제목의 관심 그룹 노트를 발표했다.^[7]

2. 1. 개념

1990년, 팀 버너스리의 하이퍼텍스트 제안은 하이퍼링크의 대상인 자원을 나타내는 짧은 문자열로서의 URL 개념을 암묵적으로 도입했다.^[1] 당시 사람들은 이를 "하이퍼텍스트 이름"^[2] 또는 "문서 이름"이라고 불렀다.

1994년 6월, IETF는 URL과 URN의 존재를 인정한 버너스리의 첫 번째 ''Request for Comments''를 발표했다. 가장 중요한 점은, ''Universal Resource Identifiers'' (즉, URL과 유사한 문자열로서, 정확한 구문과 의미는 스키마에 따라 달라짐)에 대한 공식적인 구문을 정의했다는 것이다. 또한 IETF RFC 1630은 당시 사용되던 URL 스키마의 구문을 요약하려고 시도했다.^[3]

2. 2. 발전

팀 버너스 리가 하이퍼텍스트를 제안하면서 1994년에 URL 개념이 암묵적으로 도입되었다. 1998년 URI 구문이 별도 사양으로 분리되었고, RFC 1630과 1738의 내용이 수정 및 확장되었다 (RFC|2396^영어). 이때 'U'의 의미가 "Universal"에서 "Uniform"으로 변경되었다.^[4] 1999년 12월, RFC|2732^영어는 IPv6 주소를 수용할 수 있도록 업데이트되었다. 2005년 RFC|3986^영어이 발표되어 이전 표준을 폐기하고, URI 일반 구문이 공식 인터넷 프로토콜로 확립되었다.^[1]

3. 설계

RFC 2396 (1998년 8월)과 RFC 3986 (2005년 1월)은 URI 설계를 정의하는 중요한 문서이다.^[1] 1994년에 통합 자원 위치 지정자(URL)과 통합 자원 이름(URN) 개념이 정의된 이후, 1998년에 URI 구문이 별도 사양으로 확장되었고, 2005년에는 이전 표준을 대체하는 RFC 3986이 발표되었다.

URI는 크게 URL과 URN으로 나뉜다.

URL은 리소스의 위치를 나타내는 반면,
URN은 리소스의 고유한 이름을 나타낸다.

2001년 월드 와이드 웹 컨소시엄(W3C)은 URL과 URN 대신 URI라는 용어를 우선적으로 사용하도록 권고했다.^[8] 2002년 인터넷 엔지니어링 태스크 포스(IETF)는 URL이라는 용어가 네트워크 접근성을 암시하여 혼란을 야기한다고 지적했다. 최근에는 WHATWG에서 URI 대신 URL을 사용하며, HTML5 API에서도 URL 용어를 사용한다.^[9]

3. 1. URL과 URN

팀 버너스 리가 1994년 하이퍼텍스트를 제안하면서 하이퍼링크의 대상이 되는 자원을 대표하는 짧은 문자열로 URL의 개념을 암묵적으로 도입하였다.^[1] 당시에는 "하이퍼텍스트 이름" 또는 "문서 이름"으로 불렸다.^[2]

이후 월드 와이드 웹의 핵심 기술인 HTML, HTTP, 웹 브라우저가 발전하면서, 자원의 주소를 제공하는 문자열과 단순히 자원을 명명하는 문자열을 구별할 필요성이 생겨났다. '통합 자원 위치 지정자(URL)'는 전자를, '통합 자원 이름(URN)'은 후자를 나타내게 되었다. 1992년 7월 인터넷 엔지니어링 태스크 포스(IETF) 회의에서 URL과 URN이 언급되었고, 새로운 워킹 그룹 구성의 필요성이 제기되었다.^[3]

URL과 URN은 모두 자원 ''식별''이라는 개념의 측면이었다. 1994년 6월, IETF는 URL과 URN의 존재를 인정한 버너스리의 첫 번째 ''Request for Comments''를 발표했고, 당시 사용되던 URL 스키마의 구문을 요약했다.^[15] 1994년 12월, 상대 및 절대 URL을 공식적으로 정의하고, 일반 URL 구문을 다듬었으며, 상대 URL을 절대 형식으로 해석하는 방법을 정의했다. URN의 정의와 구문은 1997년 5월 IETF 발표까지 기다려야 했다.

1998년, URI 구문이 별도의 사양이 되면서(IETF), URI와 URL 관련 내용이 수정 및 확장되었다. ''URI''에서 ''U''의 의미가 "Universal"에서 "Uniform"으로 변경되었다.

2001년, 월드 와이드 웹 컨소시엄(W3C)은 URL과 URN으로의 공식적인 세분화를 지지하기보다는 URI라는 용어를 우선적으로 인정했다.^[8] URL은 네트워크를 통해 리소스를 가리키는 URI일 뿐이다.^[15]

2002년, IETF는 "URL"이라는 용어가 거의 쓸모없게 되었으며, 주소 역할을 하는 일부 URI를 상기시키는 역할만 한다고 지적했다.

WHATWG에서 제작한 사양은 ''URI''보다 ''URL''을 선호하며, 최신 HTML5 API는 ''URI'' 대신 ''URL''을 사용한다.^[9] URL 용어를 표준화하고, URI와 국제화된 자원 식별자(IRI)는 구분하지 않는다.^[10]

구분	설명
통합 자원 위치 지정자(URL)	자원의 "위치"를 식별한다. 네트워크 내의 위치를 나타내어 자원을 식별한다.
통합 자원 이름(URN)	자원의 "이름"을 식별한다. 네트워크 상에서 자원이 없어져도 고유하고 영속적으로 식별할 수 있게 한다.

3. 2. 구성 요소 및 문법

RFC 2396은 1998년 8월에, RFC 3986은 2005년 1월에 출판되었다.^[1]

일반 URI는 다음과 같은 형태를 나타낸다.

'''scheme:'''['''//'''['''user'''[''':password''']'''@''']'''host'''[''':port''']]['''/path'''][?'''query'''][#'''fragment''']

다음은 2개의 예시 URI와 구성 부분을 나타낸 표이다.

URI 예시	스키마	사용자 정보	호스트	포트	경로	쿼리	프래그먼트
ｈｔｔｐｓ：／／ｕｓｅｒｎａｍｅ：ｐａｓｓｗｏｒｄ＠ｅｘａｍｐｌｅ．ｃｏｍ：１２３／ｐａｔｈ／ｄａｔａ？ｋｅｙ＝ｖａｌｕｅ＃ｆｒａｇｉｄ１	ｈｔｔｐｓ	ｕｓｅｒｎａｍｅ：ｐａｓｓｗｏｒｄ	ｅｘａｍｐｌｅ．ｃｏｍ	１２３	／ｐａｔｈ／ｄａｔａ	ｋｅｙ＝ｖａｌｕｅ	ｆｒａｇｉｄ１
ｕｒｎ：ｅｘａｍｐｌｅ：ｍａｍｍａｌ：ｍｏｎｏｔｒｅｍｅ：ｅｃｈｉｄｎａ	ｕｒｎ				ｅｘａｍｐｌｅ：ｍａｍｍａｌ：ｍｏｎｏｔｒｅｍｅ：ｅｃｈｉｄｎａ

다음은 URI의 공통 구문으로, 모든 스키마 구문에서 처리하는 슈퍼세트의 정의이다.



URI = scheme:[//authority]path[?query][#fragment]

각 구성 요소에 대한 설명은 다음과 같다.

'''scheme(스키마)''': URI는 "스키마"라고 불리는 식별자로 시작하며 생략할 수 없다. 계층적 식별자인 :(콜론)은 스키마의 구분 기호로, 스키마 이름의 마지막에 삽입한다. 스키마 이름은 `문자`로 시작하며, `문자`, `숫자`, `+`(플러스 기호), `-`(하이픈), `.`(마침표)로 구성된 문자열이 된다. 대소문자를 구분하지 않지만, 일관성을 유지하기 위해 소문자 사용을 권장한다.

'''authority(권한)''': 권한은 `//`(더블 슬래시) 구분 기호로 시작한다. `userinfo`(사용자 정보) 및 `host`(호스트)의 처리는 각 스키마에 따라 다르다. URI의 고안자인 팀 버너스리는 2009년 10월 12일(현지 시간) 뉴욕 타임스에서 권한의 구분 기호인 더블 슬래시에 대해 "필요하지 않다는 것이 밝혀졌다"고 언급했다.^[18] (규격 제정 시, 더블 슬래시로 할 필요성은 없다는 취지이며, 제정된 규격에서 이것이 없어도 문제는 없다는 취지는 아니다.)

'''path(경로)''': URI에 권한이 포함된 경우, 경로에 문자가 없더라도 `/`(슬래시)로 시작해야 하며, 이로 인해 경로를 생략할 수 없다. 권한이 포함되지 않은 경우 `//`로 시작할 수 없다. 또한 상대 경로인 경우 `:`로 시작할 수 없다. 경로에 `?`(물음표), `#`(번호 기호)를 포함하거나 끝에 있는 경우, 경로의 끝을 나타낸다. 계층적으로 구성된 데이터가 포함되며, 계층은 `/`로 구분한다.

'''query(쿼리)''': 쿼리는 `?` 구분 기호로 시작하여 `#` 또는 끝에서 끝난다. 경로와 달리 계층적 데이터를 포함하지 않는다. RFC 3986 제3장 4절에서 명확한 구문은 제시되지 않았다.

'''fragment(프래그먼트, 조각)''': 프래그먼트는 `#` 구분 기호로 시작한다. 임의로 처리하며, 기본(1차) 리소스를 참조하고 보조(2차) 리소스에 제공하는 프래그먼트 식별자를 포함한다. 쿼리와 마찬가지로 명확한 구문은 제시되지 않았다. 예를 들어, 기본 리소스가 HTML 문서인 경우 요소의 `id` 속성에 임의의 값을 지정하고 프래그먼트에도 동일한 값을 지정하면, 웹 브라우저는 표시 시 해당 요소의 위치까지 스크롤한다. 위키백과에서는 "앵커"라고 하는 기능에 해당한다.

3. 3. 예약 문자와 퍼센트 인코딩

RFC 2396에 처음 정의되었고,^[1] RFC 3986으로 완성된 일반 URI와 절대 URI 참조 문법에서,^[2] URI 공통 구문에서 구분 기호로 예약된 문자(Reserved Characters)는 구성 요소 내에서 직접 사용할 수 없다.

예약 문자(^[2] 제2장 2절)
gen-delims	`:`	`/`	`?`	`#`	`[`	`]`	`@`
sub-delims	`!`	`$`	`&`	`'`	`(`	`)`	`*`	`+`	`,`	`;`	`=`

[와 ](대괄호)는 IPv6의 구분 문자이다. sub-delims는 URI 스킴의 사양에 따라 정의될 수 있다.

'''퍼센트 인코딩'''(Percent-Encoding)은 예약 문자 등을 URI에서 사용할 수 있도록 다른 형식으로 변환하는 방법이다. 퍼센트 기호(%)와 옥텟을 16진수로 표현한 문자를 조합한 형식으로 나타낸다. 예를 들어, 공백 문자( )를 퍼센트 인코딩하면 %20으로 변환된다.

'''예약되지 않은 문자'''(Unreserved Characters)는 제약 없이 구성 요소 내에서 자유롭게 사용할 수 있다. 예약되지 않은 문자는 다음과 같다(^[2] 제2장 3절).

영문자: A부터 Z, 그리고 a부터 z
숫자: 0부터 9
일부 기호: -, ., _(밑줄), ~(물결표)

물결표(~)는 오래된 URI 사양에 따라 종종 %7e로 변환되는 경우가 있지만, 물결표를 포함하여 예약되지 않은 문자의 변환은 원래 필요하지 않다.

4. 스킴(Scheme)

URI 스킴은 URI의 첫 부분으로, 특정 프로토콜이나 명명 체계를 나타낸다. 예를 들어, `http`나 `https`는 하이퍼텍스트 전송 프로토콜을, `ftp`는 파일 전송 프로토콜을 나타낸다.

4. 1. 공식 등록된 스킴

IANA(Internet Assigned Numbers Authority)에 공식적으로 등록된 스킴 목록이 존재한다.^[22] 주요 스킴은 다음과 같다.

공식 등록된 스킴 목록^[22]
스킴	명칭	사양서・출처	용도・비고
about	어바웃		주로 웹 브라우저의 정보 표시 등에 사용된다. RFC 6694가 정하는 토큰은 `blank` 하나뿐이지만, 고유 기능은 각 토큰을 참조하여 처리하는 것이 권장된다.
cid	콘텐츠 ID(Content Identifier)		HTML 형식의 전자 메일이나 MHTML에서는 MIME 멀티파트의 콘텐츠로 지정된 `Content-ID`가 존재할 경우, 문서에서 cid 스킴을 사용하여 참조할 수 있다. 예: `<img src="cid:example">`
data	데이터 URI(데이터 URL)		미디어 유형으로 지정된 콘텐츠를 데이터에 첨부하여 HTML 문서 등에서 참조할 수 있다. 콘텐츠가 일반 텍스트 외의 경우 Base64로 인코딩할 필요가 있다.
dav	웹다브 (WebDAV)
dns	도메인 네임 시스템
example	예		스킴 구문 예시를 위해 등록된 스킴. RFC 7595는 새로운 스킴을 등록하는 절차 및 가이드라인이다.
file			호스트의 파일 경로를 제시하는 스킴. 구문에서 나타내는 것처럼, 권한은 인증 정보가 필요하지 않고, 로컬 호스트라면 생략할 수 있으므로, `file:///`에서 경로가 시작된다.
ftp	파일 전송 프로토콜		#공통 구문 참조
h323	H.323
http https	하이퍼텍스트 전송 프로토콜	2장 7절 1항 및 2장 7절 2항	#http/https 스킴의 구문 예시 참조
rtsp rtspu rtsps	실시간 스트리밍 프로토콜		일반적으로 rtsp와 rtsps의 통신 프로토콜은 TCP이지만, rtspu는 UDP가 된다.
sms	단문 메시지 서비스
tel	전화번호
ws wss	웹소켓		포트 번호의 기본값은 http/https와 동일하다.

4. 2. 일반적인 비등록 스킴

웹 브라우저나 HTML 문서에서 자바스크립트를 실행하는 수단으로 사용된다. 초안 상태였지만 2011년 3월 29일에 기한이 만료되었다.^[23]

5. 프로그래밍 지원

몇몇 프로그래밍 언어나 환경에서는 네트워크 통신 등에서 URI를 다룰 때 편리한 클래스 라이브러리가 표준으로 제공된다. Java에서는 `java.net.URI`가, .NET에서는 `System.Uri`가 제공된다.^[24] 안드로이드에서는 `android.net.Uri` 클래스가 제공된다.^[25] 일반적으로 네트워크 리소스뿐만 아니라, 로컬 파일 시스템 상의 리소스를 통일적으로 가리키는 목적으로도 사용된다.

참조

_[1] 웹사이트 The Early History of HTML http://infomesh.net/[...] 2020-12-06
_[2] 웹사이트 W3 Naming Schemes https://www.w3.org/H[...] 2020-12-06
_[3] 웹사이트 Proceedings of the Twenty-Fourth Internet Engineering Task Force https://www.ietf.org[...] 2021-07-27
_[4] 웹사이트 Proceedings of the Twenty-Fifth Internet Engineering Task Force https://www.ietf.org[...] 2021-07-27
_[5] 웹사이트 On Linking Alternative Representations To Enable Discovery And Publishing https://www.w3.org/2[...] 2020-12-06
_[6] 웹사이트 "[httpRange-14] Resolved" https://lists.w3.org[...] 2020-12-06
_[7] 웹사이트 Cool URIs for the Semantic Web https://www.w3.org/T[...] 2020-12-06
_[8] 웹사이트 URIs, URLs, and URNs: Clarifications and Recommendations 1.0 https://www.w3.org/T[...] W3C/IETF 2020-12-08
_[9] 웹사이트 URL Standard: 6.3. URL APIs elsewhere https://url.spec.wha[...]
_[10] 웹사이트 URL Standard: Goals https://url.spec.wha[...]
_[11] 간행물 拡張可能なマーク付け言語 (XML) 1.0 2005
_[12] 서적 Foundations of modern networking : SDN, NFV, QoE, IoT, and Cloud https://www.worldcat[...] 2016-01-01
_[13] IETF Uniform Resource Identifier (URI): Generic Syntax 2005-01-01
_[14] IETF Uniform Resource Identifier (URI): Generic Syntax
_[15] IETF RFC URIs, URLs, and URNs: Clarifications and Recommendations 1.0 https://www.w3.org/T[...]
_[16] 웹사이트 URL Standard Goals https://url.spec.wha[...] WHATWG 2017-06-23
_[17] 웹사이트 URL Standard （日本語訳）目標 https://triple-under[...] 2017-06-23
_[18] 뉴스 The Web’s Inventor Regrets One Small Thing https://bits.blogs.n[...] 2021-08-31
_[19] 웹사이트 ウェブ上のリソースの識別 https://developer.mo[...] Mozilla 2021-09-05
_[20] 웹사이트 URLSearchParams https://developer.mo[...] Mozilla 2021-08-31
_[21] IETF RFC
_[22] 웹사이트 Uniform Resource Identifier (URI) Schemes https://www.iana.org[...] IANA 2021-09-01
_[23] 웹사이트 draft-hoehrmann-javascript-scheme-03 https://tools.ietf.o[...] Internet Engineering Task Force 2021-09-08
_[24] Microsoft Learn Uri Class (System) | Microsoft Learn https://learn.micros[...]
_[25] Android Developers Uri | Android Developers https://developer.an[...]

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com