URL 인코딩이란 무엇인가요?

URL에 인코딩이 필요한 이유

RFC 3986은 URL에 쓸 수 있는 문자를 소수의 ASCII 문자로 제한하며, 그중 일부는 맡은 역할이 있습니다. ?는 쿼리의 시작, &는 매개변수 구분, =는 이름과 값의 구분, #는 프래그먼트의 시작, /는 경로 구분입니다. 값에 이런 문자가 들어가면 URL의 의미가 모호해집니다.

"salt & pepper"를 검색한다고 해 봅시다. ?q=salt & pepper처럼 그대로 쓰면 서버는 값이 salt 인 매개변수 q와, pepper라는 이름의 빈 매개변수를 하나 더 받습니다. ?q=salt%20%26%20pepper로 인코딩하면 하나의 값으로 도착합니다.

어떤 문자를 인코딩할까

인코딩은 문자가 아니라 바이트 단위로 이루어집니다. ASCII가 아닌 텍스트는 먼저 UTF-8로 변환되고, 각 바이트가 하나의 %XX 묶음이 됩니다.

16진수는 대소문자를 구분하지 않으므로 %c3%a9와 %C3%A9는 같은 뜻이지만, RFC 3986은 일관성을 위해 대문자를 권장합니다.

%20과 +: 공백에 대한 두 가지 규칙

RFC 3986이 정의한 퍼센트 인코딩은 공백을 항상 %20으로 씁니다. HTML 양식 전송은 이와 비슷한 application/x-www-form-urlencoded 형식을 쓰는데, 여기서는 공백이 +가 되고 실제 더하기 기호는 %2B가 됩니다.

• /files/my report.pdf 같은 경로에는 %20을 쓰세요. 경로의 +는 그냥 더하기 기호입니다.
• 쿼리 문자열에서는 양식 인코딩을 해석하는 서버가 +를 공백으로 읽습니다. %20은 두 규칙 모두에서 이해되므로 확실하지 않을 때 더 안전합니다.
• +84 같은 전화번호처럼 값에 실제 +가 들어갈 수 있다면 %2B로 보내야 합니다. 그렇지 않으면 공백으로 도착합니다.

JavaScript의 encodeURIComponent와 encodeURI

encodeURIComponent("a b&c")는 a%20b%26c를 반환하지만, encodeURI("a b&c")는 &를 구분자로 간주해 a%20b&c를 반환합니다. 흔한 버그는 매개변수 값에 encodeURI를 호출해 &, =, #가 그대로 통과하면서 값이 쪼개지는 경우입니다.

new URLSearchParams({ q: "a b&c" }).toString()은 q=a+b%26c를 만듭니다. 표준 서버에서는 두 형식 모두 같은 값으로 디코딩됩니다.

흔한 실수

1. 이중 인코딩: 이미 인코딩된 텍스트를 다시 인코딩하면 % 자체가 %25로 인코딩되어 %20이 %2520이 됩니다. 각 값은 URL에 넣는 시점에 정확히 한 번만 인코딩하세요.
2. 컴포넌트용 함수로 URL 전체를 인코딩: https://가 https%3A%2F%2F가 되어 링크가 더 이상 동작하지 않습니다.
3. 라우팅 전에 디코딩: 경로를 매칭하기 전에 %2F를 /로 디코딩하는 서버는 다른 경로를 읽도록 속을 수 있습니다.
4. 구식 문자 집합 가정: 일부 오래된 시스템은 "é"를 %E9(Latin-1)로 인코딩했습니다. 최신 브라우저와 WHATWG URL Standard는 UTF-8을 씁니다.