Why do spaces turn into %20 sometimes and + other times?

Two different specs. RFC 3986, which governs URLs themselves, encodes a space as %20. The application/x-www-form-urlencoded format used by HTML form submissions, defined in the WHATWG URL Standard, encodes a space as +. Both are valid in their own context, which is why + in a query string is ambiguous. The safe practice: always produce %20 for spaces and %2B for literal plus signs — every parser handles those correctly.

What is the difference between encodeURI and encodeURIComponent?

encodeURIComponent encodes nearly everything, including /, ?, &, and =, making it safe for individual values placed inside a URL. encodeURI preserves those reserved characters so a complete URL keeps its structure. Use encodeURIComponent for parameter values and path segments — which is almost every real-world case — and encodeURI only when sanitizing a full URL without restructuring it. Using encodeURI on a value containing & will silently break your query string.

How do I fix a double-encoded URL?

Double encoding happens when an already-encoded string gets encoded again — %20 becomes %2520 because the % itself turns into %25. To fix it, decode the string repeatedly until no %XX sequences remain and the output stops changing. Then find which layer of your system encoded twice — commonly your code plus a proxy, redirect service, or email link-wrapper — and remove one of the encoding steps. The rule: encode exactly once, at the last moment before the value enters the URL.

Is it safe to decode URLs in an online tool?

Only if the tool runs client-side. URLs frequently contain OAuth codes, password-reset tokens, session IDs, and email addresses. A server-side tool receives all of that and may keep it in access logs indefinitely. The toolz.dev URL Encoder/Decoder performs all conversion in your browser with JavaScript — no data is transmitted anywhere, which you can verify in your browser's network tab. For anything containing credentials or tokens, client-side processing should be non-negotiable.

Do I need to encode the whole URL or just the parameters?

