잰드케이

URL 인코딩·디코딩 — 깨진 한글 주소 읽기

%EA%B0%80 처럼 인코딩된 URL을 한글로 되돌리고, 반대로 인코딩합니다. encodeURI와 encodeURIComponent 결과를 나란히 보여주고, 긴 URL은 쿼리 파라미터까지 쪼개 줍니다.

입력

디코딩decodeURIComponent — %EA%B0%80 → 가
encodeURIComponent값에 쓸 때. / ? & = 까지 전부 인코딩
encodeURI주소 전체에 쓸 때. 구조 문자는 남겨둠

입력값은 브라우저 밖으로 나가지 않습니다. 모든 계산은 이 페이지 안에서 처리되며, 서버로 전송하거나 저장하지 않습니다.

URL 인코딩이 뭔가요?

주소에 쓸 수 없는 글자를 % + 16진수 두 자리로 바꿔 적는 방식입니다. 퍼센트 인코딩이라고도 부릅니다.

URL 표준이 허용하는 문자는 영문·숫자와 몇 가지 기호뿐입니다. 한글·공백·& 같은 걸 그대로 넣으면 주소가 어디서 끊기는지 알 수 없게 되거나, 브라우저마다 다르게 해석합니다.

그래서 글자를 UTF-8 바이트로 바꾼 다음, 바이트마다 %XX 로 적습니다. 받는 쪽은 이걸 거꾸로 풀어서 원래 글자를 복원합니다.

encodeURI와 encodeURIComponent는 뭐가 다른가요?

주소 전체를 넘기느냐, 주소의 한 조각을 넘기느냐의 차이입니다. 실무에서 가장 자주 틀리는 부분입니다.

encodeURI는 URL의 구조를 살려둡니다. / ? & = : # 같은 건 건드리지 않아요. 완성된 주소 하나를 통째로 정리할 때 씁니다.

encodeURIComponent거의 다 인코딩합니다. 위 기호들까지 %2F %26 로 바꿉니다. 쿼리 파라미터의 처럼 "이건 구조가 아니라 내용이다"라고 알려야 할 때 씁니다.

값에 encodeURI를 쓰면 사고가 납니다. ?q=a&b 를 넣을 때 & 가 살아남아서 서버가 파라미터 두 개로 읽어버립니다. 값에는 항상 encodeURIComponent가 기본입니다.

한글 한 글자가 왜 %EA%B0%80 처럼 세 덩어리인가요?

UTF-8에서 한글 한 글자가 3바이트이기 때문입니다. %XX 하나가 1바이트니까 세 개가 붙습니다.

영문·숫자는 1바이트라 인코딩해도 %XX 하나입니다. 그래서 같은 글자 수라도 한글 주소가 훨씬 길어 보입니다. "가"는 %EA%B0%80, "가나다"는 9덩어리가 됩니다.

%EC%EA로 시작하는 덩어리가 잔뜩 보인다면 거의 확실히 한글입니다. 위 도구에 붙여넣으면 바로 읽힙니다.

+와 %20은 뭐가 다른가요?

둘 다 공백을 뜻하지만, 통하는 자리가 다릅니다.

%20은 URL 어디서나 공백입니다. 반면 +가 공백이 되는 건 HTML 폼이 보낸 데이터(application/x-www-form-urlencoded) 규칙일 때뿐입니다. 그 외의 자리에서 +는 그냥 더하기 기호입니다.

그래서 검색어에 +가 들어 있으면 서버가 공백으로 착각하는 버그가 생깁니다. 위 도구의 "+ 를 공백으로" 스위치로 양쪽 해석을 다 확인할 수 있습니다.