URL 인코딩·디코딩

URL Encoder & Decoder

URL과 쿼리 값을 퍼센트 인코딩·디코딩하며 전체 URL과 구성요소 모드를 구분합니다.

주소를 퍼센트 인코딩하고 되돌립니다. 흔히 "URL 인코딩"이라고 뭉뚱그리는 네 가지 규칙 — `encodeURIComponent`, `encodeURI`, 엄격한 RFC 3986, 그리고 공백이 `+`가 되는 폼 인코딩 — 을 따로 둡니다. 잘못 고르면 누군가 `&`를 입력하기 전까지만 멀쩡한 링크가 나옵니다.

🔒 브라우저 안에서만 처리urlencodedecodepercent

규칙

방향

적용 범위

쿼리 값 하나, 경로 조각 하나, 프래그먼트 하나에 씁니다. `encodeURIComponent`가 하는 일: `/ ? : @ & = + $ , #`를 이스케이프하고 `A-Za-z0-9 - _ . ! ~ * ' ( )`는 그대로 둡니다.

텍스트

인코딩된 값

입력

0자

출력

0자

이스케이프된 글자

쿼리 문자열로 편집

사용 방법

적용 범위를 먼저 고릅니다
쿼리 값 하나나 경로 조각 하나라면 Component입니다. 대부분 이 경우입니다. 전체 URL은 이미 완성된 주소를 다듬을 때만 쓰고, `?`·`&`·`/`는 일부러 건드리지 않습니다.
붙여넣고 결과를 봅니다
아래 숫자에 몇 글자가 이스케이프됐는지 나옵니다. 아무것도 하지 않는 범위를 골랐다는 걸 빨리 알아채는 방법입니다.
옛 주소를 디코딩할 때는 바이트 인코딩을 바꿉니다
십여 년 전 한국 사이트의 링크는 UTF-8이 아니라 EUC-KR 바이트를 퍼센트 인코딩했습니다. UTF-8로 풀면 글자가 깨집니다. 디코딩 모드의 선택 상자에 EUC-KR, Shift_JIS, GB18030과 Latin-1 계열이 있습니다.
파라미터가 많으면 항목별로 편집합니다
"쿼리 문자열로 편집"을 켜면 URL이 이름·값 행으로 나뉩니다. 값은 디코딩해 보여 주고 다시 인코딩해 씁니다. 그래서 `next=` 안에 통째로 들어간 URL도 편집을 견딥니다.

자주 묻는 질문

Component와 전체 URL은 뭐가 다른가요?

Component는 구분자 `/ ? : @ & = +`까지 이스케이프합니다. 값 안에 그런 글자가 있으면 URL이 쪼개지기 때문입니다. 전체 URL은 그것들이 구조라서 그대로 둡니다. 값에 전체 URL 규칙을 쓰는 게, 값에 앰퍼샌드가 들어오는 순간 깨지는 링크를 만드는 전형적인 방법입니다.

서명 검증이 왜 실패하나요?

`encodeURIComponent`가 `! ' ( ) *`를 그대로 두는데 RFC 3986은 그렇지 않기 때문일 가능성이 큽니다. OAuth 1.0, AWS SigV4를 비롯한 대부분의 서명 방식은 엄격한 규칙으로 정규화해서, 아포스트로피가 든 값은 해시가 달라집니다. 엄격 범위가 그래서 있습니다.

"두 번 인코딩됐다"는 안내는 무슨 뜻인가요?

결과를 한 번 더 디코딩하면 다른 값이 나온다는 뜻입니다. `%20`이어야 할 자리에 `%2520`이 있는 경우죠. 대개 클라이언트에서 한 번, 프록시나 프레임워크에서 또 한 번 인코딩된 것입니다. 원본을 얻으려면 두 번 디코딩하고, 그다음에 파이프라인을 고치세요.

공백이 왜 어떨 때는 `+`이고 어떨 때는 `%20`인가요?

`+`는 `application/x-www-form-urlencoded`의 것입니다. 폼 POST 본문과 `URLSearchParams`가 만드는 형식이죠. URL의 다른 자리에서 공백은 `%20`이고, `+`는 더하기 기호 그 자체입니다. 섞어 쓰면 `a+b`가 `a b`가 되거나 그 반대가 됩니다.