Just the data parts — individual parameter values and, occasionally, path segments. The structural characters of the URL itself (the :// after the scheme, the ? starting the query, the & between parameters) must stay unencoded or the URL stops working. Encode each value separately with component-style encoding, then assemble the URL around them. Encoding a complete URL end-to-end is only correct when that URL is itself becoming a value inside another URL, like an OAuth redirect_uri.

Can URL encoding handle emoji and non-English characters?

Yes — modern percent-encoding operates on UTF-8 bytes, so any Unicode character works. A two-byte character like é becomes %C3%A9, and a four-byte emoji becomes four percent-sequences, such as %F0%9F%9A%80. Problems only arise with legacy tools or JavaScript's deprecated escape() function, which assume single-byte encodings and produce invalid output. The toolz.dev encoder handles full UTF-8 correctly in both directions.

Why does my URL break when a parameter contains an ampersand?

Because & is the delimiter between parameters. If a value contains a raw ampersand — say utm_campaign=black&friday — the server parses it as a parameter named utm_campaign with value black, plus a second parameter named friday. No error is raised; your data is just silently wrong. Encode the ampersand as %26 inside the value and the parameter arrives intact. This is one of the most common and least visible URL bugs.

What does %2F mean in a URL?

%2F is the percent-encoded forward slash. You'll see it when a value that happens to contain a slash — a file path, a date like 07/07, or a nested URL — is correctly encoded before being placed in a query parameter or path segment. Be aware that some servers and proxies (Apache, older Tomcat versions, various API gateways) reject or silently decode %2F in the path for security reasons, so if a request with an encoded slash returns a 404, the server-side configuration is usually the culprit, not your encoding.

How do I URL encode in Python, PHP, or on the command line?

Python: urllib.parse.quote() for path segments and quote_plus() for form-style query values. PHP: rawurlencode() produces RFC 3986 output with %20 for spaces, while urlencode() produces form-style output with +. Command line: jq -rR @uri or curl's --data-urlencode flag. Every one of these matches the component-style behavior of this tool, so you can prototype the encoding here and verify your code produces byte-identical output.

URL 인코딩 및 디코딩 온라인: 링크를 끊지 않고 백분율 인코딩을 위한 전체 가이드

퍼센트 인코딩을 존중하도록 가르쳐 준 버그는 정확히 한 명의 고객에 대해 실패한 OAuth 리디렉션이었습니다. WP Adminify 는 OAuth 를 통해 인증 된 Google 글꼴 통합을 가지고 있었고 한 명의 사용자 - 일부 역 프록시 설정을 실행하는 호스팅 리셀러 나는 여전히 don & # 39;t 를 완전히 이해합니다 - 계속 받고있었습니다 redirect_uri_mismatch 오류. 다른 사람들은 모두 괜찮았습니다. 이틀의 더 나은 부분을 그의 서버 구성을 비난하며 보냈습니다. 그리고 마침내 그의 브라우저가 보내는 실제 URL 을 문자별로 살펴보았는데,거기에: %2520 공간이 있어야 할 곳. 그의 프록시는 redirect_uri 를 인코딩하고있었습니다. 내 플러그인은 또한 인코딩합니다. 구글은 공간이 두 번 인코딩 된 URL 을 받았습니다 - %20 되었다 %2520- 그리고 악수 전체를 거절했습니다. 두 줄의 코드가 그것을 고쳤습니다. 이틀 동안 그것을 찾을 수 있었습니다.

그건 was't 심지어 내 첫 번째 인코딩 재해. 년 전에 I'd 원시 앰퍼샌드를 포함 하는 UTM 매개 변수와 플러그인 출시에 대 한 캠페인 링크를 구축-같은 것 utm_campaign=black&friday. 분석 대시보드에는 라는 신비한 캠페인이 표시되었습니다 black 그리고 팬텀 매개변수가 호출되었습니다 friday 그것은 아무것도 일치하지 않았습니다. 앰퍼샌드는 내 매개변수를 조용히 두 개로 나누었습니다. 오류 없음. 경고 없음. 숫자가 didn't 합산되는 것을 발견하기 전 11일 동안 조용히 잘못된 데이터만 있었습니다.

Here's URL 인코딩에 대 한 것: it's 는 isn't.까지 사소한 보이는 그 문제 중 하나 규칙은 2005 spec 에 살고 (RFC 3986), 브라우저 현실은 다른 사양(the)에 있습니다 WHATWG URL 표준), 자바 스크립트는 모두 약간 다른 일을 세 가지 다른 기능을 제공하고,PHP 는 당신에게 두 가지를 더 제공합니다. 잘못 알고 당신은 don't 충돌을 얻을 - 당신은 잘린 매개 변수,깨진 OAuth 흐름,크롬에서 작동하지만 이메일 클라이언트에서 죽는 링크를 얻을.

그래서 제가 항상 원했던 인코더/디코더를 만들었습니다 Toolz.dev. 이 가이드는 사용 방법, 그리고 - 더 중요한 것은 - 퍼센트 인코딩이 실제로 어떻게 작동하는지, 그래서 다음 %2520 로그에는 이틀이 아닌 2분이 소요됩니다.

TL;DR: URL 인코딩 또는 디코딩을 온라인으로 수행하려면 문자열을 URL에 붙여넣으세요 Toolz.dev URL 인코더/디코더,모드를 선택하고 Encode 또는 Decode 를 누르십시오. UTF-8 및 이모티콘을 올바르게 처리하며 Swap 버튼은 출력을 입력으로 다시 공급하므로 이중 인코딩 된 값을 벗길 수 있습니다 (%2520) 한 번에 한 레이어씩 분리합니다. 모든 것이 클라이언트 측에서 실행되므로 URL 의 토큰과 세션 ID 는 서버에 닿지 않습니다. 매개변수 인코딩 값 구성 요소 모드로; 이유를 알 때만 전체 URL을 인코딩합니다.

주요 특징

하나의 도구로 인코딩 및 디코딩합니다

값을 인코딩해야 하는 시간의 절반. 나머지 절반 I'm 로그 파일에서 형편없는 URL 을 쳐다보고 읽을 수 있는 것으로 디코딩해야 합니다. 이 도구는 하나의 입력 상자에서 두 가지 모두를 수행합니다. 인코딩과 디코드는 두 개의 버튼으로 서로 옆에 있으므로 there's 별도의 페이지에 대한 사냥이 없습니다. 인코딩된 문자열을 붙여넣고 디코딩을 누르십시오; 원시 쿼리 값을 입력하고 인코딩을 누르십시오. 또한 깔끔하게 왕복합니다: 인코딩,디코딩 및 원래 문자열을 다시 얻습니다. 바이트에 대한 바이트입니다. 그것은 명백하게 들리지만 I've 는 그들이 따르고 있는 사양을 결정할 수 있었기 때문에 왕복 여행에서 플러스 기호를 망친 온라인 도구를 사용했습니다. 이것은 모든 단계에서 수행하는 작업에 대해 명시적이며,you're 디버깅을 할 때 원하는 것과 정확히 같습니다.

구성 요소 대 전체 URL 인코딩 모드

이 구별은 대부분의 인코딩 버그가 탄생하는 곳입니다. 컴포넌트 모드는 isn't unreserved - 를 포함한 모든 것을 인코딩합니다 /, ?, &, 그리고 =- 이는 단일 매개변수 값에 대해 원하는 것입니다. 전체 URL 모드는 구조적 문자를 그대로 유지하므로 URL은 여전히 URL로 작동합니다. 이는 you're가 전체 주소를 정리할 때 원하는 것입니다. 잘못된 것을 사용하면 URL 구조가 손상되거나 위험한 문자가 인코딩되지 않은 상태로 남습니다. 이 도구는 두 모드를 모두 클릭 한 번으로 단일 드롭다운에 넣으며 각 모드는 JavaScript 함수로 레이블이 지정됩니다. - encodeURIComponent, encodeURI, application/x-www-form-urlencoded. 나는 그 이름에 앞뒤로 갔다. 인텐트 레이블 ("encode a value", "encode a whole URL") 는 더 잘 차갑게 읽힐 것이지만 함수 이름은 아래 참조 패널이 일대일로 코드 you're about to write 에 매핑되는 것을 의미하며 that's 대부분의 사람들이 실제로 입력 한 순간. If you've ever typed encodeURI 당신이 의미했을 때 encodeURIComponent- 한 번 이상 - 패널이 배송하기 전에 그것을 잡기 위해 거기에 있습니다.

UTF-8, 이모티콘 및 국제 문자를 처리합니다

유형 café 그리고 당신은 얻습니다 caf%C3%A9- 그만큼 é 두 개의 UTF-8 바이트로 올바르게 확장되었습니다. 이모티콘을 입력하면 4 퍼센트 인코딩 바이트를 얻을 수 있습니다. 여기서 이전 도구와 더 이상 사용되지 않는 JavaScript 가 있습니다 escape() 기능 붕괴: 라틴-1을 가정하거나 비표준을 생성합니다 %uXXXX 서버가 구문 분석할 수 없는 시퀀스. if you're building URLs with user generated content - names,search queries,city names in any language that isn't English - correct UTF-8 handling isn't a nice-to-have. 벵골어 텍스트,아랍어 슬러그,중국어 검색어: 이들 모두는 다른 쪽 끝에서 동일하게 디코딩되는 유효한 RFC 3986 퍼센트-시퀀스로 인코딩됩니다.

이중 인코딩된 값에 대한 스왑 버튼입니다

X-1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X %2520 트랩 - 이미 인코딩된 트랩입니다 %20 다시 인코딩 받기 - 한 번 이틀 비용이 들기 때문에 이것은 개인적인 것입니다. 디코딩은 단일 계층 작업입니다: %2520 디코딩합니다 %20공간이 아니라 때문입니다 %25 이다 인코딩 %니다. 하나의 패스는 당신에게 하나의 레이어를 가져옵니다. 스왑 버튼 (⇄) 는 입력 상자로 산출을 다시 움직입니다 그래서 다음 통행은 멀리 1 개의 누르기입니다. I've 는 프록시,리디렉션 서비스,및 이메일 연결 래퍼를 통과한 후에 깊은 3 개의 층을 풉니다 - 끈이 변화를 멈출 때까지 교환하고,변경하고, 교환하고,디코딩합니다. 그 "stops changing" 순간은 실제 신호 you're 찾고 있습니다. 이것이인 무슨을에 관하여 정직하십시오: it's 수동 반복,탐지기가 아닙니다. 공구는 does't 깃발 %25XX 귀하와 저는 그것이 필요한지 여부를 앞뒤로 설명합니다. 안정적일 때까지 자동 디코딩은 합법적으로 백분율 기호가 포함된 값을 자동으로 파괴할 때까지 편리할 것입니다.

세 가지 모드, 하나의 명시적 참조 패널

모드 선택기는 세 가지 옵션 - 컴포넌트, 전체 URL, form-urlencoded - 을 가지고 있으며, 그 아래의 패널은 그 모드가 탈출하는 문자를 정확히 철자하고, 보존하며, 작업된 예제를 보여주는지 전혀 기억할 수 없기 때문에 추가했습니다 encodeURIComponent 잎 ~ 혼자 (그렇습니다) 아니면 여부 ! 그리고 * 생존 (그들은,RFC 3986 이 예약되지 않은 것이 아니라 하위 델림으로 분류하기 때문에,사람들을 놀라게하는,그렇게). 세 가지 자바 스크립트 기능을 암기하는 대신' quirks,당신은 의도에 의해 모드를 선택하고 다시 읽어 it's 에 대해 할. 그 참조 텍스트는 내가 가장 사용하는 부분이며,it's 는 내가 오전 1 시에 차가운 페이지에 착륙하는 경우 원하는 것 I'd.

100% 클라이언트 측 - 브라우저에서 아무것도 남지 않습니다

Think about what's actually inside the URLs you decode: OAuth authorification codes,password-reset tokens,session IDs,unsubscribe links 의 이메일 주소,질문 문자열에 유용하게 채워진 API 키들. 그것들을 서버측 툴에 붙여넣으면 someone's access logs 에 도착하고,IP 에 묶여,누가 얼마나 오래 동안 유지되는지 알 수 있도록 유지됩니다. Toolz.dev 인코더는 브라우저에서 완전히 실행됩니다 - 변환은 로컬에서 실행되는 JavaScript 의 몇 줄이며,데이터로 요청이 이루어지지 않습니다. DevTools 를 열고 don't 가 저를 믿는다면 네트워크 탭을 시청하세요. 보안에 인접한 모든 것에 대해 클라이언트 측 isn't a feature,it's 최소 바.

무료, 가입 없음, 제한 없음

아니 계정 벽, 아니 문자열 변환을 수행하는 도구에 대한 일일 할당량 잔소리, 아니 "pro로 업그레이드하여 1,000 자 이상을 디코딩합니다." 나는 뉴스 레터 팝업으로 10 초 작업을 중단 광고에 질린 유틸리티 사이트의 피곤했기 때문에 Toolz.dev를 구축 북마크, 하루에 오십 번 사용, 완료.

URL 인코더 및 디코더 사용 방법

1단계: 도구를 열고 방향을 선택하세요

로 이동 Toolz.dev/tools/url-encoder 그리고 문자열을 왼쪽 상자에 넣습니다. 두 개의 작업 버튼인 Encode 와 Decode 가 있으며,먼저 방향을 설정하지 않고 붙여넣기 후에 하나를 선택합니다. 만약 you're 가 읽을 수 있는 것 (검색 쿼리,리디렉션 URL you're about to embed) 에서 시작한다면,Encode 를 누르십시오. if you're farting from something full of percent signs (로그 항목,리퍼러 헤더), Decode 를 누르십시오. 출력은 헤더에 복사 버튼이 있는 오른쪽 창에 떨어지고,Swap and Clear 는 두 개의 작업 버튼 옆에 앉습니다.

