카카오톡으로 공유된 링크의 주소가 유난히 길고 복잡해 보인다면, 그 안에 한글 검색어나 게시글 제목이 그대로 인코딩되어 들어 있을 가능성이 크다 — URL을 분해해 보면 그 이유가 바로 드러난다.
URL의 주요 구성 요소
- 프로토콜 —
https://, 리소스에 연결하는 방법을 지정한다. - 호스트 —
example.co.kr, 서버의 도메인 이름. - 포트 — 선택 사항, HTTPS는 기본값 443.
- 경로 —
/게시판/공지사항, 한글을 포함할 수 있다. - 쿼리 문자열 —
?이후,utm_source등 광고 추적 매개변수가 흔히 붙는다. - 프래그먼트 —
#이후, 브라우저만 처리하고 서버로는 전달되지 않는다.
한글 한 글자가 URL에서 왜 이렇게 길어지는가
한글은 URL의 안전한 문자 집합에 포함되지 않기 때문에, 완성형 한 글자마다 먼저 여러 바이트의 UTF-8로 변환된 뒤 각 바이트가 %EA%B0%80 같은 형태로 다시 인코딩된다. 짧은 한글 단어 하나도 인코딩되면 원래 길이의 몇 배로 늘어나는 경우가 흔해서, 카카오톡이나 네이버 블로그에서 공유한 링크가 유난히 길게 보이는 원인이 된다.
네이버 지도·카카오맵 링크도 같은 구조를 따른다
https://map.naver.com/p/search/강남역?c=15.00,0,0,0,dh 같은 링크도 scheme-host-path-query 구조를 그대로 따르며, 검색어(장소명)는 경로에, 지도 확대 수준 같은 값은 쿼리 문자열에 들어간다. URL을 부분별로 나눠 보면 어떤 값이 실제 검색 장소이고 어떤 값이 지도 상태(줌 레벨, 좌표)인지 빠르게 구분할 수 있다.
왜 필요한가
- 디버깅이나 로깅을 위해 복잡한 URL을 구성 요소로 분해한다.
- 긴 인코딩 문자열을 읽을 수 있는 한글로 복원한다.
- 인코딩 오류 없이 프로그램으로 URL을 올바르게 생성한다.
userinfo를 이용한 피싱 수법
https://accounts.google.com@evil.com/ 같은 URL은 accounts.google.com으로 연결되는 것처럼 보이지만, 실제로 브라우저가 여는 곳은 evil.com이다 — @ 기호 앞의 부분은 그냥 사용자 이름(userinfo)일 뿐 호스트가 아니다. 그래서 최신 브라우저들은 실제 호스트를 시각적으로 강조하려 한다.