이 도구について
이 무료 URL 인코더 / 디코더는 텍스트를 퍼센트 인코딩하여 URL이나 쿼리 문자열 안에서 안전하게 쓸 수 있게 만들고, 인코딩된 URL을 다시 읽을 수 있는 텍스트로 되돌립니다.
UTF-8을 정확하게 처리하므로 악센트가 붙은 글자, 이모지, 비라틴 문자도 깨지지 않고 인코딩·디코딩됩니다. 모든 처리는 브라우저 안에서 이루어지며, 아무것도 업로드되지 않습니다.
퍼센트 인코딩이란
URL에는 정해진 소수의 문자만 들어갈 수 있습니다. 그 밖의 모든 것 — 공백, 따옴표, &, #, ?, 악센트가 붙은 글자, 한글이나 중국어나 아랍어로 된 모든 것 — 은 보내기 전에 다시 써야 합니다.
퍼센트 인코딩은 문자를 % 와 그 바이트 값의 16진수 표기로 바꾸어 이를 해결합니다. 공백은 %20, 앰퍼샌드는 %26, 물음표는 %3F가 됩니다. 발상은 Base64와 같습니다 — 다루기 까다로운 데이터를 까다로운 통로로 안전하게 보내는 것 — 다만 문자 단위로 처리하기 때문에 결과가 대체로 읽을 수 있는 형태로 남습니다.
인코딩되는 것은 바이트이므로, UTF-8에서 1바이트를 넘는 문자는 여러 개의 이스케이프가 됩니다. é는 2바이트라 %C3%A9가 됩니다. 한글 한 글자는 보통 3바이트이며 세 개의 이스케이프가 됩니다. 이모지는 4바이트입니다. 한글이 들어간 URL을 인코딩하면 그토록 길어 보이는 이유입니다.
왜 중요한가: `&` 문제
이것이 이 도구가 막으려는 오류이며, 거의 모든 사람이 한 번쯤 겪습니다.
쿼리 문자열은 값을 & 와 = 로 구분합니다.
/search?q=coffee&page=2
이제 누군가 Bed & Breakfast를 검색한다고 해 봅시다. 그대로 넣으면:
/search?q=Bed & Breakfast&page=2
서버에는 이제 매개변수가 세 개로 보입니다 — q는 Bed 가 되고, 그다음 의미 없는 Breakfast 매개변수, 그리고 page. 검색은 아무 말 없이 엉뚱한 결과를 돌려줍니다. 값을 먼저 인코딩하면 제대로 작동합니다.
/search?q=Bed%20%26%20Breakfast&page=2
여기서 원칙이 나옵니다. URL 전체가 아니라 값을 각각 인코딩하십시오. 쿼리 문자열의 구조를 만드는 & 와 = 는 그대로 두어야 합니다. 값 안에 들어 있는 & 는 그대로 두면 안 됩니다.
값을 인코딩할 것인가, URL 전체를 인코딩할 것인가
여기가 걸려 넘어지는 지점이며, 자바스크립트에 함수가 두 개인 이유입니다.
encodeURIComponent 는 /, ?, #, &, = 를 포함해 거의 모든 것을 인코딩합니다. URL의 한 조각 — 검색어, 파일 이름, 리디렉션 대상, 토큰 — 에 사용합니다. 대개 필요한 것은 이쪽이고, 이 도구가 하는 일도 이것입니다.
encodeURI 는 구조를 이루는 문자를 건드리지 않습니다. 이미 올바른 완전한 URL을 받았고 사용할 수 없는 문자만 정리하면 된다고 가정하기 때문입니다. URL 전체에 쓰는 것이지, 개별 값에 쓰는 것이 아닙니다.
URL 전체를 Component 쪽으로 인코딩하면 모든 / 가 %2F 로 바뀌어 주소가 작동하지 않습니다. 값을 URI 쪽으로 인코딩하면 & 가 그대로 빠져나가 쿼리 문자열을 망가뜨립니다. 지금 무엇을 하려는지 아는 것이 요령의 전부입니다.
HTML 이스케이프와는 다릅니다
퍼센트 인코딩과 HTML 이스케이프는 비슷해 보이지만 다른 문제를 해결합니다.
퍼센트 인코딩(%20, %26)은 URL 안에서 텍스트를 안전하게 만듭니다. HTML 이스케이프(&, <)는 HTML 문서 안에서 안전하게 만듭니다. 페이지에 표시되는 URL은 둘 다 필요할 수 있으며 순서도 정해져 있습니다 — 먼저 URL용으로 인코딩하고, 그 결과를 HTML용으로 이스케이프합니다.
또 하나 잘 알려진 특이점이 있습니다. + 가 공백을 뜻할 때가 있다는 것입니다. HTML 폼의 잔재로, application/x-www-form-urlencoded 는 %20 대신 + 를 씁니다. 대부분의 서버는 쿼리 문자열에서 둘 다 받아들이지만, 경로 안의 + 는 말 그대로 더하기 기호입니다. 예상하지 못한 곳에서 공백이 + 로 나타난다면 폼 인코더가 원인입니다.
사용 방법
- 텍스트나 URL을 입력란에 붙여넣습니다
- 버튼으로 인코딩 또는 디코딩 합니다
- 바꾸기로 결과를 입력란에 되돌릴 수 있습니다
- 결과를 복사합니다
알아두면 좋은 점
- URL 전체가 아니라 값을 인코딩하십시오. 완전한 주소를 인코더에 넣으면 모든 / 가 %2F 로 바뀌어 망가집니다.
- 두 번 인코딩하지 마십시오. % 자체가 %25 로 인코딩되므로 두 번 거치면 %20 이 %2520 이 되어 공백이 사라집니다. 링크가 알 수 없이 깨지는 가장 흔한 원인입니다.
- 예약 문자에는 의미가 있습니다 — :, /, ?, #, @, &, =, +, $ 등. URL 안에서 쓸 수 있지만 값 안에 들어갈 때는 인코딩해야 합니다.
- 비예약 문자는 인코딩되지 않습니다: A–Z, a–z, 0–9, -, _, ., ~.
- 16진수의 대소문자는 같습니다. %3f 와 %3F 는 동일하며, 관례는 대문자입니다.
- 홀로 있는 % 는 유효하지 않습니다. 디코딩이 실패하면 16진수 두 자리가 따라오지 않는 % 를 찾아보십시오. 문자열이 중간에 잘렸다는 신호인 경우가 많습니다.
자주 묻는 질문
URL의 %20은 무슨 뜻인가요?
공백입니다. 공백은 URL에 쓸 수 없기 때문에 %20 으로 퍼센트 인코딩됩니다. % 뒤의 20 은 공백의 바이트 값을 16진수로 나타낸 것입니다. 공백이 + 로 쓰인 것을 볼 때도 있는데 이는 폼 인코딩에서 온 것입니다. 쿼리 문자열에서는 둘 다 통하지만 경로에서 올바른 것은 %20 뿐입니다.
URL 전체를 인코딩해야 하나요, 일부만 해야 하나요?
일부만 하십시오. URL 안에 넣는 값 — 검색어, 파일 이름, 리디렉션 주소 — 을 각각 인코딩하고, URL의 구조를 만드는 ://, /, ?, &, = 는 그대로 두십시오. 완전한 URL을 인코딩하면 슬래시가 %2F 로 바뀌어 주소로 해석되지 않습니다.
인코딩했더니 링크가 깨진 이유는 무엇인가요?
거의 언제나 이중 인코딩 때문입니다. % 자체가 %25 로 인코딩되므로 이미 인코딩된 문자열을 다시 인코딩하면 %20 이 %2520 이 됩니다. 그러면 디코더는 공백 대신 문자 그대로의 %20 을 돌려줍니다. 다시 인코딩하기 전에 한 번 디코딩해 실제로 무엇을 가지고 있는지 확인하십시오.
악센트가 붙은 글자 하나가 여러 개의 % 코드가 되는 이유는 무엇인가요?
퍼센트 인코딩이 글자가 아니라 바이트를 다루기 때문입니다. UTF-8에서 é 는 2바이트라 %C3%A9 가 됩니다. 한글과 한자 대부분은 3바이트여서 세 개의 이스케이프가 되고, 이모지는 4바이트입니다. 잘못된 것이 아니라 그 글자의 크기가 그대로 드러난 것입니다.
URL 인코딩과 HTML 이스케이프의 차이는 무엇인가요?
보호하는 장소가 다릅니다. URL 인코딩(%26)은 웹 주소 안에서 텍스트를 안전하게 만듭니다. HTML 이스케이프(&)는 HTML 페이지 안에서 안전하게 만듭니다. 페이지에 표시되는 링크는 둘 다 필요할 수 있으며 순서도 정해져 있습니다. 한쪽을 다른 쪽 자리에 쓰면 원래 문제는 그대로 남습니다.
입력한 텍스트가 서버로 전송되나요?
아니요. 인코딩과 디코딩 모두 브라우저 안에서 이루어지므로 붙여넣은 내용이 기기를 벗어나지 않습니다. 인터넷 연결을 꺼도 계속 작동합니다.
관련 도구
- Base64 인코딩 / 디코딩 — 토큰과 데이터 URL에서 끊임없이 마주치는 또 다른 인코딩
- JSON 포매터 — 그런 쿼리 문자열에 실려 오는 JSON을 정리하고 확인
- JWT 디코더 — URL로 도착한 토큰 읽기
- 이메일과 URL 추출 — 글에서 모든 링크 뽑아내기