2 단계: 컴포넌트, Full-URL 또는 폼 모드를 선택합니다

인코딩 a 값 그것은 매개변수 안에 위치할 것입니다 - redirect_uri, 검색어, an 이후의 모든 것 = 서명? 컴포넌트 모드를 사용합니다. 인코딩합니다 /, ?, &, 그리고 = 그래서 당신의 값은 can't 주변 URL 을 깰. 인코딩 a 완전한 URL that just needs spaces and non-ASCII character cleaned up? 구조 문자를 보존하는 full-URL 모드를 사용한다. form-urlencoded 세번째 모드는 공백이 as 로 쓰여진 컴포넌트 인코딩이다 + 대신 %20- 당신이're hand-building an application/x-www-form-urlencoded 본문. 모드는 디코딩에도 영향을 미친다는 점에 유의하십시오: in form mode, + 는 디코딩하기 전에 공간으로 다시 변환된다; 다른 두에서는 리터럴 플러스로 유지된다. 의심스러울 때: 조각의 경우 컴포넌트 모드, 전체의 경우 full-URL 모드.

3단계: 출력을 읽고 남은 백분율 징후를 확인하세요

출력은 오른쪽 창에 나타납니다. 디코딩을 위해,결과가 여전히 포함하는지 살펴보세요 %XX 시퀀스 - 만약 그렇다면,값은 두 번 이상 인코딩되었습니다. Swap 을 눌러 해당 출력을 다시 입력으로 이동하고,다시 디코딩하고,문자열이 변경을 멈출 때까지 반복합니다. 입력이 잘못된 형식 (길 잃은 형식) 인 경우 % 리터럴처럼 두 개의 16진수 숫자가 뒤에 오지 않습니다 100%), you'll 은 자동 하프 디코드가 아닌 명시적인 오류를 얻게 되는데,이는 you're 디버깅 시 원하는 동작입니다.

