URL 인코딩의 필요성
URL 인코딩은 웹이 처음 설계될 때부터 중요한 역할을 해왔습니다. 1990년대 초, 전 세계 어디서든 정보를 찾을 수 있는 월드 와이드 웹(WWW)이 등장하면서, 정보를 식별하기 위한 표준 주소 체계인 URL(Uniform Resource Locator)이 함께 탄생했습니다. 이 URL 체계는
ASCII 문자 집합
을 기반으로 만들어졌고, 이에 따라 다양한 문자나 특수문자를 안전하게 다루기 위한 인코딩 방식이 필요해졌습니다.1. URL은 ASCII 문자만 허용
URL은 인터넷 표준인 ASCII 문자 집합만 사용할 수 있습니다. 하지만 한글, 공백, 특수문자(예: @, &, #, =, ?, /) 등은 ASCII에 포함되지 않거나 특별한 의미를 갖고 있어 그대로 쓰면 문제가 발생합니다.
예시)
한글 "안녕"은 ASCII가 아니므로 URL에서 사용할 수 없습니다. 이 경우 URL 인코딩을 통해 "안녕"을 "%EC%95%88%EB%85%95"로 변환해야 합니다.
예시)
https://example.com/search?query=안녕
한글 "안녕"은 ASCII가 아니므로 URL에서 사용할 수 없습니다. 이 경우 URL 인코딩을 통해 "안녕"을 "%EC%95%88%EB%85%95"로 변환해야 합니다.
2. 특수 문자의 의미 혼동 방지
URL에서 특정 문자는 구문 해석 용도로 사용됩니다.
이런 문자가 데이터 안에 포함돼 있다면 브라우저가 오해할 수 있어 인코딩이 필요합니다. 예를 들어, 검색어에 `&`가 포함되면 두 개의 파라미터로 잘못 인식될 수 있습니다.
문자 | 의미 |
---|---|
? | 쿼리 파라미터 시작 |
& | 여러 파라미터 구분 |
= | 키와 값 구분 |
/ | 경로 구분 |
# | 앵커(페이지 내 위치) 지정 |
이런 문자가 데이터 안에 포함돼 있다면 브라우저가 오해할 수 있어 인코딩이 필요합니다. 예를 들어, 검색어에 `&`가 포함되면 두 개의 파라미터로 잘못 인식될 수 있습니다.
3. 데이터의 안정한 전송
웹에서 데이터를 주고받을 때는 프로토콜이 엄격한 형식을 요구합니다. 따라서 문제가 될 수 있는 문자는
이러한 방식은 1994년 발표된 표준 문서인 RFC 1738 - Uniform Resource Locators (URL)에서 처음 정의되었으며, 이후 모든 웹 시스템의 기본 동작이 되었습니다.
%XX
형태의 16진수 이스케이프 시퀀스로 바꿔 전송하고, 서버는 이를 다시 디코딩하여 원래 데이터를 복원합니다.이러한 방식은 1994년 발표된 표준 문서인 RFC 1738 - Uniform Resource Locators (URL)에서 처음 정의되었으며, 이후 모든 웹 시스템의 기본 동작이 되었습니다.
참고자료: 현대 웹의 URL 인코딩 해석
이후 URL/URI 스펙은 더욱 확장되어 RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax에서 다양한 문자 처리와 예약 문자 정의가 보완되었습니다. 실제 브라우저에서는 WHATWG URL 표준을 기반으로 URL을 해석하며, JavaScript에서는 encodeURIComponent()같은 함수로 URL-safe 문자열을 만들 수 있습니다.