URL 파서

스킴(프로토콜), 호스트명, 포트, 경로, 쿼리 문자열 파라미터(테이블 형태), 프래그먼트(해시), 사용자명, 비밀번호, 오리진, 검색 문자열을 추출합니다.

네. 모든 URL 인코딩 문자(%20, %3A 등)는 가독성을 위해 출력에서 자동으로 디코딩됩니다.

절대 URL(http:// 또는 https://로 시작)에서 가장 잘 작동합니다. 상대 URL에는 기준 URL이 필요하며 브라우저가 이를 자동으로 제공합니다.

URI는 RFC 3986이 정의한 상위 개념입니다: 스킴, 경로, 쿼리, 프래그먼트로 구성된 식별자. URL은 리소스의 위치를 나타내는 URI(https://ezparser.com/url-parser)이고, URN은 위치 없이 이름을 붙입니다(urn:isbn:0451450523). 일상적인 웹 작업에서 거의 항상 URL을 의미합니다.

예약되지 않은 문자(A-Z, a-z, 0-9, - . _ ~)가 아닌 모든 바이트는 % 뒤에 두 자리 16진수로 표기됩니다: 공백은 %20, UTF-8의 e-acute는 %C3%A9가 됩니다. / ? # & = 같은 예약 문자는 URL 구조에서 의미를 담당하므로 데이터로 사용될 때는 인코딩해야 합니다. 쿼리 문자열에서 오래된 폼 인코더는 공백을 +로 매핑하기도 합니다 - 이 도구는 두 형태를 모두 디코딩합니다.

https://user:[email protected]:8443/v2/users?page=2#results는 스킴(https), userinfo(user:pass@), 호스트(api.example.com), 포트(8443), 경로(/v2/users), 쿼리(page=2), 프래그먼트(#results)로 나뉩니다. RFC 3986 섹션 3이 문법을 정의하며; 이 파서가 모든 구성 요소에 라벨을 붙여 줍니다.

네 - RFC 3986 섹션 6이 정규화를 정의합니다: /a/./b는 /a/b로, /a/../b는 /b로 정규화되고 빈 세그먼트 //는 /로 수축합니다. 브라우저와 HTTP 클라이언트는 요청 전에 이를 적용하기 때문에 점 세그먼트만 다른 URL은 대개 같은 리소스에 도달합니다. 스킴 기반 정규화는 호스트를 소문자로 바꾸고 기본 :443 포트를 제거합니다.

RFC 3986은 제한을 두지 않습니다. 실무에서 Chrome은 약 2MB를 허용하지만 대부분의 서버는 요청 줄을 8KB 근처로 제한하며(Apache 기본 LimitRequestLine은 8190바이트), Twitter/X 같은 API는 2048자 제한을 문서화합니다. URL을 2000자 이하로 유지하는 것이 공유와 SEO에서 관례적인 안전 범위입니다.