4 단계: 복사 및 확인

복사 버튼을 누르고 그것이 속한 곳에 결과를 붙여 넣으십시오. 중요한 모든 것에 대해 - OAuth 는 특히 리디렉션합니다 - 하나의 최종 건전성 검사를하십시오: 인코딩 된 값을 다시 디코드 모드로 붙여 넣고 정확히 시작한 것에 대한 왕복 여행을 확인하십시오. 30 초의 검증은 이틀을 이깁니다 redirect_uri_mismatch.

퍼센트 인코딩, RFC 3986 및 공백이 % 20 또는 +가 되는 이유

URL 은 제한된 문자 집합만 안전하게 포함할 수 있습니다. 그 외의 모든 것은 퍼센트 인코딩된 바이트로 밀수입되어야 합니다. 규칙서는 RFC 3986 (2005), 캐릭터를 두 개의 진영으로 나눕니다.

예약되지 않은 문자 인코딩이 필요하지 않습니다: 문자 A–Z 그리고 a–z, 숫자 0–9및 네 개의 기호 - 하이픈 -, 기간 ., 밑줄 _, 그리고 물결표 ~. 이것들을 인코딩하는 것은 합법적이지만 무의미합니다.

예약된 문자 URL 내부에 구조적 작업이 있습니다: : / ? # [ ] @ (일반 구분 기호) 및 ! $ & ' ( ) * + , ; = (하위 구분 기호). 콜론은 스킴을 호스트에서 분리합니다. 물음표는 쿼리 문자열을 시작합니다. 앰퍼샌드는 파라미터를 분리합니다. 예약된 문자가 인코딩을 필요로 하는지 여부는 전적으로 다음에 달려 있습니다 나타나는 곳. ᅡ / 경로에는 구조가 있습니다; a / redirect_uri 매개변수 값 내부에는 데이터가 있으며,이것이 되어야 합니다 %2F 또는 서버가 URL을 잘못 구문 분석합니다.

역학: 문자를 가져와 UTF-8 바이트 (들) 을 얻고 각 바이트를 다음과 같이 씁니다 % 뒤에 두 개의 16 진수 자리. ASCII 문자는 1 바이트 - 공백은 %20, 앰퍼샌드는 %26. 그러나 UTF-8 은 멀티 바이트 인코딩이므로 é 2바이트입니다: %C3%A9. 일반적인 이모티콘은 4바이트입니다. ▪는 다음과 같이 인코딩합니다 %F0%9F%9A%80. 이것이 한 문자가 1바이트라고 가정하는 도구가 일반 영어 이외의 모든 것을 손상시키는 이유입니다.

자,공간 문제 - URL 인코딩에서 가장 혼란스러운 단일 항목입니다. RFC 3986 에 따라 공백이 됩니다 %20. 그러나 HTML 양식 제출은 다른 직렬화를 사용합니다 application/x-www-form-urlencoded, 오늘 정의되었습니다 WHATWG URL 표준, 그리고 그 형식은 공백을 다음과 같이 인코딩합니다 +니다. 둘 다 맞습니다 - 그들 자신의 문맥에서. 어떤 의미 + 쿼리 문자열에서 모호합니다: 리터럴 더하기 기호 (RFC 3986 읽기) 또는 인코딩된 공간 (양식 인코딩 읽기) 일 수 있습니다. If you've ever seen a phone number arrive as 1234 5678 누군가 보냈을 때 +1234..., you'이 버그를 만났다. 내 조언: 항상 방출 %20 공간 및 %2B 문자 그대로 더하기 기호의 경우. 아무도 그 내용을 잘못 분석하지 않습니다.

자바스크립트는 여러분에게 세가지 함수를 주는데,이들은 서로 바꿔 쓸 수 없습니다. 문자열이 주어졌을 때 a=b&c d:

