URL 인코딩: 알아야 할 모든 것
· 12분 읽기
목차
URL 인코딩 이해하기
퍼센트 인코딩이라고도 알려진 URL 인코딩은 인터넷을 통한 안정적인 데이터 전송을 보장하는 기본 메커니즘입니다. URL에서 허용되지 않는 문자를 웹 브라우저, 서버 및 기타 인터넷 인프라에서 안전하게 전송하고 해석할 수 있는 형식으로 변환합니다.
기본적으로 URL 인코딩은 간단한 문제를 해결합니다. URL은 ASCII 문자 집합의 제한된 문자만 포함할 수 있습니다. 특수 기호, 공백 또는 비라틴 문자 등 이 집합 외부의 문자를 포함해야 하는 경우 보편적으로 인식되는 형식으로 인코딩해야 합니다.
인코딩 프로세스는 문제가 있는 문자를 퍼센트 기호(%)와 문자의 ASCII 또는 UTF-8 코드를 나타내는 두 개의 16진수 숫자로 대체합니다. 이를 통해 URL의 모든 구성 요소가 오해나 데이터 손실 없이 의도한 대로 정확하게 전송됩니다.
빠른 팁: 코드를 작성하지 않고도 URL 문자열을 즉시 인코딩하거나 디코딩하려면 URL 인코더 및 디코더 도구를 사용하세요.
URL 인코딩이 필요한 이유
URL 인코딩의 필요성은 인터넷의 원래 설계 제약과 RFC 3986에 정의된 URL 사양에서 비롯됩니다. URL은 다양한 시스템, 프로토콜 및 지역 간의 호환성을 보장하기 위해 제한된 문자 집합으로 작동하도록 설계되었습니다.
URL 인코딩이 없으면 몇 가지 중요한 문제가 발생합니다:
- URL 구조의 모호성:
?,&,#와 같은 특수 문자는 URL에서 특정 의미를 갖습니다. 이러한 문자가 인코딩 없이 데이터에 나타나면 콘텐츠가 아닌 URL 구분 기호로 해석됩니다. - 문자 집합 비호환성: 다른 시스템이 동일한 바이트 시퀀스를 다르게 해석하여 데이터 손상이나 요청 실패로 이어질 수 있습니다.
- 프로토콜 위반: HTTP 및 기타 인터넷 프로토콜은 URL이 특정 형식 규칙을 준수할 것으로 예상합니다. 인코딩되지 않은 문자는 프로토콜 오류를 일으킬 수 있습니다.
- 보안 취약점: 인코딩되지 않은 특수 문자는 인젝션 공격에 악용되거나 보안 필터를 우회하는 데 사용될 수 있습니다.
URL에서 "cats & dogs"에 대한 검색 쿼리를 고려해보세요. 인코딩이 없으면 앰퍼샌드가 매개변수 구분 기호로 해석되어 쿼리가 두 개의 별도 매개변수로 분할될 수 있습니다. URL 인코딩은 이를 cats%20%26%20dogs로 변환하여 의도한 의미를 보존합니다.
ASCII 제한
URL은 128개의 문자만 포함하는 ASCII 문자 집합을 기반으로 합니다. 이 중 "예약되지 않은 문자"로 알려진 하위 집합만 인코딩 없이 URL에 나타날 수 있습니다. 이러한 예약되지 않은 문자는 다음과 같습니다:
- 대문자 및 소문자(A-Z, a-z)
- 십진수 숫자(0-9)
- 하이픈(
-), 마침표(.), 밑줄(_) 및 물결표(~)
그 외의 모든 것은 인터넷을 통한 적절한 전송 및 해석을 보장하기 위해 인코딩이 필요합니다.
URL 인코딩 작동 방식
URL 인코딩 프로세스는 문자를 퍼센트 인코딩된 동등물로 변환하는 간단한 알고리즘을 따릅니다. 이 프로세스를 이해하면 인코딩 문제를 해결하고 더 강력한 웹 애플리케이션을 작성하는 데 도움이 됩니다.
인코딩 알고리즘
문자를 인코딩해야 하는 경우 프로세스는 다음과 같이 작동합니다:
- 문자 식별: URL 구성 요소 및 인코딩 규칙에 따라 인코딩이 필요한 문자를 결정합니다.
- 바이트 값 가져오기: UTF-8 인코딩(또는 기본 문자의 경우 ASCII)을 사용하여 문자를 바이트 표현으로 변환합니다.
- 16진수로 변환: 각 바이트를 두 개의 16진수 숫자로 표현합니다.
- 퍼센트 접두사 추가: 각 16진수 쌍 앞에 퍼센트 기호(
%)를 붙입니다.
예를 들어, 공백 문자의 ASCII 값은 32(십진수) 또는 20(16진수)입니다. 인코딩되면 %20이 됩니다. @ 기호(@)의 ASCII 값은 64(십진수) 또는 40(16진수)이므로 %40으로 인코딩됩니다.
UTF-8 멀티바이트 인코딩
ASCII 범위를 벗어난 문자의 경우 UTF-8 인코딩은 여러 바이트를 생성하며 각 바이트는 퍼센트 인코딩됩니다. 이모지 "😀"(웃는 얼굴)은 UTF-8에서 4바이트로 인코딩됩니다: F0 9F 98 80. URL에서는 %F0%9F%98%80이 됩니다.
이 멀티바이트 인코딩은 모든 언어나 기호 집합의 문자를 URL에서 안전하게 전송할 수 있도록 보장하여 웹을 진정으로 국제적으로 만듭니다.
전문가 팁: URL 인코딩 문제를 디버깅할 때 브라우저의 개발자 도구를 사용하여 전송되는 실제 인코딩된 URL을 검사하세요. 네트워크 탭은 원시 인코딩된 요청을 표시하여 인코딩 문제를 드러낼 수 있습니다.
인코딩이 필요한 문자
모든 문자가 모든 컨텍스트에서 인코딩이 필요한 것은 아니지만, 어떤 문자가 언제 인코딩이 필요한지 이해하는 것은 안정적인 웹 애플리케이션을 구축하는 데 필수적입니다. 인코딩 요구 사항은 작업 중인 URL의 어느 부분인지에 따라 다릅니다.
예약된 문자
예약된 문자는 URL 구문에서 특별한 의미를 가지며 구분 기호가 아닌 데이터로 사용될 때 인코딩되어야 합니다. 이러한 문자는 다음과 같습니다:
| 문자 | URL에서의 용도 | 인코딩된 형식 |
|---|---|---|
: |
스키마와 호스트 구분, 포트 구분 기호 | %3A |
/ |
경로 세그먼트 구분 기호 | %2F |
? |
쿼리 문자열 시작 표시 | %3F |
# |
프래그먼트 식별자 시작 표시 | %23 |
[ ] |
IPv6 주소 구분 기호 | %5B %5D |
@ |
자격 증명과 호스트 구분 | %40 |
! $ & ' ( ) * + , ; = |
다양한 용도의 하위 구분 기호 | %21 %24 %26 %27 %28 %29 %2A %2B %2C %3B %3D |
안전하지 않은 문자
특정 문자는 전송 중에 수정되거나 잘못 해석될 수 있기 때문에 안전하지 않은 것으로 간주됩니다. 이러한 문자는 항상 인코딩이 필요합니다:
| 문자 | 안전하지 않은 이유 | 인코딩된 형식 |
|---|---|---|
| 공백 | 제거되거나 +로 변환될 수 있음 |
%20 |
" |
HTML에서 URL을 구분하는 데 사용됨 | %22 |
< > |
HTML 태그에 사용되며 필터링될 수 있음 | %3C %3E |
% |
인코딩 구분 기호 자체 | %25 |
\ |
일부 시스템에서 경로 구분 기호 | %5C |
^ ` { } | |
보편적으로 지원되지 않음 | %5E %60 %7B %7D %7C |
컨텍스트 종속 인코딩
인코딩 요구 사항은 작업 중인 URL 구성 요소에 따라 다릅니다. 한 컨텍스트에서 안전한 문자가 다른 컨텍스트에서는 인코딩이 필요할 수 있습니다:
- 경로 세그먼트: 슬래시는 경로 세그먼트를 구분하므로 세그먼트 이름 자체의 일부가 아닌 한 인코딩해서는 안 됩니다.
- 쿼리 매개변수: 앰퍼샌드와 등호는 특별한 의미를 가지므로 매개변수 값에 나타날 때 인코딩되어야 합니다.
- 프래그먼트 식별자: 대부분의 문자가 허용되지만 일관성을 위해 인코딩이 권장됩니다.
URL 인코딩의 일반적인 사용 사례
URL 인코딩은 수많은 실제 시나리오에서 나타납니다. 이러한 사용 사례를 이해하면 자신의 프로젝트에서 인코딩을 언제 어떻게 적용해야 하는지 인식하는 데 도움이 됩니다.
검색 쿼리
검색 엔진은 사용자 쿼리를 처리하기 위해 URL 인코딩에 크게 의존합니다. Google에서 "how to bake a cake?"를 검색하면 URL은 다음과 같이 됩니다:
https://www.google.com/search?q=how+to+bake+a+cake%3F공백은 더하기 기호(쿼리 문자열에서 공백의 대체 인코딩)로 인코딩되고 물음표는 쿼리 문자열 구분 기호와 구별하기 위해 %3F로 인코딩됩니다.
양식 제출
HTML 양식이 GET 메서드를 사용하여 제출되면 양식 데이터가 인코딩되어 URL에 추가됩니다. 사용자 이름과 비밀번호 필드가 있는 로그인 양식을 고려해보세요:
https://example.com/login?username=john.doe%40example.com&password=P%40ssw0rd%21이메일 주소와 비밀번호의 특수 문자는 해석 문제를 방지하기 위해 적절하게 인코딩됩니다.
보안 참고: URL 매개변수에 비밀번호와 같은 민감한 데이터를 절대 보내지 마세요. 이 예제는 설명용일 뿐입니다. 인증에는 항상 HTTPS와 함께 POST 요청을 사용하세요.
API 요청
RESTful API는 종종 인코딩이 필요한 매개변수를 URL에 포함합니다. 결과를 필터링하거나 복잡한 데이터 구조를 전달할 때 적절한 인코딩은 API가 의도한 대로 정확히 수신하도록 보장합니다:
https://api.example.com/users?filter=created_at>2024-01-01&sort=-name필터 매개변수의 보다 큼 기호는 HTML 엔티티나 다른 해석과의 혼동을 방지하기 위해 %3E로 인코딩되어야 합니다.
파일 다운로드
ASCII가 아닌 이름의 파일을 제공할 때 URL 인코딩은 파일 이름이 올바르게 전송되도록 보장합니다:
https://example.com/downloads/Pr%C3%A9sentation%202024.pdf"Présentation"의 악센트가 있는 "é"는 %C3%A9(UTF-8 표현)로 인코딩되어 전 세계 사용자가 시스템의 문자 인코딩에 관계없이 파일을 다운로드할 수 있습니다.
소셜 미디어 공유
소셜 미디어 플랫폼은 미리 채워진 텍스트가 있는 링크를 공유할 때 URL 인코딩을 사용합니다. 트위터 공유 링크는 다음과 같을 수 있습니다:
https://twitter.com/intent/tweet?text=Check%20out%20this%20article%21&url=https%3A%2F%2Fexample.com%2Farticle트윗 텍스트와 공유되는 URL이 모두 인코딩되어