URL 인코드 / 디코드

검색어를 쿼리 값으로 넣을 때

?q= 뒤에 검색어를 붙이기 전에 검색어를 하나의 ‘값’으로 인코딩해야 합니다. 그대로 두면 공백이나 &, =가 URL의 구분자로 읽힙니다.

서울 맛집 (강남)을 기본 설정으로 인코딩하면 %EC%84%9C%EC%9A%B8%20%EB%A7%9B%EC%A7%91%20(%EA%B0%95%EB%82%A8)이 됩니다. 한글 한 음절은 %XX 세 개, 공백은 %20이고, 괄호는 인코딩되지 않고 그대로 남습니다.

공백을 +로 (폼 데이터)를 켜면 같은 입력이 %EC%84%9C%EC%9A%B8+%EB%A7%9B%EC%A7%91+%28%EA%B0%95%EB%82%A8%29가 됩니다. 공백은 +로 바뀌고, 이번에는 괄호도 %28, %29로 인코딩됩니다. 브라우저의 폼 전송이나 URLSearchParams가 만드는 형식과 같습니다. 서명 값을 비교하는 API라면 상대가 어느 형식으로 계산하는지 먼저 확인하세요.

EUC-KR로 만들어진 오래된 주소

HTML 폼은 페이지 자체의 문자 인코딩으로 쿼리를 인코딩합니다(HTML Living Standard 4.10.22.5: 먼저 문서의 문자 인코딩을 사용). 그래서 EUC-KR로 작성된 페이지에서 전송된 ‘서울’은 UTF-8의 %EC%84%9C%EC%9A%B8이 아니라 %BC%AD%BF%EF가 됩니다.

이 값을 디코딩하면 깨진 글자를 보여 주는 대신 1번째 문자부터: %BC%AD%BF%EF은(는) 올바른 UTF-8이 아닙니다. EUC-KR 등 다른 인코딩의 텍스트는 여기서 디코딩할 수 없습니다.라고 표시하고 멈춥니다. EUC-KR은 WHATWG Encoding Standard에서 레거시 인코딩으로 분류되며, 읽으려면 인코딩을 지정할 수 있는 처리가 필요합니다. 예를 들어 Python에서는 urllib.parse.unquote('%BC%AD%BF%EF', encoding='euc-kr')로 서울을 얻습니다.

두 번 인코딩된 값

주소에 %25가 보이면 이미 인코딩된 값을 한 번 더 인코딩했을 가능성이 큽니다. % 자체가 %25로 바뀌기 때문입니다. 예를 들어 a b는 a%20b가 되고, 한 번 더 인코딩하면 a%2520b가 됩니다. 이런 값을 디코딩 칸에 넣고 한 번 풀면 직전 단계가 보이므로, 어느 단계에서 인코딩이 중복됐는지 거슬러 올라가 확인할 수 있습니다.

이 도구를 쓰기 좋은 경우

• 쿼리 값에 공백, &, =, #, 한글이 들어갈 때.
• 주소 전체를 다른 주소의 파라미터로 넘길 때(로그인 후 돌아갈 주소 등). :와 /도 인코딩되므로 하나의 값으로 전달됩니다.
• 바로 열어 볼 완전한 주소를 정리하는 용도에는 맞지 않습니다. 구분자까지 인코딩되어 링크로 쓸 수 없게 됩니다. 이때는 URL 파서에서 파라미터를 하나씩 고치세요.

제한 사항

• UTF-8만 지원하며 인코딩을 추측하지 않습니다. EUC-KR, CP949 등으로 만든 퍼센트 인코딩은 대부분 오류가 나지만, 바이트가 우연히 올바른 UTF-8이면 다른 글자로 바뀌어 표시되고 경고도 없습니다. 예를 들어 EUC-KR의 ‘홍’은 %C8%AB인데, 디코딩하면 ȫ가 됩니다.
• 디코딩은 첫 번째 문제에서 멈추고 위치를 알려 줍니다. 끝에 홀로 있는 100%의 %도 오류입니다.
• 기본 인코딩은 ! ' ( ) *를 그대로 둡니다(encodeURIComponent의 규칙). 서명 계산 등에서 %21 %27 %28 %29 %2A가 필요하면 직접 바꿔야 합니다.
• encodeURI 모드는 없습니다.
• 이모지 중간이 잘린 문자열(짝이 없는 서로게이트)은 인코딩할 수 없으며 위치를 표시합니다.