URL 인코더

URL 인코더는 문자열을 URL 쿼리 매개변수와 기타 텍스트 기반 웹 데이터에 쓰이는 폼 인코딩 형식으로 변환하는 무료 도구입니다.

URL 인코딩이란 무엇이며 왜 사용하나요?

URL 인코딩은 URL에서 특별한 의미를 갖는 문자를 퍼센트 기호와 16진수 숫자의 조합으로 바꿉니다. 이를 통해 제한된 문자 집합만 허용하는 시스템에서도 텍스트를 전달할 수 있습니다.

예를 들어 앰퍼샌드는 쿼리 매개변수를 구분하므로, 값 자체에 포함된 앰퍼샌드는 %26으로 인코딩해야 합니다. 공백도 별도로 처리해야 합니다. 이 도구는 공백을 더하기 기호로 변환하는 PHP의 urlencode 함수를 사용합니다.

변환 전: tea and cake

변환 후: tea+and+cake

URL로 인코딩된 텍스트는 다음과 같은 곳에서 볼 수 있습니다.

• 웹 양식으로 제출된 쿼리 문자열
• 그대로 넣을 수 없는 텍스트가 포함된 데이터 URI
• 이메일 메시지에 포함된 링크
• JSON 페이로드에 저장된 URL 값
• 웹 애플리케이션에서 사용하는 리디렉션 및 콜백 매개변수
• 국제화 도메인과 연결된 URL, 단 도메인 이름 자체에는 퍼센트 인코딩이 아니라 Punycode가 필요할 수 있음

URL 인코딩은 암호화가 아니며 정보를 숨겨 주지 않습니다. 퍼센트 인코딩된 URL 값을 볼 수 있는 사람은 누구나 이를 디코딩할 수 있습니다.

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

인코딩할 문자열을 입력하고 도구를 실행한 다음, URL 인코딩 결과 필드에서 변환된 값을 확인하세요. 문자열을 둘러싼 따옴표나 설명 문구가 아니라 값 자체만 인코딩해야 합니다.

변환 작업은 서버에서 이루어집니다. 입력값은 HTTPS를 통해 서버로 전송되며 저장되지 않습니다. 그렇더라도 웹 주소는 브라우저 방문 기록, 분석 시스템, 서버 로그에 남을 수 있으므로 비밀번호, 세션 토큰 또는 비공개 개인정보를 URL에 넣지 마세요.

원래 값으로 되돌리려면 URL 디코더를 사용하세요. 양방향에서 같은 문자 인코딩과 폼 인코딩 규칙을 사용했다면, 올바르게 디코딩된 값은 원본 텍스트와 일치해야 합니다.

URL 전체를 인코딩해야 하나요, 매개변수 값만 인코딩해야 하나요?

일반적으로 URL 전체가 아니라 각 매개변수 값을 인코딩해야 합니다. 주소 전체를 인코딩하면 콜론, 슬래시, 물음표, 등호 같은 구조 문자까지 바뀝니다.

검색값이 green tea & coffee라고 가정해 보겠습니다. 인코딩된 형식은 green+tea+%26+coffee이며, 매개변수 이름 뒤에 넣을 수 있습니다. 주소 전체를 인코딩하면 브라우저가 스킴, 호스트, 경로, 쿼리 문자열을 구분하는 데 필요한 문자가 가려집니다.

이 도구에서 사용하는 urlencode는 HTML 폼 방식의 쿼리 매개변수에 적합합니다. 일부 API와 경로 세그먼트는 RFC 3986 규칙을 따르며, 이 경우 공백을 +가 아니라 %20으로 표기합니다. 데이터를 받는 시스템이 +를 사용하는 폼 인코딩과 RFC 3986 방식의 %20 중 무엇을 요구하는지 확인하세요.

URL 인코딩 예시

ASCII 문자와 숫자는 읽을 수 있는 형태로 유지됩니다. 공백은 더하기 기호로 바뀌고, 예약된 문장 부호와 비ASCII 텍스트는 인코딩된 바이트로 표현됩니다.

• hello world는 hello+world가 됩니다.
• tea & cake는 tea+%26+cake가 됩니다.
• email=test@example.com은 email%3Dtest%40example.com이 됩니다.
• 100% ready는 100%25+ready가 됩니다.
• 원본 텍스트가 UTF-8을 사용한다면 café는 caf%C3%A9가 됩니다.

