개발자 도구 · URL 인코더 및 디코더
encodeURI vs encodeURIComponent: 각각 남겨두는 문자
· 작동 원리
URL 인코딩 자바스크립트 개발자 워크플로
두 JavaScript 함수는 정확히 11자 차이가 나며, 잘못된 함수를 선택하면 URL이 깨지거나 값을 이스케이프하지 못합니다. 이 게시물에서는 세트에 대해 자세히 설명하고 기억할 수 있는 규칙을 제공합니다.
'R&D'의 &가 쿼리를 분할했기 때문에 모든 것을 반환한 검색 — 잘못된 함수의 구체적인 버그
코드가 ?q=R&D를 직접 구성하는 경우 R&D를 검색하면 실수로 R에 대한 결과가 반환될 수 있습니다. 앰퍼샌드는 쿼리 매개변수 간의 구분 기호입니다. 값을 인코딩하지 않으면 q의 일부로 보존되지 않습니다. 작은 부분에 대해 encodeURI를 선택하는 것은 서버 버그가 아니라 오류입니다. 애플리케이션 코드에서 가장 안전한 옵션은 URLSearchParams인 경우가 많지만 두 가지 JavaScript 기본 요소를 이해하면 기존 코드를 훨씬 쉽게 디버깅할 수 있습니다.
두 기능이 공유하는 것 - 절대 건드리지 않는 예약되지 않은 세트와 둘 다 적용하는 UTF-8 퍼센트 인코딩
두 방법 모두 ASCII 문자, 숫자 및 예약되지 않은 구두점( _ )을 그대로 둡니다. ! ~ * ' ( )는 JavaScript의 인코딩 규칙에 따라 변경되지 않습니다. 퍼센트 삼중항을 작성하기 전에 ASCII가 아닌 문자를 UTF-8 bytes로 변환합니다. é는 단일 라틴어-1 byte이 아닌 %C3%A9가 됩니다. 또한 공백을 %20으로 인코딩합니다. 퍼센트 인코딩은 URI의 구조를 보존하는 것입니다. HTML 이스케이프, 입력 유효성 검사 또는 수신 페이지의 악성 스크립트에 대한 보호가 아닙니다.
11개의 문자만 encodeURI로 유지됩니다 — ; , / ? : @ & = + $ # 그리고 각각이 URL에서 구조적 의미를 갖는 이유
encodeURI는 encodeURIComponent가 인코딩하는 11개의 구조 문자를 추가로 보존합니다. , / ? : @ & = + $ #. 완전한 주소의 경우 슬래시와 물음표만 남겨두면 경로와 쿼리 구문이 유지됩니다. 쿼리 값의 경우 & 또는 =를 사용하면 매개변수 목록이 변경되고, 이스케이프 처리되지 않은 #을 사용하면 조각이 시작될 수 있습니다. 하나는 전체 주소에 대한 것이고 다른 하나는 해당 주소 내부의 구성 요소에 대한 것이기 때문에 기능이 정확하게 다릅니다.
다음과 같은 규칙이 적용됩니다. 값은 encodeURIComponent를 가져오고, 전체 URL은 encodeURI를 가져오며, '완전한 URL'이 생각보다 희귀한 이유
값은 거의 항상 encodeURIComponent를 얻습니다. 완전하고 이미 구조화된 주소는 encodeURI의 덜 일반적인 경우입니다. 프로그래밍 방식으로 생성하는 URL의 경우 인코딩된 부분과 원시 부분을 혼합하는 대신 URL API를 사용하여 경로 및 검색 매개변수를 처리합니다. encodeURIComponent를 사용하여 전체 URL을 인코딩하지 마십시오. 그러면 슬래시와 콜론이 계속 구분 기호로 작동할 것으로 예상됩니다. 반대로, encodeURI를 통해 사용자의 쿼리 용어를 제공하지 말고 해당 앰퍼샌드를 활성 상태로 두십시오.
실제 예: 두 함수를 통한 동일한 문자열 — 공백, &, / 및 악센트가 있는 값에 대한 출력 테이블
R&D/카페를 하나의 쿼리 값으로 삼습니다. encodeURIComponent는 R%26D%20%2F%20caf%C3%A9를 반환하여 앰퍼샌드와 슬래시를 보호합니다. encodeURI는 구조적 구두점을 유지하면서 R&D%20/%20caf%C3%A9를 반환합니다. 순진한 ?q= 접두사는 이제 의도하지 않은 구분 기호를 생성합니다. 둘 다 공백과 악센트를 인코딩하므로 "hello world"만 사용하는 테스트에서는 중요한 차이점을 놓칩니다. ToolAcre에서 생성된 문자열을 비교한 다음 URL 파서에 붙여넣고 쿼리 매개변수가 몇 개나 나타나는지 확인하세요.
일반적인 실수 - encodeURIComponent로 전체 URL을 인코딩하고 잘못된 대응으로 디코딩
전체 URL을 하나의 구성 요소로 인코딩하면 소비자가 ://를 예상하는 %3A%2F%2F가 생성됩니다. 유효성을 검사하기 전에 전체 주소를 디코딩하면 새로운 의미를 지닌 예약된 구분 기호가 다시 도입될 수 있습니다. 또한 이미 %26을 포함하는 값을 이중 인코딩하지 마세요. 백분율 기호 자체가 %25가 될 수 있으므로 두 번째 디코드 레이어의 의미가 다시 바뀔 수 있습니다. 구성 요소에 대해 encodeURIComponent와 decodeURIComponent를 쌍으로 구성하고 잘못된 백분율 이스케이프를 입력 오류로 처리합니다.
여기서 다루지 않는 내용 — +를 사용한 양식 인코딩 및 URLSearchParams를 사용한 URL 작성
HTML 양식 쿼리 인코딩은 application/x-www-form-urlencoded의 공백에 더하기 기호를 사용하는데, 이는 이 두 함수의 %20 출력과 다릅니다. URLSearchParams는 이러한 양식 규칙을 처리합니다. 이 문서에서는 경로 정규화, 유니코드 호스트 이름 변환 또는 디코딩된 URL을 요청해도 안전한지 결정하는 내용은 다루지 않습니다. URL 인코딩은 인증 정책이 아닌 표현 단계입니다.
요약: 전체가 아닌 부분을 인코딩합니다. URL 인코더 및 디코더가 두 모드를 모두 표시하여 입력에서 차이점을 확인할 수 있는 방법
기억에 남는 경계는 부분 대 전체입니다. 매개변수 값은 부분이므로 encodeURIComponent 또는 URLSearchParams를 사용하십시오. URL 인코더 및 디코더는 동일한 문자열에 대한 두 브라우저 기능을 모두 표시하고 실험을 로컬로 유지합니다. 두 개의 인코더가 상호 교환 가능하다고 결정하기 전에 &, =, #, 슬래시 및 악센트가 포함된 입력을 테스트하십시오.