퍼센트 인코딩됨

디코딩된 텍스트

URL 디코더란?

왼쪽 패널에 퍼센트 인코딩된 문자열을 붙여넣으면 오른쪽 패널에 원본이 표시됩니다. 내부적으로는 decodeURIComponent를 실행해, 입력의 각 %XX 시퀀스를 따라가며 그 16진 쌍을 UTF-8 바이트로 처리하고 원래 문자를 재구성합니다. 그래서 %20은 공백이 되고, %26은 &가 되고, %E2%9C%85는 체크마크가 됩니다. 반대 방향은 URL 인코더에 있습니다.

디코딩이 까다로운 이유는? 야생의 모든 %가 유효한 퍼센트 인코딩 시퀀스의 일부는 아니기 때문입니다. 16진수가 아닌 문자가 뒤에 오는 단독 %(%G1, 문자열 끝의 %)는 형식이 잘못되었으며 디코더는 URIError: URI malformed를 던집니다. 이 페이지는 그것을 잡아 스택 트레이스 대신 친근한 "잘못된 인코딩" 메시지를 보여주므로, 손상된 붙여넣기로 페이지가 깨지지 않습니다. 무엇이 유효한지에 대한 정확한 규칙은 RFC 3986 §2.1과 WHATWG URL 표준에 있습니다.

이중 인코딩에 주의하세요. 문자열을 디코딩했는데 출력에 여전히 % 문자가 들어 있다면(예: Ava Chen 대신 Ava%2520Chen이 돌아왔다면), 그 값은 체인 어딘가에서 두 번 인코딩되었습니다 — 보통 이미 인코딩된 값을 자동 인코딩한 프록시나 프레임워크 때문입니다. 다시 디코딩하면 나머지 길을 갈 수 있습니다. 위키피디아의 이중 인코딩 노트는 이게 어떻게 일어나는지 잘 설명합니다. 모든 것이 브라우저에서 실행됩니다. 업로드, 서버, 로그 없습니다.

URL 디코더 사용법

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

인코딩된 문자열을 붙여넣거나 샘플 클릭

왼쪽 패널에 퍼센트 인코딩된 문자열을 떨어뜨리세요. 샘플을 클릭하면 현실적인 예제를 불러옵니다. 입력 예:

Ava%20Chen%20%26%20friends%3F%20customer%40shop.com%20%20100%25%20off!

잘못된 형식의 입력(단독 <code>%</code>, <code>%G1</code> 같은 잘못된 16진 쌍)은 출력 패널에 "잘못된 인코딩" 메시지로 나타납니다 — 정확한 실패 규칙은 <a href="https://tc39.es/ecma262/#sec-decodeuricomponent-encodeduricomponent" target="_blank" rel="noopener">decodeURIComponent의 ECMAScript 명세</a>를 참조하세요.

디코딩 결과 읽기

오른쪽 패널에 디코딩된 텍스트가 표시됩니다. %20은 공백, %26은 &, %3F는 ?, %40은 @, %25는 %가 됩니다. 입력 중에 갱신됩니다.

복사 또는 다운로드

복사를 클릭해 디코딩된 텍스트를 클립보드에 넣거나, 다운로드로 .txt 파일로 저장하세요. 입력 패널의 지우기로 다시 시작할 수 있습니다. 반대 방향으로 가려면 URL 인코더로 건너뛰세요.

실제로 이걸 쓰게 되는 순간

쿼리 파라미터에 실제로 뭐가 들어 있는지 읽기

?customer=Ava%20Chen&tag%5B0%5D=red 같은 URL은 퍼센트 코드가 그대로 있으면 훑어보기 어렵습니다. 여기 값 하나만 붙여넣으면 Ava Chen이나 tag[0]이 돌아와서 파라미터가 기대한 그대로인지 한눈에 보입니다. URL 전체를 분해하려면 URL 파서가 쿼리 파라미터를 자동으로 처리합니다.

이중 인코딩된 값 디버깅

Ava%2520Chen을 붙여넣고 한 번 디코딩하면 Ava%20Chen이 나옵니다. 그 추가 레이어가 결정적 증거 — 어딘가에서 프록시, 프레임워크, 라이브러리가 값을 두 번째로 인코딩한 겁니다. 다시 디코딩하면 진짜 문자열을 얻습니다. OAuth 명세는 흔한 범인인데, redirect_uri 값이 친절하게도 각각 다시 인코딩하는 레이어들을 자주 통과하기 때문입니다.