const s = "a=b&c d";

encodeURIComponent(s); // "a%3Db%26c%20d"  — encodes =, &, and space
encodeURI(s);          // "a=b&c%20d"      — leaves = and & alone
escape(s);             // "a%3Db%26c%20d"  — deprecated; breaks on Unicode

encodeURIComponent 예약되지 않은 문자를 제외한 모든 것을 인코딩합니다(플러스) !'()*- 레거시 퀴크)로 매개변수 값에 안전합니다. encodeURI 예약된 문자를 보존하여 전체 URL이 계속 작동하도록 합니다. 하지만 이는 또한 이를 의미합니다 원't 보호하다 & 당신의 데이터 안에. 그리고 escape() 은 좋은 이유로 더 이상 사용되지 않습니다: 비표준을 생산합니다 %uXXXX 라틴-1 이 아닌 문자에 대한 시퀀스. 새 코드에서는 절대 사용하지 마세요.

PHP는 트위스트와 동일한 분할을 미러링합니다: urlencode() 양식 스타일 인코딩을 생성합니다(공간이 됩니다 +), 동안 rawurlencode() RFC 3986을 따릅니다(공간이 됩니다 %20). 만약 you're 는 양식 POST 본문 이외의 다른 것에 대한 URL 을 구축, rawurlencode() 당신이 원하는 하나입니다. 나는 일찍 잘못된 하나와 함께 WP Adminify 코드를 발송; WordPress's 자신의 add_query_arg() 나를 저장한 것보다 더 많은 시간 I'인정하고 싶습니다.

마지막으로 이중 인코딩 트랩입니다. %20 는 공간, 인코딩됩니다. 인코딩 그 문자열 다시 그리고 % 그 자체가 됩니다 %25, 당신에게 %2520. 한 번 해독하면 얻을 수 있습니다 %20 뒤로 - 여전히 인코딩. 이것은 때마다 발생 두 계층의 시스템 각 "helpfully" 인코딩: 당신의 코드 플러스 프록시,리디렉션 서비스 플러스 이메일 링크-래퍼. 그것을 방지하는 규칙: 정확히 한 번 인코딩,값이 URL 에 들어가기 전에 마지막 가능한 순간에,그리고 결코 인코딩 당신이 didn't 그냥 디코딩 또는 생성 원시.

일반적인 사용 사례

사용자 입력으로 쿼리 문자열 구축

사용자 형식의 텍스트가 URL 에 들어갈 때마다 - 검색 상자,필터, GET 를 통해 전달되는 양식 값 - 구성 요소 인코딩이어야 합니다. 를 검색하는 사용자 Q&A tips 된다 ?q=Q%26A%20tips; 인코딩되지 않은 경우 서버는 검색을 봅니다 Q 그리고 미스터리 매개변수입니다 A tips. 개발 중에는 을 사용합니다 URL 인코더 코드를 작성하기 전에 예상 값을 생성하려면 테스트할 알려진 올바른 참조가 있습니다. It's 또한 가장 빠른 방법으로 "이 문자를 인코딩해야합니까?" 코드 검토의 인수: 구성 요소 모드에 붙여넣고 살펴보세요. JavaScript's 와 같은 최신 API URLSearchParams 이 자동으로 처리, 그리고 당신은 그들을 사용 해야 합니다-하지만 당신은 여전히 필요 합니다 검증하다 무언가가 고장날 때 그들의 출력, 그리고 that's는 디코딩 작업입니다.

UTM 및 캠페인 링크 디버깅

마케팅 링크는 지뢰밭을 인코딩합니다. 공백,파이프 또는 앰퍼샌드가 있는 UTM 값; URL 단축기를 통과한 다음 이메일 service's 클릭 추적기를 통과한 다음 리디렉션하는 링크 - 각 계층은 인코딩을 추가하거나 망칠 수 있는 기회입니다. 캠페인이 분석에서 잘못 표시되면 첫 번째 동작은 항상 동일합니다: 전체 링크를 디코드 모드로 붙여넣고 분석 서버가 실제로 받은 내용을 읽습니다. 10 번 중 9 번은 범인이 몇 초 만에 보입니다 - 원시 & 매개변수 분할, a + 그것은 문자 그대로의 플러스 또는 a로 간주되었습니다 %2520 이중 인코딩 배신. 나의 black&friday indicent 는 I'd 가 첫날에 이것을 수행했다면 11 일 데이터 구멍 대신 11 초 수정되었을 것입니다.

OAuth redirect_uri 및 콜백 URL

OAuth는 공급자가 그러기 때문에 인코딩 실수가 비용이 많이 드는 곳입니다 정확한 문자열 일치 리디렉션 URI 에서. redirect_uri 는 다른 URL 안에 파라미터 값으로 내장된 전체 URL 입니다 - 그래서 컴포넌트 인코딩이 되어야 합니다,정확히 한번. 언더 인코딩 그것과 ? 또는 & 그 안에서는 외부 인증 URL 을 깬다. 이중 인코딩하면 공급자가 비교한다 https%3A%2F%2F... 귀하의 등록에 반대합니다 https://... 및 반환합니다 redirect_uri_mismatch 제로 더 자세한 내용으로. 그 오류가 나타나면,browser's 주소 표시줄에서 실제 인증 URL 을 디코딩하고 redirect_uri 문자 별 문자를 app's 등록 값과 페어링합니다 JWT 디코더 돌아오는 토큰을 검사하기 위해 브라우저를 떠나지 않고도 전체 OAuth 흐름을 디버깅할 수 있습니다.

