백분율 인코딩

Percent-encoding
MediaWiki의 URLen 코드는 도움말:마법의 말
백분율 인코딩이 필요한 위키백과의 링크는 도움말을 참조하십시오.URL § 지원되지 않는 문자로 링크 수정

URL 인코딩이라고도 하는 백분율 인코딩은 URI 내에서 합법적인 제한된 미국-ASCII 문자만 사용하여 URI(Uniform Resource Identifier)의 임의 데이터를 인코딩하는 방법이다.URL 인코딩으로 알려져 있지만, 일반적으로 Uniform Resource Locator(URL)와 Uniform Resource Name(URN)을 모두 포함하는 주 Uniform Resource Identifier(URI) 세트 내에서 더 일반적으로 사용된다.이와 같이 본국의 자료 작성에도 사용된다.application/x-www-form-urlencoded HTTP 요청에서 HTMLform 데이터의 제출에 자주 사용되는 미디어 유형.

URI에서 인코딩 비율

URI 문자 유형

URI에서 허용되는 문자는 예약되었거나 예약되지 않은 문자(또는 백분율 인코딩의 일부로 백분율 문자)이다.유보적인 캐릭터는 때때로 특별한 의미를 갖는 캐릭터들이다.예를 들어 슬래시 문자는 URL의 다른 부분(또는 더 일반적으로 URI)을 구분하는 데 사용된다.예약되지 않은 글자는 그런 뜻이 없다.백분율 인코딩을 사용하면 특수 문자 시퀀스를 사용하여 예약된 문자를 나타낸다.예약 및 예약되지 않은 문자 집합과 특정 예약 문자가 특별한 의미를 갖는 상황은 URI와 URI 체계를 지배하는 사양의 각 개정과 함께 약간 달라졌다.

RFC 3986 섹션 2.2 예약 문자(2005년 1월)
! # $ & ' ( ) * + , / : ; = ? @ [ ]
RFC 3986 섹션 2.3 예약되지 않은 문자(2005년 1월)
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~

URI의 다른 문자는 백분율로 인코딩되어야 한다.

예약 문자

예약된 집합의 문자("예약된 문자")가 특정 맥락에서 특별한 의미("예약된 목적")를 가지고 있고, URI 체계가 그 문자를 다른 목적으로 사용할 필요가 있다고 말할 때, 그 문자는 백분율로 인코딩되어야 한다.예약된 문자를 백분율 인코딩하려면 문자를 ASCII로 해당 바이트 값으로 변환한 다음 해당 값을 16진수 한 쌍으로 표시하는 것이 포함된다.백분율 부호가 앞에 있는 숫자(%)%이스케이프 문자로 사용되는 )는 예약된 문자 대신 URI에서 사용된다. (ASC가 아닌 경우)II 문자, 일반적으로 UTF-8에서 바이트 시퀀스로 변환된 후, 각 바이트 값을 위와 같이 표시한다.)

예약자/ 예를 들어, URI의 "경로" 구성 요소에 사용되는 경우 경로 세그먼트 사이의 구분 기호라는 특별한 의미가 있다.만약, 주어진 URI 계획에 따르면,/경로 세그먼트에 있어야 하고, 그 다음 세 개의 문자가 있어야 한다.%2F또는%2f원시 세그먼트 대신 세그먼트에 사용되어야 함/.

백분율 인코딩 후 예약된 문자
␣ ! # $ % & ' ( ) * + , / : ; = ? @ [ ]
%20 %21 %23 %24 %25 %26 %27 %28 %29 %2A %2B %2C %2F %3A %3B %3D %3F %40 %5B %5D

특정 컨텍스트에서 예약 목적이 없는 예약 문자도 백분율로 인코딩될 수 있지만, 그렇지 않은 문자와 의미론적으로 다르지 않다.

예를 들어 URI의 "query" 구성 요소(?문자 뒤의 부분)에서/여전히 유보적인 성격으로 여겨지지만 특별한 우리당의 계획이 달리 명시되지 않는 한, 그것은 보통 유보적인 목적을 가지고 있지 않다.캐릭터가 지정 목적이 없는 경우에는 백분율로 인코딩할 필요가 없다.

예약된 문자가 백분율 인코딩되었는지 또는 문자 그대로 표시되는지에 의해서만 차이가 나는 URI는 해당 예약된 문자가 예약된 목적이 없다고 판단할 수 없는 한 일반적으로 동등하지 않은 것으로 간주된다(동일한 리소스를 나타냄).이러한 결정은 개별 URI 체계에 의해 예약된 문자에 대해 설정된 규칙에 따라 결정된다.

예약되지 않은 문자

예약되지 않은 집합의 문자는 백분율로 인코딩할 필요가 없다.

