URL 인코딩과 디코딩 - 특수문자 처리 방법
RFC 3986 기준의 URL 퍼센트 인코딩 원리와 한글 URL 처리, encodeURIComponent vs encodeURI 차이, 최대 URL 길이 제한을 사례별로 설명합니다.
Q.URL에서 한글이 %로 시작하는 코드로 바뀌는 이유는 무엇인가요?
URL은 ASCII 문자만 안전하게 전송할 수 있습니다. 한글처럼 ASCII 범위 밖의 문자는 UTF-8로 인코딩한 뒤 각 바이트를 %XX 형식으로 변환하는 '퍼센트 인코딩'을 적용합니다. '한글'은 %ED%95%9C%EA%B8%80으로 인코딩됩니다.
한국어 검색어를 URL로 복사하면 알아볼 수 없는 "%EC%95%88%EB%85%95%ED%95%98%EC%84%B8%EC%9A%94" 같은 문자열로 바뀐다. 이것이 URL 퍼센트 인코딩이다. 사용자가 겪는 링크 오류, 폼 전송 실패, 검색 파라미터 손상 중 상당수가 이 인코딩을 올바르게 처리하지 않은 데서 발생한다.
URL 퍼센트 인코딩 원리
RFC 3986(URI 표준)에 따르면 URL에 사용할 수 있는 문자는:
- Unreserved characters: A-Z, a-z, 0-9, -, _, ., ~
- Reserved characters: 구분자 역할을 하는 18개 문자
Reserved 문자 목록: : / ? # [ ] @ ! $ & ' ( ) + , ; =
이 범위 밖의 문자(한글, 일본어, 특수 기호 등)는 퍼센트 인코딩으로 변환해야 한다.
한글 URL 인코딩 과정
한글 "안녕"이 URL에서 변환되는 과정:
- UTF-8 인코딩:
안→EC 95 88,녕→EB 85 95 - 퍼센트 인코딩: 각 바이트 앞에
%추가 - 결과:
%EC%95%88%EB%85%95
현대 브라우저는 주소창에 한글을 입력해도 내부적으로는 인코딩된 URL을 사용한다. 화면에는 한글로 표시되지만 실제 전송되는 값은 인코딩된 형태다.
공백 처리 - %20 vs +
공백을 인코딩하는 방법이 두 가지라는 점이 자주 혼란을 일으킨다.
| 방식 | 사용 맥락 |
|---|---|
| %20 | URL 경로, 쿼리스트링 일반 |
| + | HTML form 데이터 (application/x-www-form-urlencoded) |
검색 URL에서 ?q=안녕+세상 처럼 +가 쓰인 것은 form 데이터 인코딩 방식이다. 일반 URL에서는 %20을 사용한다.
encodeURI vs encodeURIComponent
JavaScript의 두 함수는 인코딩 범위가 다르다.
javascript
encodeURI("https://example.com/검색?q=안녕")
// https://example.com/%EA%B2%80%EC%83%89?q=%EC%95%88%EB%85%95
// 예약 문자(://?=)는 인코딩하지 않음
encodeURIComponent("안녕 세상")
// %EC%95%88%EB%85%95%20%EC%84%B8%EC%83%81
// 공백, 예약 문자 모두 인코딩
- URL 전체를 인코딩:
encodeURI - 파라미터 값만 인코딩:
encodeURIComponent
URL 최대 길이 제한
| 환경 | 최대 길이 |
|---|---|
| Chrome | 약 2MB |
| Internet Explorer | 2,083자 |
| Apache 서버 기본값 | 8,190바이트 |
| Nginx 기본값 | 4,096바이트 |
한글 URL은 인코딩 후 글자당 9바이트(3바이트 UTF-8 × 3자리 %XX)가 되므로 서버 설정의 URL 길이 제한을 쉽게 초과할 수 있다.
다음 단계
URL 인코딩 처리는 서버·클라이언트 양쪽에서 일관되게 적용해야 한다. 다음으로 HTML 엔티티 인코딩과의 차이를 이해하면 웹 보안의 두 가지 핵심 계층을 모두 다룰 수 있다.
---
이 글은 AI가 공개 자료를 기반으로 작성했습니다. 인코딩 구현 시 사용하는 언어와 프레임워크의 공식 문서를 함께 확인하세요.*