URL 인코딩/디코딩 도구

URL 인코딩(퍼센트 인코딩이라고도 함)은 문자를 URL에서 안전하게 전송할 수 있는 형식으로 변환하는 메커니즘입니다. URL은 ASCII 문자 집합의 특정 문자만 포함할 수 있으므로, 다른 문자(한글, 공백, 특수 기호 등)는 %XX 형식으로 인코딩해야 합니다. XX는 문자의 16진수 값입니다.

예: 공백은 %20으로, 한글 "한"은 %ED%95%9C으로 인코딩됩니다.

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로 호출을 래핑하고 조용히 빈 문자열을 반환하는 대신 오류 메시지를 표면화