예약되지 않은 문자가 백분율로 인코딩되거나 문자 그대로 표시되는지 여부에 의해서만 차이가 나는 URI는 정의상 동일하지만, 실제로 URI 프로세서는 이러한 동등성을 항상 인식하지는 못할 수 있다.예를 들어 URI 소비자는 취급하지 않아야 한다.%41와는 다르게A또는%7E와는 다르게~, 그러나 몇몇은 그렇다.상호운용성을 극대화하기 위해 URI 생산자들은 예약되지 않은 문자를 백분율로 인코딩하는 것을 금지한다.

백분율 문자

왜냐하면 백분율 문자(%)은 백분율-백분율 옥텟의 지표 역할을 하며, 다음과 같이 백분율-백분율이어야 한다.%25이 8진법을 URI 내에서 데이터로 사용할 수 있도록 한다.

임의 데이터

대부분의 URI 체계는 IP 주소나 파일 시스템 경로와 같은 임의 데이터를 URI의 구성 요소로 표현한다. URI 체계의 사양은 URI 문자와 이러한 문자로 표현되는 모든 가능한 데이터 값 사이의 명시적 매핑을 제공해야 하지만 종종 제공하지 않는다.

이항 데이터

1994년 RFC 1738이 간행된 이후, URI에서 이진 데이터의 표현을 제공하는 체계는 데이터를 위와 같은 방식으로 8비트 바이트로 나누고 각 바이트를 백분율로 인코딩해야 한다고 지정되었다.[1]예를 들어 바이트 값 0x0F는 다음과 같이 표시되어야 한다.%0F, 그러나 바이트 값 0x41은 다음과 같이 나타낼 수 있다.A또는%41. 영숫자 및 기타 예약되지 않은 문자에 대한 인코딩되지 않은 문자의 사용은 URL이 짧아지기 때문에 일반적으로 선호된다.

문자 데이터

이항 데이터의 백분율 인코딩 절차는 문자 기반 데이터에 적용하기 위해 때때로 부적절하거나 완전히 지정되지 않은 채 추론되었다.월드 와이드 웹의 형성기에 있어서, ASCII 레퍼토리의 데이터 문자를 취급하고, 백분율 인코딩 시퀀스를 결정하는 기준으로 ASCII의 해당 바이트를 사용할 때, 이 연습은 상대적으로 해롭지 않았다. 단지 문자와 바이트가 일대일 매핑을 하고 상호 교환이 가능하다고 가정했을 뿐이다.그러나 ASCII 범위를 벗어난 문자를 나타낼 필요성은 빠르게 증가했고 URI 체계와 프로토콜은 종종 URI에 포함시키기 위한 문자 데이터를 준비하기 위한 표준 규칙을 제공하지 못했다.웹 애플리케이션은 결과적으로 서로 다른 멀티바이트, 상태 저장 및 기타 ASCII 호환이 되지 않는 인코딩을 백분율 인코딩의 기준으로 사용하기 시작했으며, 모호성과 URI를 신뢰성 있게 해석하는 데 어려움이 있었다.

예를 들어, RFCs 1738 및 2396에 기반한 많은 URI 구성과 프로토콜은 데이터 문자가 예약되지 않은 문자 또는 백분율 인코딩 바이트에 의해 URI로 표현되기 전에 일부 지정되지 않은 문자 인코딩에 따라 바이트로 변환될 것으로 가정한다.이 방법으로 URI가 사용된 인코딩에 대한 힌트를 제공하지 못하거나 인코딩이 ASCII 사용과 충돌하여 예약된 문자 및 예약되지 않은 문자를 사용할 경우 URI를 신뢰성 있게 해석할 수 없다.일부 체계는 인코딩을 전혀 고려하지 않고 대신 데이터 문자가 URI 문자에 직접 매핑되도록 제안하므로, 예약된 데이터 문자나 예약되지 않은 집합에 있는 데이터 문자의 인코딩 여부와 방법을 결정하는 것은 구현에 달려 있다.

백분율 인코딩 후 일반 문자(ASCII 또는 UTF-8 기반)
newline space " % - . < > \ ^ _ ` { } ~ £ 円
%0A 또는 %0D 또는 %0D%0A %20 %22 %25 %2D %2E %3C %3E %5C %5E %5F %60 %7B %7C %7D %7E %C2%A3 %E5%86%86

임의 문자 데이터는 비밀번호 난독화 프로그램 또는 기타 시스템별 변환 프로토콜과 같이 URI가 아닌 상황에서 백분율로 인코딩되어 사용되는 경우가 있다.

현재표준

주요 기사:국제화된 리소스 식별자

