Page semi-protected

URL

URL
URL
통일된 자원 로케이터
줄임말URL
상황출판된
초판1994년, 28년 전(연간)
최신 버전생활 기준
2022
조직인터넷 기술 특별 조사위원회(IETF)
위원회.웹 하이퍼텍스트 애플리케이션 테크놀로지 워킹 그룹(WHATWG)
시리즈코멘트 요구(RFC)
에디터앤 반 케스테렌
작가들팀 버너스 리
기본 규격
  • RFC3986. – Uniform Resource Identifier(URI): 범용 구문.
  • RFC 4248 - telnet URI 스킴
  • RFC 4266 - Gopher URI 스킴
  • RFC 6068. – 'mailto' URI 스킴.
  • RFC 6196. – 메일 서버: URI 스킴을 이력으로의 이행.
  • RFC 6270. – 'tn3270' URI 스킴.
관련 기준URI, URN
도메인월드 와이드 웹
면허증.CC 기준 4.0
웹 사이트url.spec.whatwg.org

Uniform Resource Locator(URL; 균일한 자원 로케이터)는, 통칭 Web [1]주소라고 불리며, 컴퓨터 네트워크상의 위치를 지정하는 Web 자원과 그것을 취득하는 메카니즘을 참조합니다.URL은 Uniform Resource Identifier(URI;[2][3] 유니폼자원 식별자)의 특정 유형이지만 많은 사람들이 두 용어를 [4][a]서로 바꾸어 사용합니다.URL은 가장 일반적으로 참조 웹 페이지(HTTP)에 발생하지만 File Transfer(FTP; 파일 전송), Email To(메일 전송), Database Access(JDBC; 데이터베이스 액세스) 및 기타 많은 응용 프로그램에도 사용됩니다.

대부분의 웹 브라우저는 웹 페이지의 URL을 주소 표시줄의 페이지 위에 표시합니다.일반적인 URL은 다음과 같은 형식을 가질 수 있습니다.http://www.example.com/index.html(프로토콜을 나타냅니다).http호스트명( )www.example.com파일명( )을 지정합니다.index.html).

역사

Uniform Resource Locators는 World Wide Web의 발명자인 Tim Berners-Lee와 Internet Engineering Task Force(IETF;[7] 인터넷 기술 특별 조사위원회)의 URI 작업 그룹에 의해 1992년 [7][8]IETF Living Documents of a feather session에서 시작된 협업의 결과로 1994년에 RFC 1738에서 정의되었습니다.

이 형식은 기존의 도메인 이름 시스템(1985년에 작성)과 파일 경로 구문을 결합하여 디렉토리와 파일 이름을 구분하는 데 슬래시를 사용합니다.완전한 파일 경로에 서버 이름 앞에 이중 슬래시( )를 붙일 수 있는 규칙이 이미 존재했습니다.//를 참조해 주세요.[9]

Berners-Lee는 나중에 URI 내에서 도메인 이름의 일부를 구분하기 위해 점을 사용한 것에 대해 유감을 표명했으며 [9]URI의 첫 번째 구성 요소 뒤에 있는 콜론을 고려할 때 도메인 이름 앞에 두 개의 슬래시가 [10]불필요하다고 말했다.

HTML 사양의[11] 초기(1993) 초안에서는 "유니버설" 자원 로케이터를 언급했습니다.이것은 1994년 6월(RFC 1630)과 1994년 10월(draft-ietf-uri-url-08.[12]txt) 사이에 폐기되었습니다.

구문

모든 HTTP URL은 범용 URI 구문에 준거합니다.URI 범용 구문은 다음 5개의 [13]컴포넌트로 이루어진 계층 시퀀스로 구성됩니다.

