개발자 도구 · URL 인코더 및 디코더
URL 분석: 체계, 권한, 경로, 쿼리 및 단편 설명
· 배경
URL 구조 웹 표준 개발자 도구
모든 퍼센트 인코딩 결정은 문자가 있는 URL 부분에 따라 다릅니다. 이 게시물은 RFC 3986의 다섯 가지 구성 요소 이름을 지정하고 각 구분 기호의 의미와 조각이 서버에 도달하지 않는 이유를 보여줍니다.
동일한 #이 한 곳에서는 괜찮고 다른 곳에서는 링크를 파괴하는 이유 — 문자 질문이 아닌 구성 요소 질문
URL의 해시 문자(#)는 나타나는 위치에 따라 완전히 다른 의미를 갖습니다. ?search=C%23sharp와 같은 쿼리 문자열 값 내에서는 안전을 위해 %23로 인코딩되어야 합니다. https://example.com/page#section,과 같은 URL의 끝에는 조각 구분 기호와 그 뒤의 모든 항목이 조각임을 표시합니다. 하나의 문자, 두 가지 맥락, 두 가지 다른 의미. 이것이 인코딩 결정이 작업 중인 URL의 어느 부분을 아는지에 달려 있는 이유입니다.
물음표(?)에도 이중성이 있습니다. 경로 또는 쿼리 값 내에서 데이터로 표시하려면 %3F로 인코딩되어야 합니다. 경로와 쿼리 문자열 사이의 리터럴 문자로서 구조적 구문입니다. 스키마, 권한, 경로, 쿼리 및 조각이라는 다섯 가지 구성 요소를 이해하는 것이 올바른 URL 처리의 기초입니다.
5가지 구성 요소: 체계, 권한, 경로, 쿼리, 조각 — 및 이들을 구분하는 구분 기호
RFC 3986는 URL을 특정 구분 기호로 구분된 체계, 권한, 경로, 쿼리 및 조각의 5가지 구성 요소로 공식적으로 정의합니다. 체계가 먼저 오고, 그 다음에는 ://,, 권한, /,, 경로, ?, 쿼리, #, 조각 순입니다. 모든 구성 요소가 모든 URL에 표시되는 것은 아닙니다. 최소 URL에는 "mailto:user@example.com"과 같은 구성표와 경로만 있을 수 있습니다. 전체 URL에는 5개가 모두 포함됩니다.
각 구성 요소에는 고유한 구문 규칙이 있습니다. 구성표에는 콜론, 경로에는 슬래시, 쿼리에는 앰퍼샌드가 예약되어 있습니다. 예약된 문자는 데이터로 표시될 때 인코딩이 필요합니다. 경로 값의 슬래시는 %2F가 됩니다.
권한 내부 — 사용자 정보, 호스트 및 포트, @ 및 :가 예약된 이유
권한 구성 요소에는 사용자 이름, 비밀번호, 호스트 이름 및 포트와 같은 리소스의 네트워크 주소가 포함됩니다. 형식은 [userinfo@]호스트[:포트]입니다. 사용자 정보와 호스트는 @로 구분됩니다. 호스트와 포트는 :으로 구분됩니다. 이러한 @ 및 : 문자는 이러한 하위 구성 요소를 구분하는 권한 내에서 예약되어 있습니다. @ 기호가 포함된 사용자 이름이 있는 경우 연결하기 전에 백분율로 인코딩되어야 합니다. 예를 들어, 사용자 이름으로 "user@email.com:password"는 마지막 @ 앞에 "user%40email.com:password"가 됩니다.
호스트 이름은 example.com과 같이 등록된 도메인, 192.0.2.1과 같이 점으로 구분된 십진수로 된 IP 주소 또는 [::1]과 같이 대괄호로 묶인 IPv6 주소일 수 있습니다. 포트는 선택 사항입니다. 생략하면 구성표가 기본값을 결정합니다(http의 경우 80, https의 경우 443 등). userinfo 부분은 최신 URL에서는 거의 사용되지 않지만 구문의 일부로 남아 있습니다.
경로 세그먼트 및 /의 의미 — 계층 구조 및 도트 세그먼트 해상도
경로는 슬래시로 구분된 일련의 세그먼트입니다. /a/b/c 경로에는 a, b, c 세 개의 세그먼트가 있습니다. 각 세그먼트에는 예약되지 않은 문자, 백분율로 인코딩된 문자 또는 이 컨텍스트에서 안전한 특정 예약 문자가 포함될 수 있습니다. 세그먼트 구분 기호와의 혼동을 피하기 위해 세그먼트 내의 슬래시는 %2F로 인코딩되어야 합니다. 경로는 계층적입니다. 이는 a가 위치임을 의미하고 a/b이 더 구체적입니다.
경로는 특수 점 세그먼트도 지원합니다. 단일 점(.)은 "현재 디렉터리"를 의미하고 두 점(..)은 "상위 디렉터리"를 의미합니다. ../../etc/passwd와 같은 경로는 위쪽으로 확인됩니다. 최신 URL과 HTTP는 이를 사용하지 않지만 구문에는 존재합니다. 리터럴 점 또는 이중 점을 포함하는 경로 세그먼트는 리터럴 점 의미를 의도하지 않은 경우 백분율로 인코딩되어야 합니다.
쿼리 및 프래그먼트 — 키-값 규칙 및 프래그먼트가 브라우저에 유지되는 이유
쿼리 문자열은 경로를 따르며 ?로 시작합니다. 구문은 실제로 구조화되어 있지 않지만 전통적으로 &로 구분된 일련의 키=값 쌍입니다. 쿼리에는 무엇이든 들어갈 수 있습니다. & 또는 =를 포함하는 값이 있는 경우 해당 문자는 구분 기호로 오인되지 않도록 백분율로 인코딩되어야 합니다. 쿼리가 서버로 전송됩니다. 서버가 이를 어떻게 할지 결정합니다.
조각은 쿼리를 따르고 #으로 시작합니다. # 이후의 모든 내용은 조각이며 서버에 도달하지 않습니다. 브라우저는 일반적으로 명명된 앵커로 이동하거나 단일 페이지 애플리케이션 내의 상태를 나타내기 위해 조각을 로컬로 처리합니다. 조각은 서버에 도달하지 않기 때문에 다른 조각이 있는 URL은 동일한 리소스를 가리키는 것으로 간주됩니다.
실제 예: 긴 실제 URL 분석 — 모든 구성 요소와 모든 구분 기호에 레이블 지정
URL "https://user:pass@example.com:8080/path/to/page?search=hello&sort=date#results".을 가져옵니다. 구성표는 https입니다. 권한은 user:pass@example.com:8080이며 userinfo(user:pass), 호스트(example.com) 및 포트(8080)로 나뉩니다. 경로는 세그먼트 path, to 및 page가 있는 /path/to/page,입니다. 쿼리는 search=hello&sort=date이며 두 개의 매개 변수를 포함합니다. 조각 결과입니다. 이 URL을 URL 인코더 및 디코더에 입력하여 도구가 각 구성 요소에 레이블을 지정하고 인코딩하는 방법을 확인하세요.
검색에 &가 포함된 경우(예: ?search=R&D) 올바르게 인코딩되면 ?search=R%26D가 됩니다. 퍼센트 인코딩 문자는 텍스트에 시각적 경계를 만들지 않으므로 올바른 구문 분석을 위해서는 신중한 인코딩 및 디코딩이 절대적으로 필요합니다.
여기서 다루지 않는 내용 — 상대 참조 확인 및 mailto: 및 data:와 같은 특수 체계
"../page" 또는 "?query=value"와 같은 상대 참조는 HTML 내에서 유효하며 현재 문서를 기준으로 해석되지만 별도의 해결 규칙이 있습니다. mailto:, data: 및 file:과 같은 특수 구성표는 완전히 다른 규칙을 따르며 표준 절대 URL이 아닙니다.
이 게시물은 검사관이 시연한 표준 절대 URL 구조에만 중점을 둡니다. 상대 참조는 해당 구성 요소를 해석하기 전에 기본 URL이 필요하지만 mailto 및 데이터와 같은 체계는 동일한 권한 및 경로 형태를 공유하지 않습니다. 이러한 사례를 별도로 유지하면 HTTPS 주소에서 학습된 규칙이 다른 구분 기호, 해결 단계 또는 전송 동작을 사용하는 구문에 맹목적으로 적용되는 것을 방지할 수 있습니다.
요약: 인코딩하기 전에 구성 요소를 파악하십시오. URL 인코더 및 디코더의 단일 값 및 전체 주소 모드가 이 구조에 매핑되는 방식
인코딩하는 구성 요소에 따라 이스케이프가 필요한 문자와 안전한 문자가 결정됩니다. 슬래시는 경로의 리터럴 구문이므로 값의 슬래시는 %2F여야 합니다. 쿼리에서 & 및 =가 값에 나타나는 경우 인코딩해야 합니다. URL 인코더 및 디코더에는 단일 값을 인코딩하기 위한 "구성 요소" 모드와 전체 URL을 위한 "전체 주소"라는 두 가지 모드가 있습니다. 부분을 연결하여 URL을 작성할 때 구성요소 모드를 사용하십시오. 전체 주소 모드를 사용하여 기존 URL을 확인하세요.
다섯 가지 구성 요소와 해당 구분 기호를 알면 인코딩 작업이 발생할 때마다 올바르게 선택할 수 있습니다.