URL 인코딩/디코딩 도구
빠른 URL 인코딩 및 디코딩, 다양한 인코딩 모드 지원
변환 방식 선택
URL 인코딩이란?
URL 인코딩(퍼센트 인코딩이라고도 함)은 문자를 URL에서 안전하게 전송할 수 있는 형식으로 변환하는 메커니즘입니다. URL은 ASCII 문자 집합의 특정 문자만 포함할 수 있으므로, 다른 문자(한글, 공백, 특수 기호 등)는 %XX 형식으로 인코딩해야 합니다. XX는 문자의 16진수 값입니다. 예: 공백은 %20으로, 한글 "한"은 %ED%95%9C으로 인코딩됩니다.
사용 방법
사용 방법
- 인코딩/디코딩할 텍스트를 입력 상자에 입력하거나 붙여넣으세요
- 인코딩 방법을 선택하세요: encodeURIComponent 또는 encodeURI
- 결과가 자동으로 표시되며, 원클릭 복사 또는 입력/출력 교환이 가능합니다
- 디코딩할 때는 해당 디코딩 방법을 선택하세요
URL 컨텍스트
- 쿼리 값과 경로 세그먼트에는 컴포넌트 인코딩을 사용하세요. 잘못된 함수로 전체 URL을 인코딩하면 /, ?, & 같은 구분 기호가 손상될 수 있습니다.
- 디코딩 시 %2520과 같은 이중 인코딩을 확인하세요. 이는 퍼센트 기호가 다시 인코딩된 것을 의미합니다.
활용 사례
기술 원리
URL 인코딩(퍼센트 인코딩)은 RFC 3986 §2.1에 정의되어 있으며, 문자를 %XX 형식으로 변환합니다. 여기서 XX는 UTF-8 바이트 값의 두 자리 대문자 16진수 표현입니다. RFC는 두 문자 클래스를 정의합니다: 인코딩되지 않는 비예약 문자(A-Z a-z 0-9 - _ . ~)와 컨텍스트에 따라 인코딩되는 예약 문자(gen-delims : / ? # [ ] @ 및 sub-delims ! $ & ' ( ) * + , ; =). 예약 문자는 일부 URL 구성 요소에서 구조적 의미를 가지지만 다른 곳에서는 리터럴 데이터입니다. JavaScript는 범위가 다른 두 가지 내장 함수를 제공합니다. encodeURIComponent()는 A-Z a-z 0-9 - _ . ! ~ * ' ( )를 제외한 모든 문자를 인코딩합니다. 이는 개별 쿼리 매개변수 값, 경로 세그먼트, 프래그먼트 식별자를 인코딩하는 데 올바른 선택입니다. encodeURI()는 추가로 구조 문자 : / ? # [ ] @ ! $ & ' ( ) * + , ; =를 보존하며, 구문 구조를 유지하면서 전체 URI를 인코딩하도록 설계되었습니다. 핵심 차이점은 encodeURIComponent()가 /와 &를 인코딩하여 전체 문자열에 적용하면 URL을 손상시키는 반면, encodeURI()는 이를 보존한다는 것입니다. 공백 처리는 가장 흔한 상호 운용성 함정입니다. RFC 3986은 %20을 공백 문자(U+0020)의 정식 퍼센트 인코딩으로 지정합니다. 그러나 application/x-www-form-urlencoded MIME 타입(HTML 4.01 이후 HTML 폼 제출에 사용)은 공백을 +로 인코딩합니다. 두 방식은 호환되지 않습니다: %20을 기대하는 서버는 +를 리터럴로 해석하고, +를 기대하는 서버는 %20을 리터럴 퍼센트 기호와 20으로 취급합니다. 이 도구는 %20을 생성하는 encodeURIComponent()를 사용하여 RFC 3986을 따릅니다. x-www-form-urlencoded 페이로드(POST 본체 또는 레거시 미들웨어가 파싱한 쿼리 문자열)를 디코딩하는 사용자는 이 차이를 인식해야 합니다. 다중 바이트 문자 처리는 자동이지만 이해할 가치가 있습니다: 입력 문자열이 먼저 UTF-8 바이트로 인코딩된 다음 각 바이트가 개별적으로 퍼센트 인코딩됩니다. '你'(U+4F60) 같은 CJK 문자는 3 UTF-8 바이트(E4 BD A0)를 차지하여 %E4%BD%A0을 생성합니다. 서버가 GBK 같은 다른 문자셋으로 파싱하면 동일한 문자가 %C4%E3(2바이트)로 인코딩되고, 양쪽이 UTF-8에 동의하지 않으면 디코딩 결과가 깨집니다. 이중 인코딩은 또 다른 일반적인 버그입니다: %2520은 리터럴 퍼센트 기호(%25) 뒤에 20이 오는 것으로, 입력이 이미 퍼센트 인코딩된 상태에서 두 번째 인코딩이 적용되었음을 나타냅니다. 디코드 모드는 잘못된 시퀀스(불완전한 %XX)를 감지하고 조용히 쓰레기를 생성하는 대신 오류를 표면화합니다.
- encodeURIComponent vs encodeURI: encodeURIComponent는 / ? & #를 인코딩하며 쿼리 값, 경로 세그먼트, 프래그먼트에 올바름; encodeURI는 이 구조 문자를 보존하며 전체 URL에 올바름 — 잘못된 함수를 사용하는 것이 URL 인코딩에서 가장 흔한 버그
- RFC 3986 예약 문자 집합: gen-delims(: / ? # [ ] @)는 URL 구문을 전달; sub-delims(! $ & ' ( ) * + , ; =)는 URL 구성 요소에 따라 구분자 또는 데이터 — 컨텍스트가 예약 문자의 퍼센트 인코딩 여부를 결정
- 공백 인코딩: RFC 3986 정식 형식은 %20(encodeURIComponent가 생성); application/x-www-form-urlencoded는 +(HTML 폼 기본값) 사용 — 두 방식은 의미론적으로 호환되지 않으며 혼용하면 서버 측 파서를 손상
- UTF-8 다중 바이트 인코딩: '你'(U+4F60) → UTF-8 바이트 E4 BD A0 → %E4%BD%A0(3개의 퍼센트 인코딩 옥텟); GBK 하의 동일 문자 → %C4%E3(2옥텟) — 비ASCII 텍스트에 대한 클라이언트-서버 문자셋 일치 필수
- 이중 인코딩 감지: %2520은 먼저 %20으로 디코딩된 다음 공백으로 디코딩 — 디코드 모드의 출력이 이 패턴을 드러냄; %ZZ나 %2(불완전) 같은 잘못된 시퀀스는 감지되어 오류로 보고
- IRI(RFC 3987): 국제화 리소스 식별자는 URL에 Unicode 문자를 직접 허용; 브라우저는 주소 표시줄에 디코딩된 형태를 표시하지만 전송 시에는 퍼센트 인코딩된 UTF-8 형태를 전송 — 도구의 인코드 모드는 HTTP를 통해 실제로 전송되는 것을 보여줌
- decodeURIComponent 오류 처리: 불완전한 퍼센트 시퀀스(% 뒤에 16진수 2자리 미만)가 포함된 문자열을 전달하면 URIError 발생 — 도구는 try/catch로 호출을 래핑하고 조용히 빈 문자열을 반환하는 대신 오류 메시지를 표면화
예시
한자(중국어) 인코딩 (UTF-8 퍼센트 인코딩)
입력: 你好世界 (CJK 4자, UTF-8 12바이트)
출력: %E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C
각 UTF-8 바이트(E4, BD, A0, ...)가 %XX 형식으로 변환
RFC: RFC 3986 섹션 2.1은 URI의 퍼센트 인코딩을 정의
용도: 쿼리 파라미터, 경로 세그먼트, 폼 데이터 전송쿼리 문자열 구분자 인코딩
입력: name=张三&age=20
출력: name%3D%E5%BC%A0%E4%B8%89%26age%3D20
%3D는 '='(키와 값 사이의 구분자)을 인코딩
%26은 '&'(파라미터 사이의 구분자)을 인코딩
RFC: RFC 3986 섹션 3.4는 query 컴포넌트의 예약 문자를 정의전체 URL 인코딩 (부분 인코딩)
입력: https://example.com/search?q=你好&type=web
출력: https://example.com/search?q=%E4%BD%A0%E5%A5%BD&type=web
참고: 스킴, 호스트, 기존 구분자는 인코딩되지 않습니다
비-ASCII 쿼리 값만 퍼센트 인코딩됩니다
RFC: RFC 3986 섹션 3은 계층적 URI 컴포넌트를 정의공백 문자 인코딩 (두 가지 관행)
경로 세그먼트: %20 (RFC 3986 준수)
쿼리 문자열: + (HTML 폼의 역사적 관행)
예시: /search for me -> /search%20for%20me
예시: q=hello world -> q=hello+world
둘 다 동일하게 디코딩됩니다. encodeURI는 %20을 사용하고, 일부 구현에서 encodeURIComponent는 경로에 %20, 쿼리에 +를 사용합니다자주 묻는 질문
URL 인코딩은 무엇을 하나요?
URL의 안전하지 않은 문자를 % 시퀀스로 대체합니다: 공백 → %20, & → %26, # → %23 등. RFC 3986은 어떤 문자가 안전한지(영숫자와 -, _, ., ~) 그리고 어떤 문자에 인코딩이 필요한지 명시합니다. 브라우저, 서버, HTTP 라이브러리 모두 적절한 경계에서 URL 인코딩을 적용하거나 기대합니다.
encodeURI와 encodeURIComponent의 차이는?
encodeURI는 URL 구문 문자(: / ? # & =)를 그대로 둡니다 — 전체 URL을 기대합니다. encodeURIComponent는 그 문자들도 인코딩합니다 — 단일 매개변수 값을 기대합니다. 페이지는 두 모드를 모두 제공하므로, 쿼리 매개변수에는 컴포넌트 인코딩, 전체 URL에는 URI 인코딩을 선택하세요.
왜 공백이 어떨 땐 %20이고 어떨 땐 +가 되나요?
%20이 URI 표준입니다. +는 HTML 폼 제출에 사용되는 application/x-www-form-urlencoded MIME 유형의 레거시 관례입니다. 대부분의 서버에서는 동일하게 보이지만 엄밀히 같진 않습니다 — 최신 URL에서는 %20을 사용하세요.
유니코드 문자도 인코딩해야 하나요?
RFC 3986은 ASCII만 허용합니다; 비 ASCII는 UTF-8로 인코딩한 뒤 퍼센트 이스케이프해야 합니다(中 → %E4%B8%AD). 최신 브라우저는 주소창에 유니코드 형태를 표시하지만 전송 시에는 인코딩된 형태를 보냅니다. 페이지는 UTF-8 인코딩 단계를 자동으로 처리합니다.
절대 인코딩하면 안 되는 문자는?
RFC 3986의 예약되지 않은 문자: A-Z, a-z, 0-9, -, _, ., ~. 이를 인코딩하는 것은 기술적으로 허용되지만 다른 URL 문자열이 만들어집니다. 정규화 규칙에 따라 서버는 'a'와 '%61'을 동등하게 취급하거나 다르게 취급할 수 있습니다.
왜 디코딩한 URL에 이상한 문자가 있나요?
이중 인코딩되었을 가능성이 높습니다: %2520은 %20으로 디코딩되고, 다시 공백으로 디코딩됩니다 — 누군가가 URL을 두 번 인코딩했다는 뜻입니다. 그런 경우에는 두 번 디코딩하세요. 일부 서버는 자동으로 이중 인코딩하니, 클라이언트의 인코딩 동작을 확인하세요.
인코딩은 로컬에서 이루어지나요?
네. encodeURIComponent와 decodeURIComponent는 브라우저에서 실행됩니다. URL은 업로드되지 않습니다.