URL 인코딩이 필요한 이유는?
URL에는 영문, 숫자, 일부 특수문자만 안전하게 사용할 수 있습니다. 한글이나 예약 문자를 포함하려면 브라우저와 서버가 같은 값으로 해석하도록 퍼센트 인코딩으로 변환해야 합니다.
URL 인코딩/디코딩
URL에 포함된 특수문자, 한글 등을 퍼센트 인코딩하거나 원본으로 디코딩합니다.
입력
결과
URL 인코딩 핵심 질문
%20과 +의 차이는 무엇인가요?
둘 다 공백을 나타내지만 쓰이는 위치가 다릅니다. `%20`은 일반 URL 경로나 표준 인코딩에서 쓰이고, `+`는 주로 폼 전송이나 쿼리스트링의 `application/x-www-form-urlencoded` 규칙에서 사용됩니다.
encodeURI와 encodeURIComponent의 차이는?
전체 URL을 다룰 때는 구조 문자를 남기는 `encodeURI`를 쓰고, 쿼리 파라미터 값처럼 한 조각만 안전하게 바꿀 때는 거의 모든 특수문자를 인코딩하는 `encodeURIComponent`를 써야 합니다.
자주 묻는 질문
URL 인코딩이 필요한 이유는?
URL에는 영문, 숫자, 일부 특수문자만 사용할 수 있습니다. 한글이나 특수문자를 URL에 포함하려면 %XX 형태로 인코딩해야 합니다.
%20과 +의 차이는 무엇인가요?
둘 다 공백을 나타내지만, %20은 URL 경로에서, +는 쿼리스트링(폼 데이터)에서 주로 사용됩니다.
encodeURI와 encodeURIComponent의 차이는?
encodeURI는 전체 URL을 인코딩하되 :, /, ? 등은 유지합니다. encodeURIComponent는 모든 특수문자를 인코딩하므로 쿼리 파라미터 값에 사용합니다.
한글 URL은 왜 길어지나요?
UTF-8에서 한글 1자는 3바이트이고, 각 바이트가 %XX 형태(3자)로 변환되므로 한글 1자가 9자로 늘어납니다.
입력한 데이터가 서버로 전송되나요?
아닙니다. 모든 처리가 브라우저에서 이루어집니다.
URL 인코딩이 필요한 이유
한글 URL이 %EA%B2%80처럼 긴 문자열로 바뀌는 이유는?
UTF-8에서 한글 1자는 3바이트를 차지합니다. 각 바이트는 퍼센트 기호와 16진수 두 자리(%XX, 3자)로 변환되므로, 한글 1자가 9자의 인코딩 문자열이 됩니다. '검색' 두 글자가 %EA%B2%80%EC%83%89(18자)로 바뀌는 것은 이 구조 때문이며, URL에 한글이 많을수록 주소가 급격히 길어지는 것은 정상적인 현상입니다.
URL(Uniform Resource Locator)은 RFC 3986 표준에 따라 사용할 수 있는 문자가 엄격하게 제한되어 있습니다. 영문 대소문자(A-Z, a-z), 숫자(0-9), 그리고 일부 특수문자(-, _, ., ~)만 "비예약 문자"로 안전하게 사용할 수 있습니다.
반면 :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, = 같은 문자는 "예약 문자"로, URL 구조에서 특별한 의미를 가집니다. 예를 들어 ?는 쿼리 스트링의 시작을, &는 파라미터의 구분을 나타내죠. 이런 문자를 데이터 값으로 사용하려면 반드시 퍼센트 인코딩(%XX)으로 변환해야 합니다.
한글이나 일본어, 중국어 같은 비ASCII 문자는 URL에 직접 넣을 수 없습니다. 브라우저 주소창에서는 한글이 그대로 보여도, 실제로 서버에 전송되는 시점에는 UTF-8로 인코딩된 바이트를 각각 %XX로 변환하여 전송합니다. "검색"이라는 한글 두 글자가 %EA%B2%80%EC%83%89이라는 18자로 바뀌는 이유가 바로 이 때문입니다.
URL 구조와 인코딩 범위
URL은 여러 부분으로 나뉘며, 각 부분마다 인코딩 규칙이 다릅니다.
scheme://host:port/path?query=value#fragment
scheme (https, ftp 등): 인코딩하지 않습니다. 프로토콜은 항상 ASCII 문자만 사용합니다.
host (도메인명): 한글 도메인은 퍼센트 인코딩이 아니라 Punycode(xn--)로 변환됩니다. "한국.kr"은 "xn--3e0b707e.kr"이 됩니다.
path (경로): 예약 문자 중 /는 경로 구분자로 유지하고, 나머지 특수문자와 한글은 인코딩합니다.
query (쿼리 스트링): =와 &는 구조 문자로 유지하고, 파라미터의 키와 값에 포함된 특수문자를 인코딩합니다. 공백은 %20 또는 +(application/x-www-form-urlencoded)로 표현됩니다.
fragment (#hash): 브라우저에서만 사용되며 서버로 전송되지 않습니다. # 뒤의 값도 인코딩 대상입니다.
자주 사용되는 인코딩 문자
| 문자 | 인코딩 | 설명 |
|---|---|---|
| 공백 | %20 또는 + | 경로에서는 %20, 폼 데이터에서는 + |
| & | %26 | 쿼리 파라미터 구분자와 혼동 방지 |
| = | %3D | 키=값 구분자와 혼동 방지 |
| ? | %3F | 쿼리 스트링 시작 구분자와 혼동 방지 |
| # | %23 | 프래그먼트 구분자와 혼동 방지 |
| / | %2F | 경로 구분자와 혼동 방지 (값 안에서) |
| 한 (한글 예시) | %ED%95%9C | UTF-8 3바이트, 각 바이트를 %XX로 변환 |
한글 한 글자가 9자(%XX%XX%XX)로 늘어나는 이유는 UTF-8에서 한글이 3바이트를 차지하고, 각 바이트마다 %와 16진수 두 자리(3자)로 표현되기 때문입니다. 한글이 많이 포함된 URL이 유난히 길어지는 것은 이런 구조 때문이니 정상적인 현상입니다.
JavaScript 인코딩 함수 비교
encodeURIComponent와 encodeURI 중 어떤 것을 써야 하나요?
쿼리 파라미터의 값 하나를 인코딩할 때는 encodeURIComponent를 사용하세요. 이 함수는 :, /, ?, # 같은 URL 구조 문자까지 모두 인코딩합니다. 전체 URL을 다룰 때는 구조 문자를 보존하는 encodeURI가 적합합니다. 잘못 선택하면 URL이 깨지거나 이중 인코딩 문제가 발생합니다.
JavaScript에서 URL 인코딩에 사용하는 함수가 여러 개 있는데, 각각의 인코딩 범위와 용도가 다릅니다. 잘못된 함수를 사용하면 URL이 깨지거나 이중 인코딩 문제가 발생할 수 있으므로 정확히 구분해서 사용해야 합니다.
| 함수 | 인코딩 범위 | 용도 |
|---|---|---|
| encodeURI() | :, /, ?, #, &, = 등 URL 구조 문자 유지 | 전체 URL을 인코딩할 때 |
| encodeURIComponent() | 거의 모든 특수문자 인코딩 | 쿼리 파라미터 값 하나를 인코딩할 때 |
| escape() (사용 금지) | 비표준, 유니코드 미지원 | Deprecated. 사용하지 마세요 |
가장 흔한 실수는 URL 전체를 encodeURIComponent()에 넣는 것입니다. 이 함수는 /, :, ? 같은 URL 구조 문자까지 인코딩해버리기 때문에 URL이 완전히 깨집니다. 전체 URL에는 encodeURI()를, 파라미터 값에는 encodeURIComponent()를 사용하세요.
이중 인코딩도 주의해야 합니다. 이미 인코딩된 %20을 다시 인코딩하면 %2520이 되어 서버에서 올바르게 해석하지 못합니다. 인코딩 전에 원본 문자열인지 확인하는 습관이 중요합니다.
개인정보 보호
이 도구에서 입력하는 모든 데이터는 브라우저에서만 처리되며, 서버로 전송되지 않습니다. URL에 포함된 민감한 쿼리 파라미터도 외부에 노출될 걱정 없이 안전하게 인코딩/디코딩할 수 있습니다.