일반 URI 구문에서는 URI에서 문자 데이터를 표시하는 새로운 URI 체계는 사실상 번역 없이 예약되지 않은 집합의 문자를 나타내야 하며, 다른 모든 문자를 UTF-8에 따라 바이트로 변환한 다음 그 값을 백분율로 인코딩해야 한다고 권고하고 있다.이 제안은 RFC 3986의 발행과 함께 2005년 1월에 도입되었다.이 날짜 이전에 도입된 우리당 계획은 영향을 받지 않는다.

현재 명세서에서 다루지 않는 것은 인코딩된 문자 데이터로 무엇을 할 것인가이다.예를 들어, 컴퓨터에서는 문자 데이터가 어느 정도 인코딩된 형태로 표시되므로 URI 문자로 매핑될 때 이진 또는 문자 데이터로 처리할 수 있다.아마도 이러한 가능성을 고려하는 것은 우리당의 계획 명세서에 달려 있고 하나 또는 다른 하나를 필요로 하지만 실제로는 거의 그렇지 않다.

비표준 구현

유니코드 문자에 대한 비표준 인코딩이 있음:%uxxxx여기서 xxxxx는 4개의 16진수로 표시되는 UTF-16 코드 단위입니다.이 동작은 RFC에 의해 지정되지 않았으며 W3C에 의해 거부되었다.ECMA-262 제8판에는 여전히 다음과 같은 내용이 포함되어 있다.escape이 구문을 사용하는 함수encodeURI그리고encodeURIComponent함수로, UTF-8 인코딩을 문자열에 적용한 다음, 결과 바이트를 백분율로 이스케이프한다.[2]

응용 프로그램/x-www-form-urlencoded 유형

HTML 양식에 입력된 데이터를 제출하면 양식 필드 이름과 값이 인코딩되어 GET 또는 POST 메서드 또는 역사적으로 이메일을 통해 HTTP 요청 메시지로 서버로 전송된다.[3]기본적으로 사용되는 인코딩은 일반 URI 백분율 인코딩 규칙의 초기 버전을 기반으로 하며,[4] 뉴라인 정규화 및 공백 교체와 같은 여러 가지 수정 사항이 있다.+대신에%20. 이렇게 인코딩된 데이터의 미디어 유형은application/x-www-form-urlencoded현재 HTML 및 XForms 사양에 정의되어 있다.또한, CGI 규격에는 웹 서버가 이러한 유형의 데이터를 디코딩하고 애플리케이션에 사용할 수 있도록 하는 방법에 대한 규칙이 포함되어 있다.

HTML 양식 데이터가 HTTP GET 요청으로 전송되면 위에서 설명한 것과 동일한 구문을 사용하여 요청 URI의 조회 구성요소에 포함된다.HTTP POST 요청 또는 이메일을 통해 전송될 때, 데이터는 메시지 본문에 배치되며,application/x-www-form-urlencoded메시지의 Content-Type 헤더에 포함됨.

참고 항목

참조

  1. ^ RFC 1738 §2.2; RFC 2396 §2.4; RFC 3986 §1.2.1, 2.1, 2.5
  2. ^ "ECMAScript 2017 Language Specification (ECMA-262, 8th edition, June 2017)". Ecma International.
  3. ^ 'mailto' URL을 양식 작업으로 사용한 이메일 기반 HTML 양식 제출에 대한 사용자 에이전트 지원은 HTML 3.2 시대 동안 RFC 1867 섹션 5.6에서 제안되었다.다양한 웹브라우저는 별도의 이메일 프로그램을 호출하거나 자체적인 초보적인 SMTP 기능을 사용하여 이를 구현했다.때로는 신뢰할 수 없지만 웹 서버나 CGI 스크립트를 사용하지 않고 폼 데이터를 전송할 수 있는 간단한 방법으로 잠시 인기가 있었다.
  4. ^ Berners-Lee, T. (June 1994). "RFC 1630". IETF Tools. IETF. Retrieved 29 June 2016.

외부 링크

다음 사양은 모두 어떤 형태로든 예약된 문자, 예약되지 않은 문자 및 백분율 인코딩을 논의하고 정의한다.

  • RFC 3986 / STD 66(에라타 포함), 현재 일반 URI 구문 사양
  • RFC 2396(오브솔뜨, 에라타 추가)과 RFC 2732(에라타 추가)는 함께 일반 URI 구문 규격의 이전 버전을 구성했다.
  • URL 인코더 온라인 - 파일 또는 텍스트를 URL 인코딩 형식으로 변환하기 위한 다양한 옵션이 있는 웹 사이트.
  • URL 디코더 온라인 - 파일이나 텍스트를 URL 디코딩 형식으로 변환하기 위한 다양한 옵션이 있는 웹 사이트.