Skip to main content

​
퍼센트 인코딩 매개변수

X API의 일부, 특히 OAuth 서명을 처리하는 부분에서는 문자열을 RFC 3986, Section 2.1에 따라 인코딩해야 합니다. 많은 URL 인코딩 알고리즘 구현이 RFC 3986과 완전히 호환되지 않기 때문에, 잘못된 인코딩이 많은 OAuth 서명 오류의 원인이 됩니다. 이러한 이유로, 이 페이지에서는 사용해야 하는 정확한 서명 알고리즘을 설명합니다. 이 페이지에서는 RFC 3986, Section 2.1에 설명된 URL 인코딩 과정을 다룹니다. 이 문서와 모호하거나 상충되는 부분이 있을 경우를 대비해 해당 규격서를 참고할 것을 권장합니다.  

​
문자열 인코딩

다음 알고리즘은 문자열 SRC의 값을 바이트 단위로 그대로 복사해 문자열 DST를 만드는 방식으로 인코딩한다고 가정합니다. 1단계: SRC에 아직 읽지 않은 바이트가 남아 있는 동안, SRC에서 다음 바이트(8비트)를 읽습니다. 일반적으로 이것을 문자라고 보지만, 하나의 문자가 여러 바이트일 수 있는 인코딩(예: UTF-8)의 경우에는 첫 번째 바이트만 읽습니다. 2단계: 읽은 바이트가 아래의 ASCII 값 중 하나와 일치하는지 확인합니다. 아래 표는 가독성을 위해 여러 행으로 나뉘어 있지만, 실제로는 읽은 바이트가 어느 행에 있는지는 상관없이, 표에 존재하는지만 판단하면 됩니다. 2b단계: 바이트가 위 표에 나와 있지 않다면, 계속 진행합니다. 표에 없는 다른 모든 값은 인코딩해야 합니다. 2a단계: 바이트가 위 표에 나와 있다면, 그 바이트를 DST에 복사한 뒤 1단계로 돌아갑니다. 위 표에 있는 문자는 이스케이프할 필요가 없으므로, 해당 바이트를 그대로 복사하기만 하면 됩니다. 3단계: 문자 ‘%’를 DST에 기록합니다. 퍼센트 문자 ‘%’(16진수로 0x25, 2진수로 00100101)는 뒤이어 나오는 두 문자가 인코딩된 바이트를 나타낸다는 의미입니다. 4단계: 현재 바이트의 대문자 ASCII 인코딩 16진수 값을 나타내는 두 문자를 DST에 기록합니다. 이 부분은 약간 헷갈릴 수 있으므로 예제를 들어 보겠습니다. 현재 바이트가 0xE6(2진수로 11100110)이라고 가정합니다. 이는 ‘æ’의 UTF-8 인코딩 값에 해당합니다. 이 값을 인코딩하려면 먼저 문자 ‘E’(위 표에서 0x45)를, 그 다음에 문자 ‘6’(0x36)을 DST에 기록합니다. 마지막으로 기록된 세 문자는 “%E6”가 되어야 합니다. A, B, C, D, E 또는 F와 같은 문자를 기록하는 경우에는 반드시 대문자를 사용해야 합니다. 5단계: 1단계로 돌아갑니다. SRC 전체가 DST로 복사될 때까지 계속 반복합니다.  

​
예시

다음 예시는 직접 작성한 코드의 출력과 비교하는 데 도움이 될 수 있습니다. 모든 차이는 오류로 간주해야 합니다. 공백을 “+” 문자로 인코딩하는 것은 잘못된 인코딩의 한 예입니다.