일반 텍스트

퍼센트 인코딩됨

URL 인코더란?

왼쪽 패널에 문자열을 넣으면 오른쪽 패널이 퍼센트 인코딩된 버전을 보여줍니다. 내부적으로 encodeURIComponent를 실행하는데, 이 함수는 URL에서 특별한 의미를 가지는 모든 문자를 이스케이프합니다 — 공백은 %20이 되고, 앰퍼샌드는 %26이 되고, @ 기호는 %40이 되는 식입니다. 쿼리 파라미터의 「값」, 경로 세그먼트, 그리고 원시 문자열을 URL 안에 끼워 넣어도 깨지지 않게 해야 하는 모든 곳에서 필요한 인코딩이 바로 이것입니다.

인코딩에는 두 가지 종류가 있고 그 차이가 중요합니다. encodeURIComponent(이 페이지)는 ?, #, &, =, /를 포함해 특별한 문자를 모두 이스케이프합니다 — 값 수준에서 그 문자들이 URL의 의미를 바꿔버리기 때문입니다. encodeURI는 더 관대해서 그런 구조적 문자는 그대로 둡니다. 이미 완성된 URL 전체를 인코딩하는 상황을 가정하기 때문입니다. 자세한 표가 필요하면 MDN이 예약 문자 표를 정리해뒀습니다. 부품들로 URL 전체를 만들고 있다면, 이 페이지가 아니라 URL Builder가 필요합니다.

실제 인코딩 규칙은 RFC 3986 §2.1에서 옵니다: 안전하지 않은 각 바이트는 % 다음에 UTF-8 바이트의 16진수 두 자리로 적습니다. 그래서 로켓 같은 이모지는 퍼센트 트리플이 네 개 나옵니다(UTF-8 4바이트라서요). 반면 ! 같은 ASCII는 한 개로 끝납니다. WHATWG URL 표준이 모던 브라우저의 동작을 정형화하고 있고, 손으로 대조해 보고 싶다면 위키백과의 퍼센트 인코딩 항목에 깔끔한 참조 표가 있습니다. 모든 것은 브라우저 안에서 일어납니다. 업로드도, 로그도 없습니다.

URL 인코더 사용법

세 단계. 입력하는 동안 페이지가 갱신됩니다 — 변환 버튼은 없습니다.

문자열을 붙여넣거나 샘플 클릭

왼쪽 패널에 아무 텍스트나 입력하거나 붙여넣으세요. 샘플을 클릭하면 실제로 마주치는 종류의 문자가 들어간 문자열이 로드됩니다 — 공백, 앰퍼샌드, 이메일, 퍼센트 기호 등. 입력 예시:

Ava Chen & friends? [email protected]  100% off!

유니코드와 이모지도 잘 작동합니다 — 인코더가 UTF-8 바이트 시퀀스를 사용하기 때문에, 한국어 이름이나 이모지는 멀티바이트 퍼센트 시퀀스로 인코딩되고 표준을 준수하는 디코더를 통해 깔끔하게 왕복합니다.

인코딩된 출력 확인

오른쪽 패널이 퍼센트 인코딩된 버전을 보여줍니다. 공백은 %20으로, &는 %26으로, ?는 %3F로, @는 %40으로, % 자체는 %25로 변환됩니다. 입력하는 동안 갱신됩니다.

복사 또는 다운로드

복사를 클릭하면 인코딩된 문자열이 클립보드에 들어가고, 다운로드를 누르면 .txt 파일로 저장됩니다. 처음부터 다시 시작하려면 입력 패널의 지우기를 사용하세요. 반대 방향으로 가려면 URL 디코더로 넘어가세요.

실제로 이런 때 씁니다

쿼리 문자열 값을 손으로 만들 때

빠른 curl 테스트나 딥링크용으로 ?customer=Ava%20Chen&status=active를 만들어야 하나요? 각 값을 여기서 인코딩한 뒤 URL에 붙여 넣으면 됩니다. &가 들어간 값(「Smith & Co.」 같은 고객명)을 인코딩하지 않는 것이 「API가 내 파라미터의 절반밖에 못 본다」는 미스터리한 버그의 고전적 원인입니다.

리다이렉트 대상 URL 인코딩

OAuth 흐름과 SSO 리다이렉트는 목적지 URL을 쿼리 파라미터(예: ?return_to=...) 안에 넣어 전달합니다. 그 목적지 URL 자체에 :, /, ?, &가 들어 있고, 외부 URL이 형식을 유지하려면 그 모두가 퍼센트 인코딩되어야 합니다. RFC 6749 §3.1.2가 OAuth 리다이렉트 URI에 대해 이를 명시적으로 다룹니다.

