웹 주소의 모든 문자는 브라우저, 서버, 프록시 및 로그가 모두 동의하는 작고 안전한 집합에서 나와야 합니다. 링크에 설정된 외부 항목(공백, 앰퍼샌드, 악센트 문자 또는 이모티콘)을 넣어야 하는 경우 먼저 URL을 인코딩해야 합니다. 퍼센트 인코딩이라고도 하는 URL 인코딩은 해당 문자를 퍼센트 기호와 16진수 바이트 값으로 바꾸는 표준입니다. 따라서 공백은 %20이 되고 &는 %26이 됩니다. 이 가이드에서는 URL 인코딩이 무엇인지, 어떤 문자가 필요한지, %XX 형식이 어떻게 작동하는지, 그리고 대부분의 개발자를 당황하게 만드는 encodeURIComponent와 encodeURI 선택에 대해 설명합니다. 복사할 수 있는 예제를 통해 설명합니다.
빠른 답변
URL 인코딩(퍼센트 인코딩)은 URL에 안전하지 않거나 예약된 문자를 % 뒤에 UTF-8로 문자 바이트를 나타내는 두 개의 16진수 숫자로 대체합니다. 공백은 %20, 앰퍼샌드는 %26, 악센트 부호가 있는 e(é)는 %C3%A9가 됩니다. URL에 추가하는 개별 값에는 encodeURIComponent를 사용하고, 분리하고 싶지 않은 전체 URL에는 encodeURI를 사용하세요.
URL 인코딩이란 무엇입니까?
URL 인코딩은 제한적이고 보편적으로 안전한 문자 집합만을 사용하여 URL(Uniform Resource Locator)의 문자를 표현하는 방법입니다. URL 표준(RFC 3986)에서는 ASCII 문자 A-Z 및 a-z, 숫자 0-9 및 몇 가지 기호 등 소수의 문자만 문자 그대로 표시되도록 허용합니다. 그 밖의 모든 것(공백, 대부분의 구두점, 영어가 아닌 모든 문자)은 링크 내에서 안전하게 이동하기 전에 퍼센트 인코딩 시퀀스로 변환되어야 합니다.
그 이유는 URL이 많은 시스템을 통과하고 일부 문자가 해당 시스템에 특별한 의미를 갖기 때문입니다. 공백은 자동으로 삭제되거나 +로 바뀔 수 있으며, #은 조각을 시작하고 ? 쿼리 문자열을 시작합니다. 퍼센트 인코딩은 문제가 있는 문자를 "이것은 구분 기호가 아니라 데이터입니다"를 의미하는 코드로 변환하여 모호성을 제거합니다.
예약된 문자와 예약되지 않은 문자
URL 사양은 문자를 그룹으로 나눕니다. 인코딩이 필요한 것과 그대로 두어야 할 것을 정확히 알려주는 것이 무엇인지 알 수 있습니다.
예약되지 않은 문자(인코딩되지 않음)
다음 문자는 URL의 어느 위치에서나 있는 그대로 사용하기에 항상 안전하며 인코딩해서는 안 됩니다.
- 대문자: A-Z
- 소문자: a-z
- 숫자: 0-9
- 4개 기호: 하이픈(-), 밑줄(_), 마침표(.) 및 물결표(~)
예약된 문자(데이터로 사용되는 경우 인코딩)
예약 문자는 URL에서 특별한 역할을 합니다. 즉, 한 부분을 다른 부분과 구분하는 구분 기호 역할을 합니다. 그들은 그 일을 할 때만 안전합니다. 예약된 문자가 구분 기호가 아닌 값 내부에 나타나는 경우 구분 기호로 착각하지 않도록 인코딩해야 합니다.
- 경로 및 권한 구분 기호: / : @
- 쿼리 및 조각 구분 기호: ? # & =
- 하위 구분 기호: ! $ & ' ( ) * + , ; =
예를 들어 https://example.com/search?q=cats&sort=new의 &는 두 개의 쿼리 매개변수를 구분하므로 문자 그대로 유지됩니다. 그러나 "cats & dogs"라는 문구를 검색하는 경우 해당 값 내부의 &는 %26이 되어야 합니다. 그렇지 않으면 서버는 &dogs를 두 번째 매개변수로 읽습니다.
%XX 형식 설명
백분율 인코딩은 하나의 간단한 규칙을 따릅니다. 즉, 백분율 기호(%) 뒤에 두 개의 16진수 숫자가 옵니다. 이 두 자리는 16진수(00~FF, 즉 10진수로 0~255)로 작성된 단일 바이트 값입니다. 문자를 인코딩하려면 해당 바이트 값을 찾아 % 뒤에 씁니다.
- 공백은 10진수로 32이고 16진수로 20이므로 공백은 %20이 됩니다.
- 앰퍼샌드 &는 10진수 38 = 16진수 26이므로 &는 %26이 됩니다.
- 등호 =는 10진수 61 = 3D 16진수이므로 =는 %3D가 됩니다.
- 물음표? 10진수 63 = 16진수 3F입니다. 그렇다면? %3F가 됩니다.
ASCII 범위(0-127)의 문자는 단일 바이트이므로 항상 하나의 %XX 시퀀스로 인코딩됩니다. ASCII 외부 문자는 먼저 UTF-8 바이트(2바이트, 3바이트 또는 4바이트일 수 있음)로 변환되고 각 바이트는 자체 %XX가 됩니다. 이것이 바로 악센트 문자 é(U+00E9)가 %C3%A9로 인코딩되는 이유입니다. UTF-8 형식은 2바이트 C3 및 A9입니다.
encodeURIComponent 대 encodeURI - 각각을 사용하는 경우
JavaScript는 퍼센트 인코딩을 위한 두 가지 내장 함수를 제공하며, 잘못된 것을 선택하는 것은 가장 일반적인 URL 인코딩 실수입니다. 차이점은 예약된 문자를 그대로 두는 것입니다.
encodeURIComponent - 단일 값의 경우
encodeURIComponent는 예약된 구분 기호 / ?를 포함하여 예약되지 않은 문자가 아닌 거의 모든 것을 인코딩합니다. : @ & = + $ #. URL에 삽입하는 단일 데이터(쿼리 매개변수 값 1개, 경로 세그먼트 1개 또는 양식 필드 1개)에 이를 사용하세요. & 및 =를 이스케이프하기 때문에 이를 포함하는 값은 주변 쿼리 문자열을 손상시키지 않습니다.
encodeURI - 전체 URL의 경우
encodeURI는 이미 조립된 완전한 URL을 인코딩하도록 설계되었습니다. 예약된 구분 기호(:, /, ?, #, & 및 =는 변경되지 않은 상태로 전달)를 그대로 유지하므로 URL의 구조가 유지됩니다. 공백과 같이 어디에서도 유효하지 않은 문자만 인코딩합니다. 불법 문자를 포함할 수 있는 전체 URL이 있고 해당 부분을 변경하고 싶지 않은 경우 이 방법을 사용하세요.
경험 법칙
전체가 아닌 부분을 인코딩합니다. 먼저 각 개별 값에 대해 encodeURIComponent를 실행하여 URL을 구축한 다음 &, =, / 및 ?로 결합합니다. 자신을 구분자로 지정하세요. 정리할 전체 URL 문자열을 받은 경우에만 encodeURI에 도달하세요.
두 가지 실제 참고 사항: encodeURIComponent는 문자를 이스케이프하지 않습니다! ' ( ) *이므로 엄격한 파서에서는 수동으로 교체해야 할 수도 있습니다. 그리고 이미 인코딩된 문자열은 절대 인코딩하지 마세요. 그렇게 하면 모든 %가 %25로 바뀌므로 %20은 깨진 링크를 생성하는 전형적인 이중 인코딩 버그인 %2520이 됩니다.
실제 사례
다음은 인코딩 전과 후에 일반적인 문자가 어떻게 보이는지 보여줍니다. 각 줄은 문자로 읽혀집니다. 즉, 인코딩된 형식입니다.
- 공백 - 단어 구분 기호 - %20(+는 쿼리 문자열의 공백에도 사용됩니다. 아래 참조)
- & - 앰퍼샌드 - %26
- = - 등호 - %3D
- ? - 물음표 - %3F
- / - 슬래시 - %2F
- # - 해시/조각 시작 - %23
- + - 더하기 기호 - %2B
- é - 급성 악센트가 있는 e(비ASCII, 2 UTF-8 바이트) - %C3%A9
- 😀 - 이모티콘(4 UTF-8 바이트) - %F0%9F%98%80
공백과 기호를 사용하여 값 인코딩
검색 구문 "cats & dogs = fun"을 단일 쿼리 값으로 전달한다고 가정해 보겠습니다. encodeURIComponent를 실행하면 cats%20%26%20dogs%20%3D%20fun이 생성됩니다. 모든 공백, & 및 =는 이스케이프 처리되므로 전체가 세 개의 개별 매개변수가 아닌 하나의 값으로 처리됩니다.
전체 쿼리 문자열 예
이를 종합하여 쿼리와 카테고리를 사용하는 검색 페이지를 상상해 보세요. 각 값을 개별적으로 인코딩한 다음 URL을 조합합니다.
- 원시 쿼리 값: 고양이 및 개
- 원시 카테고리 값: 애완동물/동물
- 인코딩된 쿼리: cats%20%26%20dogs
- 인코딩된 카테고리: pet%2Fanimals
- 최종 URL: https://example.com/search?q=cats%20%26%20dogs&category=pets%2Fanimals
q=...와 Category=... 사이의 & 및 =는 구분 기호 역할을 하기 때문에 리터럴로 남아 있는 반면, 쿼리 값 내부의 &와 범주 값 내부의 /는 데이터이기 때문에 인코딩됩니다. 이것이 바로 encodeURIComponent를 사용하여 각 값을 인코딩한 다음 직접 조각을 결합하는 것입니다.
공백: %20 또는 +?
URL 경로에서 공백은 항상 %20입니다. 쿼리 문자열에서 이전 양식 인코딩(application/x-www-form-urlencoded)은 공백 대신 +를 사용합니다. 둘 다 공백으로 다시 디코딩되지만 모든 곳에서 교환할 수는 없습니다. 디코딩할 때 소스가 %20 또는 +를 사용했는지 확인하여 원본 텍스트를 올바르게 복원하십시오.
자주 묻는 질문
간단히 말해서 URL 인코딩이란 무엇입니까?
URL 인코딩은 웹 주소에 특수 문자를 %와 두 자리 코드로 대체하여 안전하게 포함하는 방법입니다. URL에는 제한된 문자 집합만 포함될 수 있으므로 공백, 앰퍼샌드 또는 악센트 부호 문자와 같은 다른 모든 문자는 해당 퍼센트 인코딩으로 변환되어(공백은 %20이 됨) 링크가 유효한 상태로 유지됩니다.
URL에 %20이 있는 이유는 무엇입니까?
%20은 공백을 백분율로 인코딩한 형식입니다. URL에는 공백이 허용되지 않으므로 링크에 공백이 포함된 경우(종종 파일 이름이나 검색어에서 유래) %20으로 대체됩니다. 페이지가 로드되면 서버나 브라우저는 %20을 다시 공백으로 디코딩합니다.
encodeURI와 encodeURIComponent의 차이점은 무엇입니까?
encodeURIComponent는 단일 값을 인코딩하고 예약된 구분 기호(& = ? / #)를 이스케이프하여 하나의 쿼리 매개변수 또는 경로 세그먼트에 적합하게 만듭니다. encodeURI는 전체 URL을 인코딩하고 해당 구분 기호를 그대로 유지하므로 주소의 구조가 유지됩니다. 부분에는 encodeURIComponent를 사용하고 전체 URL에는 encodeURI를 사용하십시오.
URL 인코딩이 필요한 문자는 무엇입니까?
예약되지 않은 문자(A-Z, a-z, 0-9 및 - _ )만 가능합니다. ~ - 항상 안전합니다. 공백, 대부분의 구두점, 예약된 구분 기호(/ ? : @ & = + $ , ; # ! ' ( ) *) 및 악센트 부호가 있는 문자 및 이모티콘과 같은 모든 비ASCII 문자 등 값 안에 나타날 때 다른 모든 항목은 인코딩되어야 합니다.
URL 인코딩은 암호화 또는 Base64와 동일합니까?
아니요. URL 인코딩은 암호화가 아니며 보안을 제공하지 않습니다. URL에서 문자를 안전하게 이동할 수 있도록 하는 완전히 되돌릴 수 있는 텍스트 변환이며 누구나 즉시 해독할 수 있습니다. 또한 다른 목적을 위해 바이너리 데이터를 64자 알파벳으로 다시 인코딩하는 Base64와도 다릅니다.
URL로 인코딩된 문자열을 어떻게 디코딩합니까?
프로세스를 반대로 진행합니다. 모든 %XX 시퀀스는 그것이 나타내는 바이트로 다시 변환되고 연속 바이트는 UTF-8로 읽혀 é 또는 emoji와 같은 문자를 복구합니다. JavaScript에서는 decodeURIComponent가 이 작업을 수행합니다. URL 디코더 도구는 브라우저에서 동일한 작업을 수행하며 입력에 단독 %와 같은 잘못된 시퀀스가 있는 경우 명확한 오류를 표시합니다.
URL을 즉시 인코딩 또는 디코딩
무료 URL 인코더/디코더를 사용하여 텍스트를 퍼센트 인코딩하거나 인코딩된 URL을 디코딩하세요. 한 번의 클릭으로 encodeURIComponent와 encodeURI 간을 전환하면 모든 것이 브라우저에서 실행됩니다.