URL 인코딩: +와 %20, 한글 주소 처리 차이
검색어 “가방 + 파우치&색=초록”을 주소에 넣었는데 일부가 사라졌다면 문자를 URL 값으로 인코딩했는지 확인합니다. 주소 전체를 한꺼번에 인코딩하는 것과, 주소 안의 한 값을 인코딩하는 것은 다릅니다.
한 값을 구성요소로 인코딩합니다
쿼리 값에 들어간 &는 다음 항목의 시작으로 해석될 수 있습니다. +는 폼 방식에서 공백으로 읽힐 수 있습니다. 한글과 예약 문자를 값으로 전달하려면 구성요소에 맞게 인코딩해야 합니다. 아래 도구의 인코딩 기능은 encodeURIComponent 방식을 사용합니다.
원문: 가방 + 파우치&색=초록
값의 일부 예: 공백 → %20 / + → %2B / & → %26주소 전체에는 그대로 적용하지 않습니다
https://example.com/?q=... 전체를 구성요소 인코딩하면 콜론과 슬래시까지 바뀌어 일반 주소로 쓰기 어렵습니다. URL을 이루는 구조와 그 안의 데이터를 구분하세요. 여러 항목을 만드는 프로그램에서는 URLSearchParams 같은 API를 사용할 수 있지만, 출력의 공백 표기가 폼 규칙을 따를 수 있다는 점을 알아야 합니다.
+와 %20의 해석을 나눠 봅니다
decodeURIComponent는 +를 공백으로 바꾸지 않습니다. 반면 URLSearchParams처럼 폼 인코딩을 다루는 방식은 쿼리의 +를 공백으로 해석합니다. 실제 더하기 기호를 전달하려면 %2B로 표현해야 혼동을 줄일 수 있습니다. 아래 표의 결과를 각각 비교해 보세요.
| 입력 | 구성요소 디코딩 | 폼 쿼리 해석 |
|---|---|---|
| a+b | a+b | a b |
| a%20b | a b | a b |
| a%2Bb | a+b | a+b |
이미 인코딩된 값을 다시 인코딩하지 않습니다
공백을 표현한 %20을 다시 인코딩하면 퍼센트 문자가 %25가 되어 %2520이 됩니다. 수신자가 한 번만 디코딩하면 공백 대신 %20 문자열이 남습니다. 따라서 함수 입력이 원문인지, 이미 인코딩된 문자열인지 계약을 정해야 합니다. 눈에 %가 보인다는 이유로 무조건 여러 번 디코딩하면 실제 퍼센트 표기를 손상시킬 수 있습니다.
오류가 났을 때 원문을 보존합니다
% 뒤의 두 자리가 빠졌거나 올바른 바이트 시퀀스가 아니면 디코딩이 실패할 수 있습니다. 이 경우 %를 전부 삭제하지 말고 원래 값을 보낸 경로를 확인하세요. 도구는 한 번의 인코딩과 한 번의 구성요소 디코딩을 따로 표시합니다. 폼 방식 변환이나 주소 이동은 하지 않습니다. 결과를 실제 주소에 넣기 전 작은 가상 검색어로 왕복 결과가 같은지 확인하세요.
직접 확인하기
예제로 결과 확인
입력은 이 브라우저에서 처리되며 서버에 저장되지 않습니다. 비밀번호·개인정보 대신 예제나 사본을 사용하세요.
결과가 여기에 표시됩니다.
참고 자료와 확인 범위
아래 자료는 형식·기능의 정의를 확인하는 데 사용했습니다. 본문의 예제와 설명은 이 사이트의 작업 상황에 맞춰 구성했습니다. 제품 메뉴는 버전과 언어에 따라 다를 수 있습니다.
확인일: 2026-10-15 · 오류를 발견하면 이 글의 오류 신고로 알려주세요.