로그 및 추천 헤더에서 잘못된 URL을 디코딩합니다

서버 로그와 리퍼러 헤더는 퍼센트 인코딩된 수프로 가득합니다: %D0%9F%D1%80%D0%B8%D0%B2%D0%B5%D1%82 검색 리퍼러에서 봇 트래픽의 트리플 인코딩된 경로, 의심스러운 요청의 인코딩된 페이로드. 이를 디코딩하면 실제로 무슨 일이 일어났는지 알아내는 방법입니다. 그 이상한 404가 키릴 문자를 사용하는 사용자였는지 아니면 스크립트를 조사하는 사용자였는지 여부입니다 ../../etc/passwd 인코딩의 세 계층 뒤에. 이것은 또한 정확히 개인 정보 각도가 가장 중요한 상황입니다: 로그 URL 은 일상적으로 세션 토큰과 이메일 주소를 포함합니다. 자체 로그를 유지하는 일부 임의의 서버가 아닌 클라이언트 측 도구에서 디코딩합니다. 나는이 워크 플로우에 대해 더 많이 썼다 API 디버깅 도구 가이드.

컬을 사용한 API 테스트

쉘과 컬은 URL 인코딩 위에 두 번째 지뢰밭을 형성합니다. & bash의 프로세스를 배경, ? zsh 에서 glob 확장을 트리거합니다 - 그래서 인용되지 않은 인코딩되지 않은 URL 은 네트워크에 도달하기도 전에 혼란스러운 방식으로 실패합니다. 내 워크플로: 도구의 각 매개 변수 값을 인코딩하고 URL 을 조립한 다음 작은 따옴표로 감싼 다음 컬을 실행합니다. API 가 "looks right," 장황한 출력에서 정확한 URL 을 디코딩합니다 (curl -v) 실제로 전송된 내용을 보려면 버그가 API가 아닌 내 터미널이었습니다. curl's --data-urlencode 플래그는 POST 본문에 대한 인코딩을 처리하지만 GET 쿼리 문자열의 경우 you're는 대부분 자체적으로 수행되며 신뢰할 수 있는 인코더가 추측을 능가합니다.

ASCII가 아닌 텍스트와 링크를 공유합니다

다른 언어로 된 Wikipedia 기사, 현지 지명이 포함된 Google 지도 링크, 벵골어 또는 아랍어 슬러그가 포함된 문서 URL - 주소 표시줄에서 하나를 복사하면 예쁘게 될 수 있습니다 유니코드 형태 또는 벽 %E0%A6%ACbrowser's 분위기에 따라 -스타일 바이트. 일부 채팅 앱과 이메일 클라이언트는 원시 유니코드 형식을 자르거나 엉망으로 만듭니다. 공유하기 전에 URL 을 인코딩하면 모든 메신저,메일링 리스트 및 Markdown 렌더러 I've 에서 살아남은 순수 ASCII 문자열이 생성됩니다. 반대로 디코딩하면 읽을 수 없는 공유 링크가 클릭하기 전에 사람이 확인할 수 있는 것으로 다시 전환됩니다. 라인 노이즈처럼 보이는 도착 항목을 전달하기 전에 수행할 가치가 있습니다.

encodeURIComponent vs encodeURI vs escape(): 어느 것을 사용해야합니까?

3 개의 기능,1 개의 정확한 과태. Here's 정직한 비교:

	`encodeURIComponent()`	`encodeURI()`	`escape()`
인코딩하다	제외한 모든 `A-Z a-z 0-9 - . _ ~ ! ' ( ) *`	예약되지 않은 것을 제외한 모든 것 + 예약된 모든 문자(`: / ? # [ ] @ ! $ & ' ( ) * + , ; =`)	제외한 모든 `A-Z a-z 0-9 @ * _ + - . /`
공간이 되는	`%20`	`%20`	`%20`
`&` 그리고 `=`	인코딩됨(`%26`, `%3D`)	인코딩되지 않음	인코딩된
유니코드 처리	올바른 UTF-8 바이트	올바른 UTF-8 바이트	깨진 - 비표준 `%uXXXX`
위해 사용하십시오	매개변수 값, 경로 세그먼트, URL 내부의 모든 것	완전한 URL 당신은 don't 구조 조정을 원합니다	아무것도
상태	표준, 권장	표준, 틈새	더 이상 사용되지 않습니다

내 자세, 그리고 I'll 이 언덕에서 죽는다: 사용 encodeURIComponent 가치관에는 거의 항상. 정신 모델은 간단합니다. 문자열이 진행되는 경우입니다 내부 URL (쿼리 값,경로 세그먼트,redirect_uri), it's 구성 요소,그리고 그것은 얻는다 encodeURIComponent. 다음과 같은 경우 encodeURI 정말 옳다 드문: 당신은 공간이나 비 ASCII 문자를 포함하는 완전하고 이미 구조화 된 URL 을 가지고 있으며,당신은 그것의 구조를 건드리지 않고 그것을 소독하고 싶습니다. That's 어쩌면 실제 인코딩 호출의 5% escape() 단순히 약 2010 년 이후에 작성된 코드에 표시되지 않아야합니다 - 그것의 유니 코드 출력 isn't 유효한 퍼센트 인코딩, 그리고 모든 현대 린터는 어쨌든 플래그를 지정합니다.

