개발자 도구 · URL 인코더 및 디코더
URL 생성자가 인코딩하는 것: 브라우저의 백분율 인코딩 세트
· 작동 방식
URL 인코딩 자바스크립트 뭐야 웹 API
URL API는 URL의 어느 부분에 있는지에 따라 일부 문자를 자동으로 퍼센트 인코딩하고 다른 문자는 그대로 둡니다. 이 게시물에서는 WHATWG 인코딩 세트와 출력을 예측하는 방법을 설명합니다.
%20이 된 공간과 | 그대로 유지됨 — new URL()이 경로를 부분적으로 인코딩한 구체적인 사례
새 URL("https://example.com/hello world")이 실행되면 해당 공간은 자동으로 %20이 됩니다. 그러나 새로운 URL("https://example.com/hello|world")은 파이프를 그대로 유지합니다. 이 차이는 무작위가 아닙니다. WHATWG URL 표준은 각 URL 구성 요소에 대해 인코딩할 별도의 문자 집합을 정의합니다. 경로, 쿼리, 조각 및 사용자 정보는 각각 고유한 규칙을 갖습니다. 이러한 집합을 이해한다는 것은 생성자가 무엇을 할 것인지 예측한다는 것을 의미합니다.
공간은 HTTP를 통해 안전하지 않고 가독성이 떨어지기 때문에 퍼센트 인코딩이 필요합니다. 파이프는 다릅니다. 구조를 분할하는 예약된 문자가 아니므로 브라우저는 이를 그대로 둡니다. 안전성과 가독성 사이의 경계는 추측이 아닌 WHATWG에 의해 그려집니다. "hello world"를 테스트하면 인코딩이 표시됩니다. "hello|world"를 테스트하면 각 URL 부분의 경계가 드러납니다.
하나의 URL, 여러 인코딩 세트 — 경로, 쿼리, 조각 및 사용자 정보 각각에는 이스케이프할 자체 문자 목록이 있습니다.
하나의 URL에는 각각 고유한 인코딩 규칙이 있는 여러 지역이 포함되어 있습니다. 경로는 한 세트를 따르고, 다른 세트를 쿼리하고, 세 번째는 조각, 네 번째는 userinfo를 따릅니다. 경로 및 쿼리에서 공백은 %20이 됩니다. 등호는 쿼리에 남아 키와 값을 구분하지만 encodeURIComponent는 이를 %3D로 바꿉니다. URL 생성자는 해당 컨텍스트를 알고 각 부분에 대해 올바른 규칙을 적용합니다.
인코딩 세트는 정확하고 작습니다. Path에는 자체 문자 목록이 있습니다. 쿼리에는 비슷하지만 다른 목록이 있습니다. 이는 어떤 문자가 구조적 의미를 갖고 있는지를 반영합니다. 슬래시는 경로 세그먼트를 분할하므로 encodeURIComponent는 이를 %2F로 인코딩합니다. 조각에서 슬래시는 아무 것도 깨지지 않고 존재할 수 있습니다. WHATWG 규칙을 이해한다는 것은 코드를 실행하지 않고 출력을 예측하는 것을 의미합니다.
퍼센트 인코딩이 단방향인 이유: 인코딩된 상태는 그대로 유지됩니다.
URL 생성자는 단방향 정규화를 수행합니다. "%20"을 새 URL에 전달하면 변경되지 않은 %20이 생성됩니다. 생성자는 이를 이미 인코딩된 것으로 인식하고 그대로 둡니다. 이것이 이중 인코딩이 중요한 이유입니다. 한 번 인코딩하고 생성자를 통과하면 인코딩이 유지됩니다. 생성자는 디코딩, 재해석 및 재인코딩을 수행하지 않습니다. 앞으로 읽습니다.
이 단방향 속성은 URL.href를 표준으로 신뢰하는 응용 프로그램에 영향을 미칩니다. 사용자 입력을 경로와 연결하면 입력이 정규화되지만 디코딩되지는 않습니다. "my+file"과 같은 값은 그대로 유지되거나 일부 상황에서는 "my%2Bfile"이 됩니다. decodeURIComponent를 사용하는 이후 코드는 양식 데이터에서 플러스를 공백으로 읽을 수 있습니다. 생성자는 한 번 정규화됩니다. 그 후에는 값이 고정됩니다.
작업된 예: new URL()을 통해 동일한 지저분한 문자열을 전달하고 href, pathname 및 searchParams 읽기 — 세 가지 다른 보기
"hello world&foo=bar|test#anchor"를 가져와서 다른 구성 요소가 포함된 새 URL에 넣습니다. 공간은 모든 곳에서 %20이 됩니다. 경로의 앰퍼샌드는 그대로 유지되지만(구조적 의미는 없음) 쿼리에서도 그대로 유지됩니다(매개변수를 분리하므로 정규화하면 "q="와 "foo=bar" 사이의 경계가 사라집니다). 파이프와 해시는 위치에 따라 다르게 동작합니다.
href, pathname 및 searchParams를 읽으면 세 가지 다른 보기가 표시됩니다. pathname은 구성표, 호스트 또는 쿼리 없이 인코딩된 경로를 표시합니다. searchParams는 디코딩된 매개변수를 제공하므로 양식 데이터의 "hello+world"는 공백이 됩니다. 검색 속성은 리터럴 문자열을 유지합니다. href는 정규화된 완전한 URL을 보여줍니다. 이들은 하나의 객체에 공존합니다. 어떤 것을 사용할지는 다음 단계에 따라 다릅니다.
URLSearchParams 및 양식 인코딩 규칙 — 경로 이름이 %20을 생성하는 동안 공백에 대해 +를 생성하는 이유
URLSearchParams는 양식 인코딩을 적용합니다. 공백은 %20이 아니라 플러스가 됩니다. 새로운 URLSearchParams({q: "hello world"})는 "q=hello%20world"가 아닌 "q=hello+world"를 생성합니다. 이것이 역사적 적용/x-www-form-urlencoded 규칙입니다. 그러나 이 문자열을 새 URL에 대한 원시 쿼리로 전달하면 플러스는 플러스로 유지됩니다. URLSearchParams만이 이를 공백으로 디코딩합니다. 생성자는 보이는 것에 충실합니다.
이 더하기 기호 차이로 인해 일반적인 버그가 발생합니다. 주소 표시줄의 URL은 공백으로 %20을(를) 사용합니다. 양식 데이터는 플러스를 사용합니다. URLSearchParams.get 대신 decodeURIComponent(문자 그대로 플러스로 읽음)를 사용하여 디코딩하는 경우 공백은 플러스 문자가 됩니다. URL 인코더 및 디코더는 "hello+world"를 붙여넣고 구성 요소와 양식 모드를 비교하여 공백이 나타나는 위치를 확인하는 두 가지를 모두 표시합니다.
encodeURI와 비교 — 둘이 일치하는 부분과 갈라지는 부분
URL 생성자와 encodeURIComponent는 다른 도구입니다. encodeURIComponent는 예약되지 않은 문자, 숫자 및 - _ 를 제외한 거의 모든 것을 인코딩합니다. ! ~ * '( ). 맥락이 없다고 가정합니다. URL 생성자는 실제 URL을 구문 분석하고 구성 요소별로 WHATWG 규칙을 적용합니다. encodeURIComponent는 "hello/world""를 "hello%2Fworld"로 바꿉니다. 새 URL은 슬래시를 경로 구분 기호로 간주합니다. 동일한 입력, 다른 출력.
조각을 연결하여 URL을 작성할 때 encodeURIComponent를 사용하십시오. 전체 또는 부분 URL의 경우 URLSearchParams 또는 URL 생성자를 사용하세요. 전체 URL에 encodeURIComponent를 사용하지 마십시오. 당신은 계획을 망칠 것입니다. 결과를 의도와 비교하십시오. 브라우저는 URL 구조 의견을 시행하고 새 URL이 이를 구현합니다. URL 인코더 및 디코더는 두 보기를 나란히 표시합니다.
여기서 다루지 않는 내용 — 호스트 구문 분석, IDNA 및 특수 대 비특수 체계
WHATWG URL 표준은 정보의 원천이지만 이를 읽으려면 인내심이 필요합니다. 인코딩 세트는 일반 목록이 아닌 알고리즘 조각으로 정의됩니다. 실제로는 세트를 암기하는 것보다 원리를 이해하는 것이 더 중요합니다. Path는 더 많은 문자를 허용합니다(슬래시는 구조적입니다). 쿼리에는 자체 규칙이 있습니다. 조각에는 제한이 가장 적습니다(클라이언트 측에서 처리되고 서버로 전송되지 않음). 각 구성 요소에는 고유한 규칙이 있습니다. 이것을 알면 어디를 봐야 할지 알 수 있습니다.
정규화와 검증은 서로 다른 경계입니다. 생성자는 정규화합니다. 퍼센트 인코딩을 정리하고, 구성 요소 규칙을 적용하고, 정식 형식을 제공합니다. 유효성을 검사하지 않습니다. 잘못된 문자가 발생하지만 빈 호스트는 허용됩니다. 생성자는 형식에는 엄격하지만 해석에는 관대합니다. 정확한 사양 준수를 위해서는 WHATWG의 백분율 인코딩 바이트 섹션을 읽어보세요. 일상적인 건물의 경우 URLSearchParams, URL API 및 실제 예제를 사용하세요.
요약: 파서에는 의견이 있습니다. URL 인코더 및 디코더가 값 또는 주소의 일반 백분율 인코딩을 표시하여 브라우저가 생성한 것과 비교할 수 있는 방법
여기서 지원되지 않는 WHATWG 기능에는 IDNA 변환(국제 도메인 이름을 ASCII로)을 통한 호스트 구문 분석 및 특수 대 비특수 체계 처리가 포함됩니다. 파일: URL은 이중 슬래시 권한을 사용합니다. 데이터: URL은 그렇지 않습니다. 생성자는 이러한 규칙을 적용합니다. 호스트 이름을 변환하고 특수 상태를 결정하는 것은 퍼센트 인코딩이 아닌 사양 읽기에 속합니다. 이는 다양한 구성표에 걸쳐 URL을 구축할 때 중요합니다.
브라우저 해석과 기대치를 비교하여 URL 구성을 테스트하십시오. 새 URL로 빌드하고 중요한 속성을 읽어보세요. 완전한 양식은 href, 경로는 pathname, 원시 쿼리는 검색, 디코딩은 searchParams. 출력 결과가 놀라우면 URL 인코더 및 디코더에 붙여넣고 단계별로 변환을 따르세요. 이 도구는 원시 인코딩과 함께 정규화된 출력을 표시하여 차이점을 드러냅니다. WHATWG 세트를 이해한다는 것은 브라우저 선택과 이를 사용하는 방법을 이해한다는 것을 의미합니다.