개발자 도구 · URL 인코더 및 디코더
RFC 3986 예약 및 예약되지 않은 문자: URI 표준의 내용
· 배경
URL 인코딩 rfc3986 퍼센트 인코딩
RFC 3986는 문자를 예약된 문자, 예약되지 않은 문자 및 기타 모든 문자로 나누고, 해당 분할은 충족된 모든 백분율 인코딩 규칙을 설명합니다. 이 게시물은 관련 섹션을 명확하게 읽습니다.
RFC 3986 예약 및 예약되지 않은 문자 - URL을 작성할 때 중요한 사항
RFC 3986는 문자를 예약되지 않은 항목, 예약된 항목, 인코딩해야 하는 기타 모든 항목의 세 가지 범주로 나눕니다. 예약되지 않은 문자는 인코딩이 필요하지 않습니다. 문자, 숫자, 하이픈, 마침표, 밑줄 및 물결표가 여기에 해당합니다. RFC는 2.3 섹션에 이를 명시적으로 나열하여 모든 URI 컨텍스트에서 인코딩되지 않은 상태로 두어도 안전하다고 명시합니다. 이러한 문자를 사용하여 URL 인코더 및 디코더에서 테스트하면 변경되지 않은 채 통과되는 것으로 나타났습니다. 예약된 문자는 gen 구분 기호(: / ? # [ ] @)와 하위 구분 기호(! $ & ' ( ) * + , ; =)로 세분화되며, 각각은 서로 다른 URL 구성 요소에서 구조적 의미를 갖습니다.
문자는 언제 인코딩이 필요합니까? 예약된 문자는 모호한 경우에만 백분율로 인코딩되어야 합니다. 슬래시는 경로 세그먼트를 표시합니다. 쿼리 값에서는 %2F여야 합니다. 앰퍼샌드는 매개변수를 구분합니다. & 값에는 %26이(가) 필요합니다. 예약되지 않은 문자는 인코딩이 필요하지 않습니다. 하이픈은 하이픈으로 유지됩니다. URL 표준은 올바른 구문 분석을 보장합니다. URL 인코더 및 디코더로 테스트: encodeURIComponent와 함께 "hello/world"을 입력하면 "hello%2Fworld"가 생성되고, encodeURI를 사용하면 슬래시가 유지됩니다.
예약되지 않음: 문자, 숫자, 하이픈, 마침표, 밑줄 및 물결표 — 인코딩이 필요하지 않으며 인코딩되어서는 안 되는 문자
백분율 인코딩은 %HH를 사용합니다. 여기서 HH는 16진수 표기법입니다. ASCII 문자 A(코드 65)는 %41이 됩니다. 비ASCII é에는 UTF-8 인코딩이 필요합니다. é (U+00E9)는 %C3%A9가 됩니다. 최신 표준은 브라우저 전반에 걸쳐 UTF-8을 균일하게 지정합니다.
완전한 URL에는 구조적 구문이 그대로 필요합니다. 쿼리 값에는 무해한 내부 예약 문자가 필요합니다. 쿼리 매개변수 ?q=R&D는 수동인 경우 &를 %26로 인코딩해야 하며, 그렇지 않으면 앰퍼샌드가 구분 기호가 됩니다. 슬래시가 있는 값은 구성 요소 모드에서 %2F가 됩니다. 구성 요소 인코딩(encodeURIComponent)은 예약되지 않은 문자, 숫자 및 - _ 를 제외한 모든 것을 인코딩하여 이를 처리합니다. ! ~ * '( ). 테스트는 방법 간의 차이를 명확하게 보여줍니다.
예약됨: gen-delims 및 sub-delims — 두 그룹, 해당 구성원 및 구조적 역할
쿼리 문자열은 예약 문자가 중요한 이유를 보여줍니다. 앰퍼샌드는 키=값 쌍을 구분합니다. ?utm_source=email&utm_campaign=sale은 두 개의 매개변수를 의미합니다. 값 내에서 이스케이프되지 않은 앰퍼샌드는 쌍을 끝냅니다. 같음은 키와 값을 구분합니다. 구문 분석은 여러 계층에서 발생합니다. 각각은 동일한 규칙을 적용합니다.
쿼리 값에 인코딩이 필요한 문자에는 앰퍼샌드, 등호, 해시, 물음표, 공백 및 ASCII가 아닌 문자가 포함됩니다. 해시는 가장 은밀합니다. #anything은 조각 식별자가 되며 서버로 전송되지 않습니다. 해시로 끝나는 캠페인 이름은 요청이 브라우저를 떠나기 전에 그 뒤의 모든 내용을 잃습니다. 공백은 %20이어야 합니다. URL 인코더 및 디코더로 테스트하면 구성 요소 및 양식 모드가 표시됩니다. 위치를 이해하면 인코딩 필요성이 결정됩니다.
예약 문자를 인코딩해야 하는 경우 — 구분 기호로 오해될 수 있는 경우에만 구성 요소별로
백분율 인코딩은 RFC 3986에서 유지됩니다. 예약되지 않은 세트는 작은 크기로 유지되어 이식성을 보장합니다. 퍼센트 인코딩된 예약되지 않은 문자는 의미 변경 없이 디코딩될 수 있습니다. A가 예약되지 않았기 때문에 %41을 A로 디코딩하는 것이 정확합니다. %2F를 /로 디코딩하면 슬래시가 구분 기호가 아닌 데이터인 경우 의미가 변경됩니다. RFC 3986 정규화 섹션 6에서는 구문 접근 방식을 다룹니다.
다른 위치에 있는 예약된 문자는 다른 역할을 갖습니다. 체계 표시 체계의 콜론:권한 경계; userinfo의 콜론은 데이터입니다. 물음표는 쿼리 섹션을 엽니다. 쿼리 값의 슬래시는 리터럴입니다. 해시는 조각 시작을 표시합니다. 위치는 인코딩 필요성을 결정합니다. 쿼리 문자열은 그 자체가 URI인 값을 전달합니다. https://example.com/page?param=value과 같은 리디렉션 URL을 매개변수로 인코딩하려면 슬래시와 콜론을 %2F 및 %3A로 인코딩해야 합니다. 컨텍스트는 항상 안전한 문자를 정의합니다.
작업 예: 실제 URL의 모든 문자 분류 — 예약되지 않음, 구분 기호로 예약됨, 데이터로 예약됨
RFC 1738(1994)에서는 많은 문자가 안전하지 않은 것으로 간주했습니다. 배포가 UTF-8로 표준화됨에 따라 이후 표준에서는 제한 사항이 완화되었습니다. 물결표(~)는 진화를 예시합니다. RFC 1738에는 %7E가 필요하고, RFC 2396(1998)는 물결표를 예약되지 않음으로 이동했으며, RFC 3986는 예약되지 않은 상태를 확인했습니다. 진화에는 배포 교훈이 반영됩니다. 표준은 이전 버전과의 호환성을 유지합니다.
RFC 정규화를 통해 불필요하게 퍼센트 인코딩된 예약되지 않은 문자를 디코딩할 수 있습니다. %41는 A로 안전하게 정규화됩니다. %2F와 같은 인코딩된 예약 문자는 절대 디코딩되지 않습니다. 의미를 바꾸면 구조가 깨집니다. 현대 합의는 RFC 3986을 참조 기준으로 사용합니다. URL 인코더 및 디코더는 전체적으로 RFC 3986를 따르며 브라우저 동작과 별도로 고정 참조를 제공합니다. WHATWG URL 표준은 RFC 외에 구성 요소별 인코딩 세트를 추가합니다. 표준이 공존합니다: 일반 URL 구문 분석을 위한 RFC 3986, 웹 브라우저를 위한 WHATWG. 라이브러리는 다릅니다. 문서를 확인하세요.
섹션 6의 정규화 지침 — 16진수 대소문자, 예약되지 않은 디코딩 및 경로 세그먼트 규칙
RFC에 대한 테스트 3986는 URL이 수십 년에 걸쳐 소프트웨어 전반에서 작동하도록 보장합니다. URL 인코더 및 디코더는 구성된 구성 요소에 적용할 RFC 3986 인코딩 기준을 제공합니다. URL 라이브러리의 모든 인코딩 결정을 설명하는 표준 문서를 읽어보세요. WHATWG URL은 RFC 3986를 완전히 교체하는 대신 이를 기반으로 구축됩니다. 일반 브라우저용 URL을 작성하시나요? RFC 3986을 따르세요. 브라우저는 WHATWG 규칙을 맨 위에 적용합니다. 오래된 시스템인가요? 실제 구현을 테스트합니다. 저장을 위해 정규화하시겠습니까? RFC 3986를 일관되게 적용합니다. Reserved/unreserved 구별을 이해하면 안전한 문자를 알 수 있습니다.
URL 인코딩은 보안 삭제가 아닙니다. SQL, HTML, JavaScript, URI 등 각 컨텍스트에는 자체 출력 인코딩이 필요합니다. 퍼센트 인코딩은 URL 구조만 보호합니다. 올바른 레이어에 올바른 방어를 적용하세요.
여기서 다루지 않는 내용 — WHATWG URL 표준의 다양한 인코딩 세트 및 IRI 처리
RFC 2396 (1998)은 RFC 1738보다 문자 집합을 더 엄격하게 명시했습니다. URI 구조를 제공하고 예약되지 않은 문자를 리터럴 데이터로 공식화했습니다. 원래 정의 위에 하이픈, 마침표, 밑줄, 물결표를 포함하여 예약되지 않은 확장이 가능합니다. RFC 2396에서는 일반 구분 기호(:, /, ?, #, [, ], @)와 하위 구분 기호(!, $, &, ', (, ), *, +, ,, ;, =) 간의 구분을 도입했습니다. 각 그룹은 URL에서 서로 다른 구조적 역할을 갖습니다. 이름을 지정하면 예약된 문자를 두 그룹으로 구분할 수 있습니다. 이름을 아는 것은 기술적인 논의에 도움이 됩니다.
RFC 3986(2005)은 최신 참조입니다. 예약된/unreserved 구별을 유지했지만 표기법을 단순화했습니다. 표준 기관은 소급하여 웹을 중단하지 않습니다. 표준을 의도적으로 알고 인코딩하십시오. URL 인코더 및 디코더는 RFC 3986 참조를 제공합니다.
요점: 표준은 짧고 정확합니다. URL 인코더 및 디코더의 두 가지 모드가 데이터 인코딩과 구분 기호 보존에 어떻게 대응하는지
표준 선택은 상황에 따라 다릅니다. 일반 브라우저용 URL을 작성하시나요? RFC 3986를 따르세요. 브라우저는 WHATWG 규칙을 적용합니다. 오래된 시스템인가요? 실제 구현을 테스트합니다. 저장을 위해 정규화하시겠습니까? RFC 3986을 일관되게 적용합니다. 백분율 인코딩 규칙은 보수적인 RFC 1738에서 명확한 RFC 2396 및 RFC 3986를 통해 계층화된 WHATWG URL 표준으로 발전했습니다. 각 세대는 경험을 반영했습니다. 최신 빌더는 상황에 따라 RFC 3986 또는 WHATWG를 따릅니다. 호환성에 대한 생각이 필요한 이전 URL과 새 URL이 공존합니다. 카테고리를 이해하면 인코딩 실수를 방지할 수 있습니다.
배포하기 전에 URL이 올바르게 인코딩되었는지 확인하세요. URL 인코더 및 디코더는 RFC 3986 규칙을 엔드 투 엔드로 보여줍니다. 정확한 16진수 값을 확인하고 어떤 문자가 인코딩되는지 이해하세요. 조각을 연결하여 URL을 작성할 때 이 도구를 사용하십시오. 일관된 URI 구문 분석을 위한 RFC 3986 예약 및 예약되지 않은 카테고리 파티션 문자 집합입니다.