URL 인코더/디코더
URL과 쿼리 파라미터용으로 퍼센트 인코딩하거나 이미 인코딩된 URL을 디코딩합니다. 단일 값에는 encodeURIComponent, 전체 링크에는
텍스트를 퍼센트 인코딩해 URL 안에서 안전하게 오갈 수 있게 하거나, 로그나 메일에 있던 링크를 해석합니다. 공백, 앰퍼샌드, 물음표, 비라틴 문자 같은 값은 쿼리 문자열에 들어가기 전에 이스케이프해야 하며, 이 도구는 인코딩된 형태가 정확히 어떻게 되는지 보여 줍니다.
중요한 것은 두 가지 모드입니다. 단일 값(검색어, 이메일 주소, 토큰)을 인코딩하면 예약 문자가 모두 이스케이프되고, 완전한 링크를 인코딩하면 슬래시, 물음표, 앰퍼샌드 같은 구조 문자는 그대로 남습니다. 잘못 고르는 것이 리디렉션이 깨지는 가장 흔한 원인이므로 모드를 선택할 수 있게 되어 있습니다.
URL을 인코딩하고 디코딩하는 방법
텍스트나 URL을 붙여 넣습니다
값 모드와 전체 링크 모드 중에서 고릅니다
인코딩되거나 디코딩된 결과를 복사합니다
자주 묻는 질문
두 모드는 무엇이 다른가요?
값 모드는 & = ? / # 같은 예약 문자를 이스케이프하며, 쿼리 파라미터 안에서는 이 방식이 필요합니다. 전체 링크 모드는 이런 문자를 그대로 두어 완전한 URL이 쓸 수 있는 상태로 유지됩니다.
공백이 %20이나 +가 되는 이유는 무엇인가요?
%20이 표준 퍼센트 인코딩입니다. 더하기 기호는 HTML 양식 제출에서 온 옛 관례이며 쿼리 문자열 안에서만 같은 뜻이고 경로에서는 그렇지 않습니다.
인코딩뿐 아니라 디코딩도 되나요?
네. 디코딩은 양방향으로 동작하며 악센트 문자와 CJK 텍스트를 포함한 원래 문자를 보여 줍니다.
제 문자열에서 디코딩이 실패하는 이유는 무엇인가요?
두 자리 16진수가 뒤따르지 않는 잘못된 % 기호는 유효하지 않아 디코딩할 수 없습니다. 값이 중간에 잘렸는지, 문자 그대로의 퍼센트 기호를 쓰려던 것은 아닌지 확인하세요.
비라틴 문자도 처리하나요?
네. 텍스트를 먼저 UTF-8로 인코딩한 뒤 퍼센트 인코딩하며, 이것이 브라우저와 서버가 기대하는 형태입니다.
입력한 내용이 업로드되나요?
아니요. 인코딩과 디코딩은 브라우저 안에서 이루어지는 순수한 텍스트 연산입니다.
한눈에 보기
| 입력 | 텍스트 |
|---|---|
| 여러 파일 | 아니요 |
| 실행 위치 | 브라우저에서 실행 - 파일은 업로드되지 않습니다 |
| 오프라인에서도 작동 | 예 — 페이지를 불러온 후 |
| 가격 | 무료, 가입 필요 없음, 워터마크 없음 |
데이터 형식 고르기
JSON은 API가 반환하거나 프로그램이 읽는 데이터의 기본 선택입니다. 중첩 구조, 숫자, 불리언, null을 자연스럽게 다루고 모든 언어가 파싱합니다. CSV는 더 작고 스프레드시트에서 바로 열리지만, 중첩을 표현할 방법이 없고 구분자, 인용, 문자 집합에 관한 공통 표준도 없습니다. 변환이 어긋나는 지점이 바로 여기입니다. XML은 장황하지만 속성, 혼합 콘텐츠, 스키마를 담을 수 있어 문서 형식과 기존 연동에서 여전히 주류입니다. YAML은 설정 파일에 가장 읽기 좋지만 공백에 민감하고 형 변환이 뜻밖의 결과를 냅니다("no"가 false가 되거나 1.10 같은 버전이 1.1이 됩니다). 보기 좋은 형식이 아니라 그것을 사용하는 도구가 선호하는 형식을 고르십시오.
변환이 조용히 깨지는 곳
변환 버그는 대부분 문법이 아니라 의미의 문제입니다. 우편번호 CSV 열은 스프레드시트가 숫자라고 추측하는 순간 앞의 0을 잃습니다. 긴 ID는 부동소수점 정밀도를 넘어섭니다. 날짜는 일이 먼저인지 월이 먼저인지에 따라 의미가 달라집니다. JSON 키에는 순서가 없지만 배열에는 있습니다. 키를 정렬하는 도구는 아무것도 바꾸지 않지만 배열을 정렬하는 도구는 데이터를 바꿉니다. Unicode도 함정입니다. 텍스트는 UTF-8이나 UTF-16으로, 또는 BOM과 함께 도착할 수 있고, 잘못 추측한 디코더는 강세 문자가 있는 글자를 깨진 문자로 만듭니다. 어떤 변환이든 믿기 전에 첫 행과 마지막 행, 앞에 0이 붙은 필드, 따옴표나 쉼표, 줄바꿈이 들어 있는 필드를 표본 검사하십시오.