URI = 구성표 ": "[//" 권한 경로 ["?" 쿼리] ["#" 조각]

여기서 권한 구성요소는 세 가지 하위 구성요소로 나뉩니다.

authority = [userinfo "@" host [:" 포트]

이는 구문 다이어그램에서 다음과 같이 나타납니다.

URI syntax diagram

URI는 다음과 같이 구성됩니다.

  • 스킴 컴포넌트 뒤에 콜론이 계속)이 있습니다.:)는 문자로 시작하여 문자, 숫자 및 플러스(+)의 임의의 조합으로 구성됩니다.+기간(.또는 하이픈(-). 스킴은 대소문자를 구분하지 않지만 표준형식은 소문자이며 스킴을 지정하는 문서에서는 소문자를 사용해야 합니다.일반적인 스킴의 예는 다음과 같습니다.http,https,ftp,mailto,file,data그리고.irc. URI 스킴은 Internet Assigned Numbers Authority(IANA; 인터넷 할당 번호국)에 등록해야 합니다.단,[b] 실제로는 등록되지 않은 스킴이 사용됩니다.
  • 옵션의 권한 컴포넌트 앞에 슬래시를 2개 붙입니다(//구성 요소:
    • 옵션의 userinfo 서브컴포넌트.사용자명과 옵션의 패스워드 앞에 콜론을 붙일 수 있습니다( ).:) 뒤에 at 기호( )가 붙습니다.@)의 사용username:password는 보안상의 되지 않습니다.userinfo 서브컴포넌트는 첫콜론('콜론') 에 있는 수 없습니다.:콜론 뒤의 데이터가 빈 문자열(비밀번호 없음)이 아닌 한 userinfo 서브컴포넌트 내에 있습니다.
    • 호스트 서브 컴포넌트.등록명(호스트명을 포함하지만 이에 한정되지 않음) 또는 IP 주소로 구성됩니다.IPv4 주소는 닷 10 진표기로 하고, IPv6 주소는 괄호로 묶어야 합니다( ).[]를 참조해 주세요.[15][c]
    • 콜론 앞에 옵션의 포트 서브컴포넌트(:).
  • 슬래시로 구분된 일련의 경로 세그먼트로 구성된 경로 구성요소(/패스는 항상 URI에 정의되지만 정의된 패스는 비어 있을 수 있습니다(길이 제로).세그먼트가 비어 있을 수도 있으며, 이로 인해 두 개의 슬래시가 연속으로 발생할 수 있습니다.//패스 컴포넌트에 있습니다.경로 구성요소는 파일 시스템 경로와 정확히 유사하거나 파일 시스템 경로에 매핑될 수 있지만 항상 관련성을 의미하는 것은 아닙니다.권한 구성요소가 있는 경우 경로 구성요소는 비어 있거나 슬래시( )로 시작해야 합니다./authority 컴포넌트가 없는 경우 경로는 빈 세그먼트(슬래시 2개)로 시작할 수 없습니다.//) – 다음 문자는 권한 [17]컴포넌트로 해석되기 때문입니다.
규칙에 따라 http 및 https URI에서는 경로의 마지막 부분에 pathinfo라는 이름이 붙으며 이는 임의입니다.기존 물리 자원명(파일, 내부 모듈 프로그램 또는 실행 가능 프로그램 등)을 참조하지 않고 실행 가능 모듈 또는 프로그램에 의해 관리되는 경로의 첫 번째 부분에 별도로 전달되어야 하는 논리 부분(명령어 또는 한정자 부분 등)을 참조하지 않는 0개 이상의 경로 세그먼트로 구성됩니다.웹 서버. 이는 동적 콘텐츠(문서 등)를 선택하거나 요청에 따라 맞춤화하기 위해 자주 사용됩니다(CGI 및 PATH_INFO 등 참조).
예제:
URI:"http://www.example.com/questions/3456/my-document"
여기서:"/questions"경로의 첫 번째 부분(실행 가능한 모듈 또는 프로그램)입니다."/3456/my-document"pathinfo라는 이름의 경로의 두 번째 부분으로, pathinfo라는 이름의 실행 가능한 모듈 또는 프로그램에 전달됩니다."/questions"를 눌러 요청된 문서를 선택합니다.
쿼리 부분이 없는 pathinfo 부분을 포함하는 http 또는 https URI는 마지막 부분이 "slug"인 "clean URL"이라고도 할 수 있습니다.
쿼리 딜리미터 예
앰퍼샌드(&) key1=value1&key2=value2
세미콜론(;) [d]。 key1=value1;key2=value2
  • 옵션 쿼리 컴포넌트 앞에 물음표( )가 붙습니다.?)에는 비규칙 데이터의 쿼리 문자열이 포함되어 있습니다.구문은 잘 정의되어 있지 않지만, 통념상으로는 딜리미터로 구분된 속성-값 쌍의 시퀀스가 대부분입니다.
  • 해시 앞에 옵션의 fragment컴포넌트(#fragment에는 세컨더리 자원에 대한 방향을 나타내는 fragment ID가 포함되어 있습니다.예를 들어 URI의 나머지 부분에 의해 식별되는 기사 제목입니다.프라이머리 리소스가 HTML 문서인 경우 fragment는 특정 요소의 속성이며 웹 브라우저는 이 요소를 뷰로 스크롤합니다.

웹 브라우저는 보통 지정된 호스트에 대해 HTTP 요청을 실행하여 URL을 참조 해제합니다(기본적으로는 포트 번호80).를 사용한 URLhttps스킴에서는 웹 사이트에 대한 보안 연결을 통해 요청과 응답을 해야 합니다.

국제화된 URL

인터넷 사용자는 다양한 언어와 알파벳을 사용하여 전 세계에 분산되어 있으며, 자신의 지역 알파벳으로 URL을 만들 수 있을 것으로 기대된다.IRI(Internationalized Resource Identifier)는 Unicode 문자를 포함하는 URL 형식입니다.최신 브라우저는 모두 IRI를 지원합니다.다른 알파벳에 대한 특별한 처리가 필요한 URL 부분은 도메인 이름과 [19][20]경로입니다.

IRI 의 도메인명은, Internationalized Domain Name(IDN; 국제화 도메인명)이라고 불립니다.웹 및 인터넷 소프트웨어는 도메인 이름을 도메인 이름 시스템에서 사용할 수 있는 punycode로 자동 변환합니다(예: 중국어 URL).http://例子.卷筒纸된다http://xn--fsqu00a.xn--3lr804guic/.그xn--는 문자가 원래 [21]ASCII가 아님을 나타냅니다.

URL 경로 이름은 로컬 쓰기 시스템에서 사용자가 지정할 수도 있습니다.아직 인코딩되지 않은 경우 UTF-8로 변환되며 기본 URL 문자 세트의 일부가 아닌 문자는 percent-encoding을 사용하여 16진수로 이스케이프됩니다(일본어 URL 등). http://example.com/引き割り.html된다http://example.com/%E5%BC%95%E3%81%8D%E5%89%B2%E3%82%8A.html타겟 컴퓨터는 주소를 디코딩하여 [19]페이지를 표시합니다.

프로토콜 상대 URL

Protocol-relative 링크(프로랙틴), 또한protocol-relative URL(PRURL)로 알려져 있으며 URL이 없는 프로토콜을 구체화 했다.예를들면,//example.com는 현재 페이지의 프로토콜(일반적으로 HTTP 또는 HTTPS)[22][23]을 사용합니다.

「 」를 참조해 주세요.

메모들

  1. ^ URL은 지정된 리소스에 액세스하는 수단을 의미하며 프로토콜 또는 액세스 메커니즘에 의해 나타나며, 모든 [5][4]URI에 해당하지는 않습니다.따라서http://www.example.com는 URL,www.example.com그렇지 않습니다.[6]
  2. ^ 새로운 URI 스킴의 등록 순서는 1999년에 RFC 2717에 의해 처음 정의되었으며,[14] 현재는 2015년 6월에 발표된 RFC 7595에 의해 정의되어 있습니다.
  3. ^ World Wide Web 상의 리소스와 관련된 URI의 경우 일부 웹 브라우저에서는.0폐기되는 닷 10진 표기의 일부 또는 사용되는 [16]원시 정수 IP 주소.
  4. ^ 이력 RFC 1866(RFC 2854에 의해 폐지)에서는 CGI 작성자는 '&' 외에 [18]';'도 지원하도록 권장하고 있습니다.

인용문

  1. ^ W3C(2009년).
  2. ^ "Forward and Backslashes in URLs". zzz.buzz. Retrieved 2018-09-19.
  3. ^ RFC 3986 (2005)
  4. ^ a b 공동 W3C/IETF URI 계획 이해 그룹(2002).
  5. ^ RFC 2396(1998).
  6. ^ Miessler, Daniel. "The Difference Between URLs and URIs".
  7. ^ a b W3C(1994년)
  8. ^ IETF(1992)
  9. ^ a b Berners-Lee (2015).
  10. ^ BBC 뉴스 (2009).
  11. ^ Berners-Lee, Tim; Connolly, Daniel "Dan" (March 1993). Hypertext Markup Language (draft RFCxxx) (Technical report). p. 28.
  12. ^ 버너스 리, 팀;Masinter, 래리, McCahill, 마크 페리(1994년 10월).균일한 자원 Locators(URL)(기술 보고서).(이 Internet-Draft 행태 변화 표준 RFC, RFC1738년(1994년으로 출판되었다.))중앙, C.S.;마틴, D.C.(1995년 1월)에 영향.불쾌해 컴포넌트 Interface++(기술 보고서).UCSF도서관 및 센터 지식 경영을 위한.
  13. ^ RFC 3986, 섹션 3 (2005)
  14. ^ IETF (2015)
  15. ^ RFC 3986 (2005), § 3.2.2.
  16. ^ 로렌스(2014).
  17. ^ RFC 2396(1998), § 3.3.
  18. ^ RFC 1866(1995), § 8.2.1.
  19. ^ a b W3C(2008년).
  20. ^ W3C(2014년)
  21. ^ IANA(2003)
  22. ^ Glaser, J. D. (2013). Secure Development for Mobile Apps: How to Design and Code Secure Mobile Applications with PHP and JavaScript. CRC Press. p. 193. ISBN 978-1-48220903-7. Retrieved 2015-10-12.
  23. ^ Schafer, Steven M. (2011). HTML, XHTML, and CSS Bible. John Wiley & Sons. p. 124. ISBN 978-1-11808130-3. Retrieved 2015-10-12.

레퍼런스

외부 링크