뉘앙스 하나 더: encodeURIComponent 잎 ! ' ( ) * RFC 3986 이 예약된 하위 구분 기호로 나열하더라도 역사적인 이유로 인코딩되지 않았습니다. OAuth 및 strict-parsing API 의 경우 일부 라이브러리는 두 번째 패스를 추가하여 해당 5 개도 인코딩합니다. 까다로운 API 가 값을 거부하면 that's a place to look - and the URL 인코더's 컴포넌트 모드는 정확히 어떤 문자가 변환되었는지 보여 주므로 비교할 수 있습니다.

자주 묻는 질문

URL 인코딩이란 무엇입니까?

URL 인코딩 (퍼센트 인코딩) 은 URL 에서 안전하지 않거나 구조적으로 의미가 있는 문자를 나타내는 메커니즘입니다. 문제가 있는 각 문자는 UTF-8 바이트로 변환되고 각 바이트는 퍼센트 기호 뒤에 16 진수 두 자리 - 공백은 % 20,암퍼샌드는 % 26 이 됩니다. 규칙은 RFC 3986 에 정의되어 있습니다. URL 은 제한된 문자 집합만 허용하고 ? 및 & amp;와 같은 문자는 URL 구조 내에서 수행할 작업이 있기 때문입니다.

왜 공백이 가끔씩 % 20 으로 바뀌고 다른 때에는 + 로 바뀌나요?

두 가지 다른 사양. URL 자체를 관리하는 RFC 3986 은 공간을 % 20 으로 인코딩합니다. WHATWG URL Standard 에 정의된 HTML 양식 제출에서 사용되는 응용 프로그램/x-www-form-urlencoded 형식은 공간을 +로 인코딩합니다. 둘 다 자체 컨텍스트에서 유효하므로 쿼리 문자열에서 +가 모호합니다. 안전한 관행: 항상 공백에 대해 % 20 을 생성하고 리터럴 플러스 기호에 대해 % 2B 를 생성합니다. 모든 파서는 이를 올바르게 처리합니다.

encodeURI 와 encodeURIComponent 의 차이점은 무엇입니까?

encodeURIComponent 는 /, ?, & amp;, 및 =를 포함한 거의 모든 것을 인코딩하여 URL 내부에 배치된 개별 값에 대해 안전하게 만듭니다. encodeURI 는 해당 예약된 문자를 보존하므로 완전한 URL 은 구조를 유지합니다. 거의 모든 실제 사례인 매개변수 값 및 경로 세그먼트에 encodeURIComponent 를 사용하고 전체 URL 을 재구성하지 않고 삭제할 때만 encodeURI 를 사용합니다. & amp;가 포함된 값에 encodeURI 를 사용하면 쿼리 문자열이 자동으로 끊어집니다.

이중 인코딩된 URL을 어떻게 수정하나요?

이중 인코딩은 이미 인코딩된 문자열이 다시 인코딩될 때 발생합니다 - %20 은 %2520 이 됩니다. 왜냐하면 %25 로 바뀌기 때문입니다. 이를 수정하려면 %XX 시퀀스가 남지 않고 출력이 변경되는 것을 멈출 때까지 문자열을 반복적으로 디코딩합니다. 그런 다음 시스템의 어느 계층이 두 번 인코딩되었는지 찾으십시오 - 일반적으로 코드와 프록시,리디렉션 서비스 또는 이메일 링크 래퍼 - 그리고 인코딩 단계 중 하나를 제거합니다. 규칙: 값이 URL 에 들어가기 전 마지막 순간에 정확히 한 번 인코딩합니다.

온라인 도구에서 URL을 디코딩하는 것이 안전합니까?

도구가 클라이언트 측에서 실행되는 경우에만. URL 은 OAuth 코드,암호 재설정 토큰,세션 ID 및 이메일 주소를 자주 포함합니다. 서버 측 도구는 이 모든 것을 수신하고 이를 액세스 로그에 무기한 보관할 수 있습니다. Toolz.dev URL 인코더/디코더는 JavaScript 로 브라우저에서 모든 변환을 수행합니다. 아무 데이터도 전송되지 않으며 브라우저's 네트워크 탭에서 확인할 수 있습니다. 자격 증명이나 토큰이 포함된 모든 경우 클라이언트 측 처리는 협상할 수 없어야 합니다.

전체 URL을 인코딩해야 합니까 아니면 매개변수만 인코딩해야 합니까?

