URL 인코더/디코더
URL을 인코딩하고 디코딩합니다.
유효하지 않은 URL
Tips
- 일본어 문자「あ」는 UTF-8로 인코딩하면
%E3%81%82가 됩니다. - 공백은 URL 경로에서는
%20으로, 쿼리 파라미터에서는+로 변환될 수 있습니다(RFC 3986과 HTML 폼 사양의 차이). ?,&,=등의 예약 문자를 파라미터 값으로 사용할 때는 인코딩이 필요합니다.- REST API 쿼리 파라미터에 비ASCII 문자를 포함하거나 리다이렉트 URL을 안전하게 전달할 때 유용합니다.
자주 묻는 질문
인코딩은 공백이나 비ASCII 문자를 URL에서 안전하게 사용할 수 있는
%XX 16진수 형식으로 변환하는 과정입니다. 디코딩은 그 반대 과정으로 원래의 읽기 쉬운 텍스트로 복원합니다.URL 경로 부분에는
%20을 사용합니다(RFC 3986 표준). +는 HTML 폼 데이터의 application/x-www-form-urlencoded 쿼리 문자열에서만 사용합니다. 확실하지 않은 경우 %20이 더 안전한 선택입니다.비예약 문자인 영문자(A–Z, a–z), 숫자(0–9), 그리고
- _ . ~ 기호는 인코딩 없이 URL에 사용할 수 있습니다. &나 =와 같은 예약 문자는 파라미터 값으로 사용할 때 반드시 인코딩해야 합니다.
여담 ― URL의 탄생: Tim Berners-Lee와 World Wide Web의 여명
URL은 1991년 World Wide Web의 발명자 Tim Berners-Lee가 설계했습니다. 처음에는 ASCII 문자만 가정하여 설계되었기 때문에, 일본어와 같은 멀티바이트 문자나 특수 문자는 퍼센트 인코딩으로 표현해야 합니다.
인터넷 최초의 웹 페이지 URL인 http://info.cern.ch/hypertext/WWW/TheProject.html은 지금도 접근 가능합니다. 이모지 도메인(예: 🍕.ws)도 기술적으로 가능하며, 내부적으로 Punycode(xn-- 형식) 형태로 변환됩니다. URL은 이론적으로 2,000자 이상도 가능하지만, 실용상 브라우저와 서버의 제한(약 2,048자)이 있습니다.
RFC 3986에서 URL 사양이 정의되어 있지만, "%20(공백)"과 "+(공백)"의 구분은 지금도 자주 혼란의 원인이 됩니다. %20은 URI 표준이며, +는 HTML 폼의 application/x-www-form-urlencoded 형식에서 사용됩니다. 용도에 따라 구분이 필요합니다.