슬래시가 들어간 경로 세그먼트 인코딩

REST API에 /repos/:owner/:name 같은 라우트가 있고 이름에 슬래시가 들어 있는 경우(드물지만 일부 카탈로그에서는 합법), 슬래시를 %2F로 인코딩하지 않으면 라우터가 경로 구분자로 처리해버립니다. 다운로드 URL의 공백이나 악센트가 있는 파일명에도 같은 논리가 적용됩니다.

URL에 닿기 전에 사용자 입력 정제하기

HTML 폼, 검색 박스, CSV 임포트에서 URL로 들어가는 문자열은 인코딩이 필요합니다. 인코딩되지 않은 사용자 입력이 바로 깨진 링크, 파라미터 인젝션 벡터, ASCII 사용자에게는 작동하지만 다른 사람들에게는 조용히 실패하는 URL의 원인입니다. OWASP의 경로 순회 노트는 이 단계를 건너뛰는 비용을 잘 상기시켜 줍니다.

자주 묻는 질문

encodeURIComponent를 써야 하나요, encodeURI를 써야 하나요?

거의 항상 encodeURIComponent입니다 — 이 페이지가 쓰는 게 그것입니다. 쿼리 파라미터 값, 경로 세그먼트, 그리고 문자열이 URL의 「조각」이어야 하는 모든 곳에서 옳은 선택입니다. encodeURI는 이미 구조적으로 완성된 URL을 인코딩하기 위한 것입니다(실무에서는 드뭅니다 — 보통 부품에서 만들기 때문에). 위에 링크된 MDN 레퍼런스에 각각이 어떤 문자를 이스케이프하는지 전체 표가 있습니다.

왜 공백이 어떨 때는 +이고 어떨 때는 %20인가요?

두 가지 인코딩 전통이 나란히 존재합니다. application/x-www-form-urlencoded(HTML 폼 제출의 ?key=value 본문)는 공백에 +를 씁니다. RFC 3986의 일반 URL 퍼센트 인코딩은 %20을 씁니다. encodeURIComponent는 항상 %20을 만듭니다. 대부분의 서버는 둘 다 받지만, 다운스트림 디코더가 폼-엄격이라면 인코딩 후에 .replace(/%20/g, "+")로 바꿔주세요.

이모지와 비ASCII 텍스트도 제대로 처리하나요?

네. 인코더가 입력을 먼저 UTF-8로 직렬화한 다음 각 바이트를 퍼센트 인코딩합니다. 그래서 이모지는 멀티바이트 퍼센트 시퀀스가 되고, 표준을 준수하는 어떤 디코더라도 그것을 다시 왕복시킵니다. Latin-1이나 다른 레거시 인코딩을 쓰는 시스템과 통합 중이라면 다른 문제가 있는 것입니다 — 업스트림 시스템을 바꿔야지, 비-UTF-8 인코더를 직접 만들지 마세요.

encodeURIComponent가 인코딩하지 않는 문자는?

문자 A-Z와 a-z, 숫자 0-9, 그리고 비예약 문자 - _ . ! ~ * ' ( )입니다. 나머지는 모두 퍼센트 인코딩됩니다. 이 목록은 원래 명세에서 그대로 왔고, 모든 모던 자바스크립트 엔진에서 고정입니다 — 정확한 출처가 필요하면 ECMAScript의 encodeURIComponent 명세를 보세요.

여기에 붙여넣은 입력이 어딘가로 전송되나요?

아니요. 인코딩은 자바스크립트 엔진을 통해 완전히 브라우저 안에서 실행됩니다. 네트워크 호출, 서버, 로그가 없습니다. 비밀, 토큰, 민감한 무엇이든 붙여넣어도 — 머신을 떠나지 않습니다.

여기서 인코딩할 수 있는 문자열의 크기는?

입력에 256 KB 상한이 있습니다. 실제 URL 값은 잘해야 몇 킬로바이트입니다. 수 MB 데이터를 인코딩해야 한다면, 거의 확실히 본문을 POST해야 할 것을 URL에 임베드하려는 것입니다 — 서버 측에서 인코딩하고 왕복은 건너뛰세요.

다른 URL 및 인코딩 도구

인코딩은 한 가지 작업입니다. 자연스럽게 짝지어지는 도구들: