URL 디코더

URL 디코더는 퍼센트 인코딩된 URL 텍스트를 원래 문자열 형태로 되돌리는 무료 도구입니다.

URL 디코딩은 어떤 작업을 하나요?

URL 디코딩은 공백, 문장 부호와 기타 바이트를 URL이나 퍼센트 인코딩을 사용하는 정해진 구문으로 전달하기 위해 적용한 이스케이프 처리를 되돌립니다. 퍼센트 인코딩에서는 퍼센트 기호와 두 자리 16진수로 바이트를 나타냅니다. 폼 형식의 URL 인코딩은 공백을 +로도 표현합니다. 예를 들어 공백은 %20, 앰퍼샌드는 %26으로 표기할 수 있습니다.

간단한 변환 전후 예시는 다음과 같습니다.

인코딩된 입력: red%20%26%20blue

디코딩된 출력: red & blue

일부 문자는 URL 구조에서 특별한 의미를 가지므로 이러한 인코딩이 필요합니다. 물음표는 URL의 쿼리가 시작되는 지점을 구분하고, 폼 형식의 쿼리 데이터에서는 일반적으로 앰퍼샌드가 필드를 나눕니다. 이런 문자를 인코딩하면 애플리케이션에서 구분자가 아닌 데이터로 전달할 수 있습니다.

URL 인코딩은 암호화가 아니며 정보를 숨겨 주지 않습니다. 인코딩된 값을 읽을 수 있는 사람이라면 누구나 디코딩할 수 있습니다. 퍼센트 인코딩된 비밀번호, 액세스 토큰 또는 개인정보를 보호된 데이터로 취급하지 마세요.

URL 디코더는 어떻게 사용하나요?

인코딩된 텍스트를 붙여 넣거나 입력해 처리한 다음, URL 디코딩됨 결과 필드에서 복원된 값을 확인하세요. 이 도구는 PHP의 urldecode 함수를 사용하므로 유효한 %HH 시퀀스를 변환하고 더하기 기호를 공백으로 처리합니다.

1. 쿼리 매개변수 값처럼 인코딩된 구성 요소를 복사하세요.
2. 따옴표가 실제 값에 포함된 경우가 아니라면 따옴표를 추가하지 말고 URL 인코딩된 값을 입력하세요.
3. URL 입력을 처리하고 URL 디코딩됨 결과를 확인하세요.
4. 출력에 %2F 또는 %20 같은 시퀀스가 여전히 남아 있다면 다시 디코딩하기 전에 원본이 두 번 이상 인코딩되었는지 확인하세요.

처리는 서버에서 이루어집니다. 입력한 데이터는 HTTPS를 통해 서버로 전송되며 저장되지는 않지만, 처리 중에는 기기 외부로 나갑니다. 서버 측 처리가 해당 데이터에 적합한 경우가 아니라면 이 URL 디코더에 비밀 정보를 붙여 넣지 마세요.

URL 인코딩은 어디에 사용되나요?

URL 인코딩은 쿼리 문자열, 폼 제출 데이터, 링크에 삽입된 값에서 가장 흔히 볼 수 있습니다. 제한된 텍스트 형식을 통해 데이터를 전달해야 하는, 쉽게 눈에 띄지 않는 여러 곳에서도 사용됩니다.

• 쿼리 문자열: "tea & cake" 검색어는 q=tea+%26+cake로 표시될 수 있습니다.
• 데이터 URI: 미디어 유형 뒤의 텍스트 데이터를 퍼센트 인코딩할 수 있으며, Base64도 흔히 쓰이는 또 다른 표현 방식입니다.
• 이메일 링크: mailto 링크는 제목이나 본문 매개변수에 있는 공백, 줄바꿈, 문장 부호를 인코딩할 수 있습니다. 이메일 메시지 내부에서 사용하는 MIME 전송 인코딩은 별개의 형식입니다.
• JSON 페이로드: JSON 자체에는 고유한 이스케이프 규칙이 있지만, JSON 문자열에 이미 인코딩된 URL이나 쿼리 값이 들어 있다면 이를 별도로 디코딩해야 할 수 있습니다.
• 국제화 도메인: ASCII가 아닌 도메인 레이블에는 일반적으로 퍼센트 인코딩이 아닌 Punycode를 사용합니다. 다만 경로와 쿼리 구성 요소에는 퍼센트 인코딩된 UTF-8 바이트가 포함될 수 있습니다.

인코딩된 텍스트가 xn--로 시작하는 도메인 레이블이라면 IDN 퓨니코드 변환기를 사용하세요. URL 디코더는 Punycode 변환이 아니라 퍼센트 인코딩된 URL 구성 요소를 처리하는 도구입니다.

URL 디코딩 예시

다음은 흔히 볼 수 있는 URL 디코딩 입력과 그에 해당하는 디코딩 결과입니다.

• hello%20world는 hello world가 됩니다.
• name=Tom+Jones는 name=Tom Jones가 됩니다.
• fish%26chips는 fish&chips가 됩니다.
• 바이트가 UTF-8 텍스트를 나타내는 경우 %C2%A3는 £가 됩니다.
• UTF-8로 해석하면 %E6%9D%B1%E4%BA%AC는 東京가 됩니다.
• 100%25는 100%가 됩니다.

