개발자 도구 · URL 인코더 및 디코더
RFC 1738에서 URL 표준까지: 백분율 인코딩 규칙이 어떻게 발전했는지
· 배경
URL 인코딩 rfc-역사 웹 표준
URL의 이스케이프 문자 규칙은 1994 이후 여러 번 다시 작성되었습니다. 이 게시물은 RFC 1738, RFC 2396, RFC 3986 및 WHATWG URL 표준을 따르며 매번 변경된 내용을 설명합니다.
RFC 1738에서 URL 표준까지 - 백분율 인코딩 규칙이 어떻게 발전했는지
물결표(~)는 표준 생성 및 배포 전반에 걸쳐 인코딩 규칙이 어떻게 변경되는지를 보여줍니다. RFC 1738(1994)에는 모든 곳에서 %7E가 필요합니다. RFC 2396(1998)는 물결표를 예약되지 않은 상태로 이동하여 인코딩되지 않은 상태를 허용합니다. RFC 3986(2005)에서 예약되지 않은 상태를 확인했습니다. %7E가 포함된 이전 URL은 계속 유효합니다. 새로운 빌더 출력 ~. 진화는 웹이 성숙해지고 인프라가 표준화됨에 따라 배포 교훈을 반영합니다. RFC 1738는 초기 인프라가 이기종이고 다양했기 때문에 보수적이었습니다.
RFC 1738 성문화된 1994 브라우저 동작. UTF-8에 표준화된 배포; 제한은 불필요한 것으로 판명되었습니다. 이후 표준에서는 문자 제한을 완화했습니다. RFC 3986는 예약되지 않은 문자의 안전한 디코딩을 허용합니다.
RFC 1738 (1994): '안전하지 않은' 문자 및 첫 번째 이스케이프 규칙 — 위험하다고 간주된 항목과 그 이유
RFC 1738는 역사적으로 프로토콜(제어 문자)에서 사용되었던 URI 구문(공백, 슬래시)과 충돌하거나 시스템이 안전하게 전송할 수 없는 문자로 "안전하지 않은" 문자를 정의했습니다. 보수적인 목록은 현대 인터넷에 필요한 것보다 훨씬 더 많이 퍼센트 인코딩됩니다. 많은 초기 시스템이 RFC보다 앞서 있었습니다. 그것은 그들의 행동을 성문화했습니다. 제어 문자는 프로토콜에서 정말 위험했습니다. 공백은 명령줄에서 읽는 HTTP 클라이언트의 전송 문제였습니다. 최신 시스템은 명시적 인코딩을 통해 이러한 경우를 더욱 우아하게 처리합니다.
RFC에 대한 테스트 1738는 기존 시스템이 예상했던 바를 보여줍니다. 1990년대 URL 사양의 문자를 인코딩하고 최신 RFC 3986과 비교합니다. 차이점은 무엇이 완화되었는지를 보여줍니다. 예약되지 않은 세트는 시간이 지남에 따라 확장되었습니다. 하이픈, 마침표, 밑줄은 항상 안전합니다. Tilde가 안전해지려면 RFC 2396가 필요했습니다. 보수적인 접근 방식은 이전 버전과의 호환성을 의미했습니다. RFC 1738 규칙에 따라 작성된 이전 URL은 현재도 유효합니다. RFC 3986 섹션 6의 정규화를 통해 불필요하게 백분율로 인코딩된 예약되지 않은 문자를 안전하게 디코딩할 수 있습니다.
RFC 2396 (1998) — 예약된 것과 예약되지 않은 것, 일반 구문 및 물결표가 복원되었습니다.
RFC 2396 (1998)은 RFC 1738보다 문자 집합을 더 엄격하게 명시했습니다. 이는 URI 구조를 제공하는 예약된 문자와 예약되지 않은 문자를 리터럴 데이터로 공식화했습니다. 하이픈, 마침표, 밑줄, 물결표를 포함하여 예약되지 않은 확장이 가능합니다. 이는 체계별 규칙과 별도로 일반 URI 구문을 인정했습니다. RFC 2396에서는 일반 구분 기호(:, /, ?, #, [, ], @)와 하위 구분 기호(!, $, &, ', (, ), *, +, ,, ;, =) 간의 구분을 도입했습니다. 이름을 지정하면 예약된 문자가 서로 다른 구조적 역할을 가진 두 그룹으로 구분됨이 명확해집니다.
RFC 2396에는 의미 변경 없이 디코딩할 수 있는 백분율 인코딩 문자를 지정하는 정규화 지침이 도입되었습니다. 예약되지 않은 문자 디코딩이 정규화됩니다. 예약된 문자 인코딩 스틱. RFC 3986 표기법을 더욱 단순화했습니다. 표준은 이전 버전과의 호환성을 강력하게 유지합니다.
RFC 3986 (2005) — ! * '( ) 하위 구분으로 이동, gen 구분에 이름이 지정되고 정규화 안내가 도착합니다.
RFC 3986(2005)은 백분율 인코딩에 대한 최신 참조 표준입니다. 예약된/unreserved 구별을 유지했지만 표기법을 단순화하고 정규화 지침을 추가했습니다. Tilde는 명확하게 예약되지 않은 상태로 움직였습니다. 표준 명확화 퍼센트 인코딩 예약되지 않은 문자는 의미 변경 없이 디코딩될 수 있습니다. RFC 3986 섹션 3에서는 URI 구문을 정확하게 설명합니다. 섹션 2에서는 문자 범주를 정의합니다. 6 섹션은 구문 정규화에 대한 공식 규칙을 전담합니다. 비교 기반 정규화는 정규화된 형식이 일치하는 경우 URI가 동일한 것으로 간주합니다. 경로에서 점 세그먼트 제거는 의미 변경 없이 정규화됩니다.
정규화는 분석, 캐싱, 링크 추적에 중요합니다. 16진수 대소문자만 다른 URL(RFC 3986에서는 대문자 선호)은 실제로 동일해야 합니다. 정규화하면 중복된 로그 항목과 캐시 누락을 방지할 수 있습니다. 정규화된 URL에 입력된 캐시는 요청자의 인코딩 기본 설정에 관계없이 콘텐츠를 제공합니다. RFC 3986 정규화 지침을 통해 시스템은 일관된 결정을 내릴 수 있습니다. 그러나 엄격한 시행으로 인해 현재 인터넷에서 제대로 작동하는 URL이 중단됩니다.
WHATWG URL 표준: 브라우저가 실제로 수신하는 내용 분석 — 인코딩 세트, 특수 구성표 및 오류 허용
WHATWG URL 표준(2016–현재)은 URL이 RFC 3986을 완벽하게 따르지 않는 브라우저 경험에서 나타났습니다. 브라우저는 인코딩되지 않은 공간, 혼합 인코딩, 특이한 문제에 직면했습니다. WHATWG는 이론적인 문법이 아닌 실제 브라우저 구문 분석을 설명합니다. 실제 브라우저에서는 공백 허용, 이스케이프 문자 처리, 잘못된 입력 복구를 위한 실용적인 규칙을 개발했습니다. RFC 3986는 2005에 도착하여 형식적인 문법을 정의했지만 실제 브라우저는 이미 약간씩 갈라져 있었습니다.
WHATWG는 상황별 규칙을 사용하여 9개의 인코딩 세트를 정의합니다. 경로의 공백은 %20이 됩니다. userinfo의 슬래시는 %2F가 됩니다. 브라우저는 웹에 대해 더 좁은 표준을 적용합니다. RFC 3986은 기준선을 제공합니다. WHATWG는 이를 기반으로 합니다.
작업 예: 물결표, 공백 및 비ASCII 문자가 포함된 URL 1개 — 각 규칙 세대가 URL을 인코딩하는 방법
국제화 도메인은 퓨니코드 인코딩을 사용합니다(뮌헨은 xn--mnchen-3ya가 됨). 경로와 쿼리는 여전히 퍼센트 인코딩을 사용합니다. 도메인 부분은 퓨니코드를 사용합니다. 경로 및 쿼리 부분은 백분율 인코딩을 사용합니다. 레이어는 섞이거나 간섭하지 않습니다.
IDNA(Internationalized Domain Names in Application)는 호스트 이름 문제를 해결합니다. Punycode는 DNS 호환성을 위해 비ASCII를 ASCII로 인코딩합니다. xn-- 접두사는 퓨니코드 인코딩을 나타냅니다. 알고리즘은 결정적입니다. münchen은 항상 xn--mnchen-3ya가 됩니다. 비ASCII 문자는 DNS 확인 전에 변환해야 합니다. DNS 제약 조건 및 레이블 제한으로 인해 호스트 이름에 대한 백분율 인코딩이 작동하지 않습니다. 각 접근 방식은 서로 다른 문제를 올바르게 해결합니다. 표준은 정당한 이유로 별도로 발전했습니다.
여기서 다루지 않는 내용 — 자체 기록이 있는 IRI 및 국제화 도메인 이름
표준 선택은 상황에 따라 다릅니다. 브라우저용 URL을 구축하시나요? RFC 3986를 따르세요. 브라우저는 WHATWG를 적용합니다. 오래된 시스템인가요? 테스트 구현. 진화를 이해하면 혼란이 방지됩니다.
최신 빌더는 상황에 따라 RFC 3986 또는 WHATWG를 따라야 합니다. 호환성에 대한 신중한 생각이 필요한 이전 URL과 새 URL이 공존합니다. URL 인코더 및 디코더는 전체적으로 RFC 3986을 따르며 브라우저 동작과 별도로 고정 참조를 제공합니다. WHATWG는 RFC 기본 사항 외에 구성 요소별 인코딩 세트를 추가합니다. 언제 변경된 사항을 알면 시스템이 일치하지 않는 이유를 이해하는 데 도움이 됩니다. 두 표준을 모두 사용하여 URL을 테스트하면 사용자 환경에서 어떤 표준이 제어되는지 알 수 있습니다. 두 표준 모두 정확합니다.
요약: 코드가 어떤 규칙을 따르는지 파악 — URL 인코더 및 디코더가 RFC 3986 동작을 고정 참조 지점으로 제공하는 방법
RFC 3986 정규화를 통해 불필요하게 백분율로 인코딩된 예약되지 않은 문자를 안전하게 디코딩할 수 있습니다. %41은 A로 정규화됩니다. %2F와 같은 인코딩된 예약 문자는 절대 디코딩되지 않습니다. 의미를 바꾸면 구조가 깨집니다. 표준 기관은 이전 버전과의 호환성을 강력하게 유지합니다. 문제를 해결하려면 수십 년 후에는 불가능할 전 세계적 조정이 필요합니다. 표준 서적은 소급하여 웹을 손상시키지 않습니다. 인코딩 결정을 변경하면 수십억 개의 기존 시스템이 동시에 중단됩니다.
백분율 인코딩은 RFC 1738에서 RFC 2396 및 RFC 3986에서 최신 WHATWG URL 표준에 이르기까지 30년에 걸쳐 신중하게 발전했습니다. 최신 코드는 RFC 3986 기준을 따라야 합니다. 이전에 인코딩된 이전 URL은 계속 유효합니다. 왕복 테스트를 통해 정확성과 호환성이 보장됩니다.