본문으로 건너뛰기
yutils
예시

입력 (인코딩 모드)

안녕하세요 yutils!

출력

%EC%95%88%EB%85%95%ED%95%98%EC%84%B8%EC%9A%94%20yutils!

참고

한글은 UTF-8 3바이트로 인코딩되어 `%EC%95%88` 형태로 표현됩니다. `!` 같은 일부 예약문자도 안전을 위해 인코딩 — 디코드 시 원본 복원.

사용법 / 자주 묻는 질문

이런 경우 사용하세요

  • URL 쿼리 파라미터에 한글·공백·특수문자 넣기 (검색어 등)
  • API endpoint 경로에 한글 카테고리·이름을 안전하게 박기
  • 다른 사이트의 인코딩된 URL 디코딩해서 무엇을 가리키는지 보기
  • 리다이렉트 체인 분석 — `?redirect=` 같은 파라미터 내부 URL 디코드
  • 이메일 본문에 박힌 긴 URL 의 인코딩 상태 확인

자주 묻는 질문

Q.encodeURI 와 encodeURIComponent 차이는?
A.encodeURI 는 전체 URL 을 인코딩하므로 `:`, `/`, `?`, `#` 같은 reserved character 는 유지합니다. encodeURIComponent 는 쿼리 값처럼 부분 인코딩용 — `:`, `/` 도 인코딩. 본 도구는 component 기준입니다.
Q.space 는 `+` 인가 `%20` 인가?
A.URL path 에서는 `%20`, application/x-www-form-urlencoded body 에서는 `+` 가 표준입니다. 본 도구는 path 기준(`%20`) — form data 에서는 추가 보정 필요.
Q.이미 인코딩된 문자열을 또 인코딩하면?
A.`%20` 이 `%2520` 처럼 이중 인코딩됩니다. 디버깅 중 자주 만나는 함정 — 이미 인코딩됐는지 먼저 확인하세요.
재미있는 사실

  • URL 의 percent-encoding (`%20` 같은 형태) 은 1994년 Tim Berners-Lee 의 RFC 1738 가 정식화했고, 2005년 RFC 3986 이 현재 표준입니다. `%XX` 는 그 바이트의 16진 값 — 다국어가 늘면서 UTF-8 + percent-encoding 이 사실상 표준 조합이 됐습니다.

    RFC 3986 (2005)

  • RFC 3986 의 'unreserved' 집합 — `A-Z a-z 0-9 - _ . ~` — 이 4가지 문자만 encoding 없이 안전하게 박을 수 있습니다. 옛 RFC 1738 의 unreserved 가 더 넓었는데 (`+ - $ . , !` 포함) 호환성 문제로 좁혀졌어요.

    RFC 3986 — Unreserved Characters

  • 공백 처리에서 함정 — URL path 안에서는 `%20` 이지만, query string 의 `application/x-www-form-urlencoded` 인코딩에서는 `+` 로 박힙니다. `encodeURIComponent` 는 `%20` 만 쓰고, 폼 제출 시 브라우저가 `+` 로 따로 처리. 두 영역에서 다른 규칙이 30년째.

    WHATWG URL — Form encoding

관련 도구

이 카테고리 모든 도구 보기 →