일반 문자, 숫자, 인코딩되지 않은 문장 부호는 대체로 입력한 그대로 유지됩니다. 빈 값을 입력하면 URL 디코딩됨 결과도 비어 있습니다. 매우 긴 입력에도 동일한 디코딩 규칙이 적용되지만, 브라우저, 서버 및 수신 시스템에서 요청이나 URL 길이에 자체 제한을 둘 수 있습니다.

악센트가 있는 문자와 라틴 문자가 아닌 문자는 일반적으로 UTF-8 바이트 시퀀스로 인코딩되며, 각 바이트가 따로 표기됩니다. 원본 시스템에서 다른 문자 인코딩을 사용했다면 디코딩된 바이트가 대체 문자나 의미를 알 수 없는 텍스트로 표시될 수 있습니다.

URL 디코딩이 실패하거나 문자가 깨지는 이유는 무엇인가요?

입력에 불완전한 퍼센트 시퀀스가 있거나, 두 번 이상 인코딩되었거나, 잘못된 문자 집합으로 해석되거나, 애초에 URL 인코딩된 데이터가 아니라면 결과가 바뀌지 않거나 예상과 다르게 나올 수 있습니다. PHP의 urldecode는 잘못된 퍼센트 시퀀스를 변경하지 않으며, 이중 인코딩된 입력은 한 번 처리한 뒤 중간 결과를 출력합니다. 반복해서 디코딩하기 전에 원본을 확인하세요.

• 이중 인코딩된 입력: %2520는 한 번 디코딩하면 %20이 되고, 두 번째로 디코딩해야 공백이 됩니다. 다른 인코딩 계층이 있다는 사실을 알고 있을 때만 다시 디코딩하세요.
• 불완전한 퍼센트 시퀀스: 인코딩된 각 바이트에는 두 자리 16진수가 필요합니다. 끝에 있는 % 또는 %2 같은 값은 형식이 잘못되어 완전한 인코딩 바이트를 나타낼 수 없으므로 PHP의 urldecode가 변경하지 않습니다.
• 잘못된 문자 인코딩: 퍼센트 디코딩은 바이트를 복원합니다. 예를 들어 ISO-8859-1 바이트를 UTF-8로 해석하면 퍼센트 시퀀스가 유효하더라도 문자가 깨질 수 있습니다.
• 텍스트가 아닌 바이너리 데이터: 디코딩된 바이트가 이미지, 압축 파일 또는 다른 바이너리 콘텐츠를 나타낼 수 있습니다. 이런 출력은 읽을 수 있는 텍스트로 표시되지 않는 것이 정상입니다.
• 잘못된 인코딩 계열: URL 디코딩 결과를 이어서 Base64 디코더에 입력하면 표준 알파벳과 URL 안전 알파벳의 차이, 누락된 = 패딩 또는 손상된 입력 때문에 디코딩에 실패할 수 있습니다. URL 퍼센트 인코딩에는 패딩이 없고 Base64 알파벳도 사용하지 않습니다. URL 디코딩은 이러한 Base64 문제를 검증하거나 복구하지 않습니다.

리터럴 더하기 기호를 처리할 때는 주의하세요. 폼 형식의 URL 인코딩에서 +는 공백을 의미합니다. 실제 더하기 기호는 일반적으로 디코딩 전에 %2B로 인코딩되어 있어야 합니다.

자주 묻는 질문

URL 전체를 디코딩해야 하나요, 일부만 해야 하나요?

가능하면 개별 경로 세그먼트나 쿼리 매개변수 값만 디코딩하세요. URL 전체를 디코딩하면 %26, %3F 또는 %2F처럼 인코딩된 예약 문자가 구분자로 바뀌어 URL 해석 방식이 달라질 수 있습니다.

소문자로 된 16진수 코드도 디코딩되나요?

예. 퍼센트 시퀀스의 16진수는 대소문자를 구분하지 않으므로 %2f와 %2F는 같은 바이트를 나타냅니다. 대소문자가 섞인 시퀀스도 유효합니다.

같은 값을 여러 번 반복해서 디코딩하나요?

아니요. urldecode를 한 번 호출하면 디코딩도 한 번만 수행됩니다. %252F가 %2F로 바뀐 뒤 슬래시를 만들려면 한 번 더 처리해야 합니다. 하지만 반복 디코딩은 리터럴 퍼센트 시퀀스를 포함하도록 만들어진 데이터를 변경할 수 있습니다.

URL 디코딩으로 손상된 텍스트를 복구할 수 있나요?

아니요. 유효한 퍼센트 인코딩은 되돌릴 수 있지만, 누락된 16진수를 복원하거나 원래 문자 집합을 확실하게 알아낼 수는 없습니다. 디코딩된 바이트가 올바르게 표시되지 않으면 원본 시스템, HTTP 헤더 또는 관련 문서를 확인하세요.

xn--로 시작하는 값은 어떻게 처리해야 하나요?

일반적인 퍼센트 인코딩 텍스트가 아니라 Punycode 도메인 레이블로 처리하세요. IDN 퓨니코드 변환기를 사용한 뒤 변환된 도메인을 주의 깊게 확인하세요. 시각적으로 비슷한 Unicode 문자가 서로 다른 문자 체계에 속할 수 있기 때문입니다.