데이터 부분만 - 개별 파라미터 값과,가끔씩, 경로 세그먼트. URL 자체의 구조적 문자 (스킴 뒤의 ://, 쿼리 시작,& 파라미터 사이) 는 인코딩되지 않은 상태로 유지되거나 URL 이 작동을 중지해야 합니다. 각 값을 컴포넌트 스타일 인코딩으로 별도로 인코딩한 다음,그 주위에 URL 을 어셈블합니다. 완전한 URL 을 엔드투엔드로 인코딩하는 것은 해당 URL 자체가 OAuth redirect_uri 와 같이 다른 URL 내부의 값이 될 때만 올바릅니다.

URL 인코딩이 이모티콘과 영어가 아닌 문자를 처리할 수 있나요?

예 - 최신 퍼센트 인코딩은 UTF-8 바이트에서 작동하므로 모든 유니코드 문자가 작동합니다. é와 같은 2 바이트 문자는 %C3%A9 가 되고,4 바이트 이모지는 %F0%9F%9A%80 과 같은 4 퍼센트 시퀀스만 발생합니다. 문제는 레거시 도구 또는 JavaScript's 더 이상 사용되지 않는 escape() 함수에서만 발생하며,이는 단일 바이트 인코딩을 가정하고 잘못된 출력을 생성합니다. Toolz.dev 인코더는 양방향에서 전체 UTF-8 을 올바르게 처리합니다.

매개변수에 앰퍼샌드가 포함되어 있는데 URL이 끊어지는 이유는 무엇입니까?

왜냐하면 &는 매개 변수 사이의 구분 기호입니다. 값이 원시 앰퍼샌드를 포함하는 경우 - 예를 들어 utm_campaign=black&friday - 서버는 값이 검은색인 utm_campaign 이라는 매개 변수와 friday 라는 두 번째 매개 변수로 구문 분석합니다. 오류가 발생하지 않습니다; 데이터가 조용히 잘못되었습니다. 앰퍼샌드를 값 내부의 % 26 으로 인코딩하면 매개 변수가 그대로 도착합니다. 이것은 가장 일반적이고 가장 눈에 잘 띄지 않는 URL 버그 중 하나입니다.

URL 에서 % 2F 는 무엇을 의미합니까?

% 2F 는 퍼센트로 인코딩된 앞으로의 슬래시입니다. You'll 은 우연히 슬래시를 포함하는 값 - 파일 경로,07/07 과 같은 날짜 또는 중첩된 URL - 이 쿼리 파라미터나 경로 세그먼트에 배치되기 전에 올바르게 인코딩될 때 보안상의 이유로 경로의 % 2F 를 거부하거나 묵묵히 디코딩하는 일부 서버와 프록시 (Apache,이전 Tomcat 버전,다양한 API 게이트웨이) 를 알고 있어야 합니다. 따라서 인코딩된 슬래시가 있는 요청이 404 를 반환하는 경우 서버측 구성은 일반적으로 인코딩이 아니라 범인입니다.

Python, PHP 또는 명령줄에서 URL 인코딩은 어떻게 합니까?

파이썬: 경로 세그먼트에 대한 urllib.parse.quote() 및 양식 스타일 쿼리 값에 대한 quote_plus(). PHP: rawurlencode() 는 공백에 대해 % 20 으로 RFC 3986 출력을 생성하는 반면 urlencode() 는 +로 양식 스타일 출력을 생성합니다. 명령줄: jq -rR @uri 또는 curl's --data-urlencode 플래그. 이들 중 하나마다이 도구의 구성 요소 스타일 동작과 일치하므로 여기에서 인코딩을 프로토 타입하고 코드가 바이트 동일 출력을 생성하는지 확인할 수 있습니다.

감싸는 중

URL 인코딩은 큰 보상을 받는 작은 기술입니다. 일단 읽을 수 있게 되면 %C3%A9 é와 스팟으로 %2520 이중 인코딩 냄새로, "it의 전체 범주는 내 machine&quot에서 작동; 버그 - 깨진 OAuth 흐름, 팬텀 UTM 캠페인, 완벽하게 합리적으로 보이는 요청을 거부하는 API - 신비한에서 기계로 바뀝니다. 인덱스 카드에 맞는 규칙: 예약되지 않은 문자가 통과하고, 다른 모든 것은 % HH로 UTF-8 바이트가되고, 구조가 아닌 값을 인코딩하고, 정확히 한 번 인코딩합니다.

보관하세요 URL 인코더/디코더 형제자매 옆에 북마크가 있습니다 Base64 변환기 다른 인코딩 체계의 경우 모든 인증 헤더에서 you'll이 만납니다(I've written a full Base64 인코딩 가이드 언제 어떤 것을 사용할 것인가), HTML 엔터티 인코더/디코더 웹 콘텐츠가 상단에 쌓이는 것을 좋아하는 세 번째 인코딩 계층의 경우(the HTML 엔터티 가이드 내가 친 것과 동일한 함정의 이중 탈출 버전을 다룹니다 %2520), 그리고 JSON 포맷터 디코딩된 URL이 가리키는 모든 항목에 대해.

그리고 만약 you're 더 넓은 브라우저 기반 디버깅 키트를 조립하고 있다면, the 코딩 도구 가이드 이러한 도구가 실제 워크 플로우에서 어떻게 조화를 이루는지 살펴 봅니다. Toolz.dev 의 모든 것은 클라이언트 측을 실행하고 비용이 들지 않으며 한 가지 작업을 잘 수행합니다. That & # 39;s 전체 피치 - 내가 잘못 배치 된 단일 % 25 에 이틀을 보내기 전에 누군가가 나에게 만들었 으면 좋았을 것과 같은 것입니다.

Frequently Asked Questions

URL encoding (percent-encoding) is the mechanism for representing characters in a URL that would otherwise be unsafe or structurally meaningful. Each problematic character is converted to its UTF-8 bytes, and each byte is written as a percent sign followed by two hexadecimal digits — a space becomes %20, an ampersand becomes %26. The rules are defined in RFC 3986. It exists because URLs only permit a limited character set, and characters like ? and & have jobs to do inside URL structure.

Command Palette