URL 인코딩(퍼센트 인코딩이라고도 함)은 RFC 3986에서 정의한 URL 내 데이터 전송 메커니즘입니다. URL에서 예약된 의미를 가지는 문자(예: ? / # & =)나 ASCII 인쇄 가능 범위 밖의 문자는 하나 이상의 %XX 세 개로 다시 작성됩니다. 여기서 XX는 바이트의 16진수 값입니다. 디코더는 바이트 단위로 역과정을 수행합니다.

퍼센트 인코딩은 전송 형식이지 보안 메커니즘이 아닙니다. 인코딩된 문자열을 받은 사람은 쉽게 디코드할 수 있습니다. 인코딩을 암호화나 해시와 혼동하지 마세요.

이 도구는 모든 개발자가 결국 마주치게 되는 세 가지 인코딩 모드를 제공합니다. 선택한 모드에 따라 인코딩되는 문자가 결정됩니다.

Component 모드 (encodeURIComponent). URL 내부에 삽입할 단일 값을 인코딩할 때 사용합니다. 쿼리 문자열 값, 경로 세그먼트, 프래그먼트 등에 적합합니다. URL 예약 문자를 모두 인코딩하여 어떤 슬롯에서든 안전하게 사용할 수 있습니다.

전체 URL 모드 (encodeURI). 이미 조립된 URL을 가지고 있고 실제로 안전하지 않은 문자(공백, 비ASCII)만 이스케이프하고 싶을 때 사용합니다. 구조적 문자(: / ? # & = +)를 그대로 두어 URL이 파싱 가능한 상태를 유지합니다.

Form 모드 (application/x-www-form-urlencoded). Content-Type이 application/x-www-form-urlencoded인 HTTP 요청 본문을 작성할 때 사용합니다. 공백이 +가 되고, 줄바꿈이 CRLF(%0D%0A)로 정규화되며, HTML 폼을 제출할 때 브라우저가 보내는 것과 동일한 문자 집합을 사용합니다.

안전한 쿼리 문자열 프로그래밍 방식 구축: /search?q=[value] 같은 URL을 직접 구성할 때, Component 모드로 값을 처리하면 값 내부의 &나 =가 주변 URL을 망가뜨리지 않습니다.

URL 내부에 URL 삽입: 한 URL을 다른 URL의 매개변수로 전달할 때(예: OAuth 리다이렉트 URL), 내부 URL을 Component 모드로 인코딩해야 합니다. 전체 URL 모드가 아닙니다. 그래야 내부 URL의 / : ? &이(가) 외부 URL의 구조로 오해받지 않습니다.

fetch로 폼 데이터 제출: Content-Type: application/x-www-form-urlencoded로 POST 본문을 보낼 때, 본문은 Form 모드 의미 체계로 인코딩되어야 합니다. 이 도구의 Form 모드는 브라우저가 보내는 것과 바이트 호환되는 출력을 생성합니다.

URL 인코딩은 암호화가 아닙니다. 누구나 함수 호출 한 번으로 출력을 디코드할 수 있습니다. 인코딩으로 비밀을 숨기지 마세요.

모드 선택이 중요합니다. 전체 URL을 Component 모드로 처리하면 URL이 망가집니다(모든 /가 %2F가 됨). 쿼리 값을 전체 URL 모드로 처리하면 예약 문자가 위험하게 남을 수 있습니다(값 내 &이 여전히 매개변수 구분자처럼 보임). 의심스러울 때는 Component를 선택하세요.