본문으로 건너뛰기
bobob

URL 파서

URL의 protocol, host, path, query, hash를 분해해 redirect와 canonical 문제를 확인해요.

브라우저에서만 처리입력값이 서버로 가지 않아요.

입력과 결과

입력한 내용은 이 브라우저에만 저장돼요. 다시 열면 마지막 작업을 불러올 수 있어요.

이럴 때 써요

  • URL의 protocol, host, path, query, hash를 분해해 redirect와 canonical 문제를 확인해요.
  • 브라우저 로컬 방식으로 입력을 다루며 복사 전 결과를 확인해요.
  • URL 파서와 관련 도구를 이어서 사용해 작업 흐름을 줄여요.

예제

일반 입력
https://example.com/tools?q=json#top
URL 파서를 사용하기 전에 이 예제로 입력 흐름을 확인하세요.
일반 출력
프로토콜 / 호스트 / 경로 / 정리된 URL / 중복 신호 / 대표 URL 보고서
복사하기 전에 결과 형태와 다음 검토 지점을 확인하는 예제예요.
추가 예제
https://example.com/path?utm_source=newsletter&id=123#details
복사하기 전에 결과 형태와 다음 검토 지점을 확인하는 예제예요.
추가 예제
https://app.example.com/callback?state=a%20b&code=redacted
복사하기 전에 결과 형태와 다음 검토 지점을 확인하는 예제예요.
추가 예제
https://example.com/page?utm_source=x https://example.com/page
복사하기 전에 결과 형태와 다음 검토 지점을 확인하는 예제예요.

자주 하는 실수

  • URL의 protocol, host, path, query, hash를 분해해 redirect와 canonical 문제를 확인해요.
  • 브라우저 로컬 처리 방식과 실제 입력 구조가 맞지 않으면 결과를 그대로 믿기 어려워요.
  • 복사한 값에 운영 비밀값, 고객 데이터, 내부 URL이 섞여 있으면 공유 전에 제거해야 해요.

복사하기 전에

  1. 1원본 입력과 결과 형태를 한 번 더 비교해요.
  2. 2대상 런타임, 인코딩, 시간대, 보안 정책 차이를 확인해요.
  3. 3URL 파서 결과가 다음 단계에 맞는지 관련 도구로 이어서 검토해요.

참고 자료

  • URL 을 쪼개는 규칙은 RFC 3986 에 있어요

    scheme, authority(사용자·호스트·포트), path, query, fragment 로 나뉘고 구분자가 정해져 있어요. fragment(`#` 뒤)는 **서버로 전송되지 않아요** — 서버 로그에 안 남는 이유예요.

    기준 RFC 3986

  • 브라우저와 서버가 같은 URL 을 다르게 볼 수 있어요

    브라우저는 WHATWG URL 표준을 따르는데, 이쪽은 RFC 3986 보다 관대해서 공백·한글을 자동으로 정규화해요. 그래서 주소창에 보이는 모양과 실제로 전송되는 퍼센트 인코딩 문자열이 달라요.

    기준 WHATWG URL Standard

자주 묻는 질문

URL 파서 입력값은 어디에서 처리되나요?

가능한 작업은 브라우저에서 처리돼요. 운영 비밀값이나 고객 데이터는 넣지 않는 기준은 그대로 유지하세요.

결과를 그대로 운영에 써도 되나요?

복사하기 전에 대상 런타임, 인코딩, 시간대, 보안 정책처럼 환경별 차이를 한 번 더 확인하세요.