악센트가 있는 문자와 비라틴 문자는 먼저 문자 인코딩을 통해 바이트로 표현됩니다. 웹에서는 일반적으로 UTF-8을 사용합니다. 그런 다음 허용된 집합에 속하지 않는 각 바이트가 개별 퍼센트 이스케이프로 바뀝니다. 따라서 눈에 보이는 문자 하나가 %로 시작하는 여러 묶음으로 변환될 수 있습니다.

숫자는 별도로 처리할 필요가 없습니다. 입력값이 비어 있으면 인코딩된 내용도 생성되지 않습니다. 인코딩된 바이트 하나가 문자 세 개를 차지하므로 입력값이 매우 길면 결과가 상당히 길어질 수 있습니다.

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

대개 입력값이 서로 다른 규칙으로 인코딩되었거나, 두 번 이상 인코딩되었거나, 예상한 문자 집합의 텍스트가 아닐 때 디코딩이 실패합니다.

• 서로 다른 공백 처리 방식: 폼 디코더는 +를 공백으로 처리하지만, 엄격한 퍼센트 디코더는 더하기 기호 그대로 둘 수 있습니다.
• 이중 인코딩: %26의 퍼센트 기호 자체가 %25로 바뀌어 %2526이 될 수 있습니다. 이 값을 한 번만 디코딩하면 원래 앰퍼샌드가 아니라 %26이 반환됩니다.
• 잘못된 문자 인코딩: UTF-8 바이트를 다른 문자 집합으로 디코딩하면 대체 문자나 깨진 글자가 나타날 수 있습니다.
• 텍스트가 아닌 바이너리 데이터: 디코딩된 바이트가 이미지, 압축 파일 또는 다른 파일일 수 있으므로, 이를 텍스트로 표시하면 알아볼 수 없는 내용이 나타납니다.
• 잘못된 형식 또는 알파벳: URL 안전 Base64, 표준 Base64, 퍼센트 인코딩은 서로 다른 형식입니다. Base64 텍스트에 URL 디코더를 적용해도 의도한 값을 복원할 수 없습니다.

URL 인코딩에는 패딩 문자가 없습니다. 디코더에서 패딩이 누락되었다고 나온다면 입력값은 퍼센트 인코딩된 텍스트가 아니라 Base64 또는 다른 패딩 형식일 가능성이 높습니다.

자주 묻는 질문

퍼센트 이스케이프의 대문자와 소문자는 같은 뜻인가요?

네. 퍼센트 이스케이프의 16진수 문자는 대소문자를 구분하지 않으므로 %2F와 %2f는 모두 슬래시를 나타냅니다. 표기를 일관되게 유지하려면 대문자 16진수를 사용하는 것이 좋습니다.

URL 인코딩으로 국제화 도메인 이름을 변환할 수 있나요?

아니요. é 같은 문자가 들어 있는 도메인 레이블에는 일반적으로 국제화 도메인 이름 처리가 필요하며, xn--으로 시작하는 ASCII Punycode 형식으로 변환해야 합니다. 퍼센트 인코딩은 URL의 다른 구성 요소에 사용되며 이 변환을 대신할 수 없습니다.

줄바꿈과 탭은 어떻게 처리되나요?

탭과 줄바꿈 바이트는 일반적인 URL 값에 그대로 넣을 수 없으므로 퍼센트 인코딩됩니다. 탭은 흔히 %09로 표현되며, 줄 끝 표기는 원본이 LF 문자와 CRLF 문자 중 무엇을 사용하는지에 따라 달라집니다.

인코딩한 URL을 애플리케이션에 붙여 넣어도 작동하지 않는 이유는 무엇인가요?

애플리케이션이 인코딩 전 원본 값을 요구하고 자체적으로 인코딩한다면 이중 인코딩이 발생할 수 있습니다. URL 전체 길이 제한을 초과했거나 주소의 구조를 나타내는 부분에 있는 예약 문자가 인코딩되어 URL이 거부될 수도 있습니다. 인코딩하기 전에 애플리케이션이 어떤 개별 구성 요소를 요구하는지 확인하세요.

인코딩된 쿼리 문자열 데이터는 공유해도 안전한가요?

아니요. URL 퍼센트 인코딩은 표현 방식만 바꾸며, 브라우저와 개발자 도구를 사용하면 원래 값을 확인할 수 있습니다. 링크를 공유하기 전에 쿼리 매개변수에 이메일 주소, 계정 참조 정보, 액세스 토큰 또는 공개하면 안 되는 다른 데이터가 들어 있는지 확인하세요.