URL 인코드 / 디코드
텍스트의 URL 인코드/디코드를 실시간으로 변환. 쿼리 파라미터 확인이나 비 ASCII URL 처리에 유용합니다.
📖 자주 걸리는 지점
텍스트의 URL 인코딩과 디코딩을 실시간으로 수행합니다. encodeURIComponent 에 준거하며 처리는 브라우저 안에서 끝납니다. URL 인코딩이라고 불리는 처리는 한 종류가 아닙니다 — URL 의 어디에 두는 값인지에 따라 이스케이프해야 할 문자가 다릅니다. 경로의 일부와 쿼리의 값과 폼의 전송 내용에서는 규칙이 다르며 이 혼동이 문제의 대부분을 낳습니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| encodeURI 와 encodeURIComponent 를 잘못 쓴다 | encodeURI 는 URL 전체를 인코딩하기 위한 함수이므로 URL 의 구분으로서 의미를 갖는 / · ? · & · = · # · : 를 그대로 남깁니다. 따라서 쿼리의 값으로서 URL 을 넘길 때 이것을 쓰면 값 안의 & 나 = 가 구분으로 해석되어 파라미터가 갈라집니다 — ?redirect=https://a.com/?x=1&y=2 라면 받는 쪽은 redirect · y 라는 두 개의 파라미터로 읽습니다. 증상은 값의 도중에 끊긴다는 것이므로 짧은 값으로 테스트하고 있으면 알아챌 수 없습니다. |
URL 의 부품에는 항상 encodeURIComponent 를 쓰세요 — 쿼리의 값, 경로의 한 세그먼트, 프래그먼트의 내용은 모두 부품입니다. encodeURI 를 써도 되는 것은 이미 조립이 끝난 URL 전체를 한 번만 통과시킬 때뿐이며 실무에서는 거의 나설 자리가 없습니다. 더 확실한 것은 직접 문자열을 연결하지 않고 URLSearchParams 나 new URL() 을 쓰는 것입니다 — const u = new URL(base); u.searchParams.set("redirect", target); 라고 쓰면 이스케이프의 판단 자체가 불필요해집니다. URL 을 문자열 연결로 조립하고 있는 곳은 그 자체가 버그의 후보라고 생각하세요. |
| 플러스 기호가 공백으로 바뀐다 | 공백을 나타내는 방법이 두 가지 있습니다. URI 의 퍼센트 인코딩에서는 %20 이지만 HTML 폼의 application/x-www-form-urlencoded 에서는 + 입니다. encodeURIComponent 는 전자를 따르므로 공백을 %20 으로 만들지만 받는 쪽이 폼 형식으로 해석하면 값에 포함되어 있던 진짜 + 가 공백으로 변환됩니다. 실해가 큰 것은 메일 주소의 에일리어스로 user+tag@example.com 을 쿼리로 넘기면 user tag@example.com 이 되어 도달하지 않게 됩니다. Base64 의 표준 알파벳에도 + 가 포함되므로 토큰을 URL 에 실으면 같은 문제가 일어납니다. |
쿼리 문자열을 조립한다면 URLSearchParams 를 쓰세요 — 값 안의 + 를 올바르게 %2B 로 이스케이프하고 공백은 + 로 써내므로 받는 쪽이 폼 형식으로 해석해도 일관됩니다. 손으로 조립하는 경우에는 값에 + 가 포함될 수 있다면 명시적으로 %2B 로 치환하세요. Base64 를 URL 에 실을 거라면 처음부터 URL-safe 형식(- 과 _)을 쓰세요 — 표준 알파벳을 URL 인코딩하는 것보다 확실합니다. 이 문제는 우연히 값에 + 가 들어 있을 때만 깨지므로 테스트 데이터에 반드시 + 를 포함하는 값을 넣으세요. |
| 이중 인코딩으로 %25 가 늘어선다 | 이미 인코딩된 문자열을 한 번 더 인코딩하면 % 자신이 %25 가 됩니다 — %20 은 %2520 으로, 일본어라면 %E3%81%82 가 %25E3%2581%2582 가 됩니다. 디코딩을 한 번밖에 하지 않는 쪽에서는 이 여분의 층이 그대로 남아 화면에 %20 이라는 문자열이 표시됩니다. 원인은 어느 층에서 인코딩할지가 정해져 있지 않은 것이며 프레임워크가 자동으로 인코딩하고 있는데 애플리케이션 쪽에서도 수동으로 인코딩하고 있다는 조합이 전형적입니다. 한쪽을 지우면 고쳐지지만 어느 쪽을 지워야 하는지는 코드를 쫓지 않으면 알 수 없습니다. |
인코딩하는 곳을 한 군데로 정하고 문서에 쓰세요 — 이 함수는 인코딩된 값을 받는다, 이 층에서만 인코딩한다고 명기하면 이중 인코딩은 구조적으로 일어나지 않게 됩니다. 그리고 디코딩은 반드시 한 번만 하세요 — 아직 % 가 남아 있으니 한 번 더 디코딩한다는 루프는 심각한 취약점이 됩니다. 공격자가 %252e%252e%252f 를 보내 1 회째 디코딩으로 %2e%2e%2f, 2 회째로 ../ 가 되면 경로 탐색의 검사를 빠져나갑니다 — 검사는 1 회째 디코딩 결과에 대해 이루어지기 때문입니다. 혹시 모르니 한 번 더 디코딩한다는 발상 자체를 피하세요. |
도메인 이름은 URL 인코딩이 아니라 퓨니코드입니다. 일본어 도메인의 例え.テスト 는 %E4%BE%8B... 가 아니라 xn--r8jz45g.xn--zckzah 라는 형식으로 변환되어 DNS 에 보내집니다 — 브라우저는 주소창에 일본어로 표시하지만 그것은 표시상의 친절이고 실제로 문의하고 있는 것은 xn-- 의 문자열입니다. 덧붙여 겉모습이 아주 비슷한 다른 문자를 쓴 피싱(호모그래프 공격)이 있으므로 브라우저는 조건에 따라 퓨니코드를 그대로 표시합니다 — 알고 있을 도메인이 xn-- 로 표시되면 의심한다는 것은 유효한 습관입니다. 한 가지 더, URL 의 프래그먼트(# 이후)는 서버에 전송되지 않습니다 — 액세스 로그에도 리퍼러에도 남지 않으므로 쿼리보다는 안전합니다. 다만 브라우저의 기록에는 남으므로 기밀을 URL 에 넣지 않는다는 원칙은 변하지 않습니다.
📖 사용법
-
1
인코딩할 텍스트 입력상단 입력란에 텍스트를 붙여넣으면 실시간으로 인코딩됩니다.
-
2
디코딩할 인코딩된 문자열 입력하단에 URL 인코딩된 문자열을 붙여넣으면 실시간으로 디코딩됩니다.
-
3
결과 복사 후 사용복사 버튼으로 클립보드에 복사합니다.
❓ 자주 묻는 질문
encodeURIComponent와 encodeURI의 차이는?
URL의 일본어는 어떻게 되나요?
+ 기호는 공백을 나타내나요?
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.