로그에서 웹훅과 분석 URL 검사

프로덕션에서 뭔가 실패했을 때, 액세스 로그의 URL은 보통 완전히 인코딩되어 있습니다 — 웹훅이 실제로 보낸 JSON 대신 %7B%22event%22%3A%22signup%22%7D입니다. 여기 붙여넣으면 {"event":"signup"}이 돌아오는데, 이건 읽을 수 있습니다.

매직 링크나 비밀번호 재설정 URL 디코딩

Marco Rivera 같은 고객이 "재설정 링크가 깨졌다"고 할 때, 그 링크에는 토큰, 이메일, 리다이렉트 대상이 들어 있고 모두 퍼센트 인코딩되어 있습니다. 의심스러운 파라미터를 디코딩하면 이메일이 올바른 주소인지, 토큰이 메일 클라이언트의 변형을 견뎌냈는지, 리다이렉트 URI가 잘렸는지가 보입니다.

자주 묻는 질문

단독 % 또는 %G1 같은 잘못된 입력은 어떻게 되나요?

네이티브 decodeURIComponent는 유효한 %XX 16진 쌍이 아닌 시퀀스에서 URIError: URI malformed를 던집니다. 이 페이지는 그것을 잡아서 충돌하는 대신 출력 패널에 "잘못된 인코딩: ..."을 씁니다. 가장 흔한 원인은 %25여야 했던 떠도는 % 리터럴이거나, 끝부분 16진 숫자가 잘려나간 복사-붙여넣기입니다.

입력이 이중 인코딩되었는지 어떻게 알 수 있나요?

한 번 디코딩하세요. 출력에 여전히 % 문자(특히 %20, %2F, %3A)가 있고 원래 일반 텍스트여야 했다면, 두 번 인코딩된 겁니다. 첫 번째 디코딩의 출력을 다시 디코딩하세요. 세 라운드는 드물지만 가능 — 보통 세 개의 다른 서비스가 같은 값을 각각 인코딩한 체인을 의미합니다.

+ 기호는 — 공백으로 디코딩되어야 하지 않나요?

decodeURIComponent로는 아닙니다 — +를 그대로 둡니다. +를 공백으로 보는 관습은 application/x-www-form-urlencoded(HTML 폼 제출)에 속하며, 일반적인 URL 퍼센트 인코딩의 것이 아닙니다. 입력이 폼 본문에서 와서 +가 공백을 의미한다면, 먼저 .replace(/\+/g, "%20")를 실행한 다음 디코딩하세요. application/x-www-form-urlencoded에 대한 WHATWG 명세가 이 두 갈래 상황을 설명합니다.

유니코드와 이모지도 올바르게 왕복되나요?

예. 퍼센트 인코딩된 멀티바이트 UTF-8 시퀀스(예: 체크마크의 %E2%9C%85, 로켓의 %F0%9F%9A%80)는 원래 문자로 곧장 디코딩됩니다. 이게 실패하는 유일한 경우는 인코더가 UTF-8이 아닌 문자셋을 사용했을 때이며, 현대 시스템은 그렇게 하지 않습니다.

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

아니요. 디코딩은 전적으로 브라우저 안에서 실행됩니다. 네트워크 호출도, 서버 로그도, 어떤 것도 기기를 떠나지 않습니다. 토큰, 이메일, 서명된 URL — 모두 안전하게 붙여넣을 수 있습니다.

여기서 얼마나 큰 문자열을 디코딩할 수 있나요?

입력에 256 KB 상한이 있습니다. 수백 KB의 퍼센트 인코딩 텍스트가 있다면, 거의 확실히 도구에 붙여넣기보다는 서버 측에서 디코딩되어야 할 페이로드입니다 — 그 정도로 큰 인코딩된 페이로드는 보통 base64나 요청 본문이 적합한 작업에 URL 인코딩을 잘못 쓰고 있다는 뜻입니다.

다른 URL 및 인코딩 도구

디코딩은 한 가지 작업입니다. 자연스럽게 짝을 이루는 다른 도구들: