URL이 왜 깨졌는지 (그리고 고치는 법)

이메일에 URL을 붙여넣어. 누가 클릭해. 404가 나와.

URL이 괜찮아 보였어. 하지만 브라우저와 그들 사이 어딘가에서 공백이 %20이 되거나, 앰퍼샌드가 사라지거나, 플러스 기호가 완전히 다른 뭔가로 바뀌었어.

URL 인코딩은 URL이 특정 문자만 포함할 수 있기 때문에 존재해. 나머지는 번역이 필요해.

특수 문자의 문제

URL은 제한된 문자 세트로 초기 인터넷 시절에 설계됐어. 안전한 건:

A-Z a-z 0-9 - _ . ~

나머지? 잠재적으로 문제.

공백은 맥락에 따라 %20이나 +가 돼. 리터럴 공백이 있는 URL은 깨져.

앰퍼샌드 (&)는 쿼리 파라미터를 구분해. 데이터에 앰퍼샌드가 있으면 URL 파서는 새 파라미터를 시작한다고 생각해.

물음표 (?)는 쿼리 문자열의 시작을 알려. 데이터에 하나 있으면 모든 걸 혼란스럽게 해.

인코딩이 자동으로 일어날 때

브라우저는 타이핑할 때 URL을 인코딩해. 그래서 구글에 "new york restaurants"를 붙여넣으면 작동하는 거야.

하지만 자동화된 시스템은 종종 안 해. API, 스크립트, 이메일 클라이언트—정확히 작성된 대로 URL을 전달할 수 있어. 안전하지 않은 문자를 포함하면 깨져.

이중 인코딩 함정

짜증나는 부분이 여기야.

URL을 인코딩해. 그다음 파라미터로 다른 URL에 넣어. 시스템이 다시 인코딩해. 이제 %20이 %2520이 돼.

디코딩하면 공백 대신 %20을 받아.

이건 리다이렉트 URL, 추적 파라미터, OAuth 콜백에서 지속적으로 일어나. URL이 추가 퍼센트 기호로 뭉개져 보이면 이중 인코딩 확인해.

흔한 인코딩 실수

전체 URL 인코딩. 하지 마. 값만 인코딩하고, 구조는 안 해. https://가 https%3A%2F%2F가 되면 안 돼.

플러스 기호 잊기. 쿼리 문자열에서 +는 공백을 의미해. 데이터에 리터럴 플러스 기호가 있으면 인코딩이 필요하거나 사라져.

인코딩이 멱등이라고 가정. 이미 인코딩된 문자열을 인코딩하면 다른 출력을 만들어. 인코딩 전에 뭔가 인코딩됐는지 확인해.

실전 예제

공백이 있는 검색 쿼리:

전: https://example.com/search?q=new york pizza
후:  https://example.com/search?q=new%20york%20pizza

파라미터로서의 콜백 URL:

callback = https://mysite.com/auth?token=abc
인코딩:   https%3A%2F%2Fmysite.com%2Fauth%3Ftoken%3Dabc

URL의 이메일 주소:

전: user+tag@example.com
후:  user%2Btag%40example.com

URL 문제 디버깅

실제 요청 확인. 브라우저 개발자 도구가 뭐가 전송되는지 보여줘. 예상과 비교해.

디코딩하고 검사. URL이 작동 안 하면 디코딩해서 서버가 실제로 뭘 받는지 봐.

특수 문자로 테스트. 테스트 데이터에 공백, 앰퍼샌드, 플러스 기호 포함해. "test"로 작동하지만 "test & verify"로 실패하면 인코딩 문제가 있어.

---

URL 인코딩은 보이지 않게 작동하는 것 중 하나인데 안 될 때까지야. 규칙을 이해하면 URL이 신비롭게 깨질 때 더 빨리 디버깅할 수 있어.