URL 파서 무료 온라인: URL 분해 분석

A 링크 디버깅, UTM 확인, API 구조, 리다이렉션 분석.

A 저희 파서는 일반적인 URL 인코딩 문자를 자동으로 디코딩합니다. 예를 들어, 쿼리에 공백이 포함된 경우 원본 URL에서는 '%20'으로 표시되지만, 파싱된 결과에서는 공백으로 표시됩니다. 이는 폼이나 API 요청 디버깅에 매우 유용합니다.

A 브라우저는 서버 측 도구로 URL을 보내기 전에 해시 조각을 제거하는 경우가 많습니다. 저희 파서는 사용자가 붙여넣은 URL을 그대로 읽습니다. 주소 표시줄에서 복사했는데 해시가 없다면 브라우저가 친절을 베푼 겁니다. 대신 코드나 텍스트 파일에서 원시 URL을 붙여넣어 보세요. 약 30%의 사용자가 이 점을 간과합니다.

A 물론입니다. 데이터 엔지니어는 종종 로그나 데이터베이스에서 원시 URL을 CSV 파일로 덤프합니다. 이 파서는 URL을 다시 쓰지 않지만, 어떤 부분이 잘못되었는지 강조 표시합니다. 예를 들어, 쿼리 문자열에 물음표가 두 개 있으면 두 번째 것이 경로의 일부로 처리됩니다. 이것이 소스를 수정해야 한다는 신호입니다. 최상의 결과를 위해 URL을 한 번에 하나씩 붙여넣으세요.

A 네, 완전히 동일합니다. 모든 분석은 브라우저 안에서 처리되며, 데이터가 외부로 전송되지 않습니다. 모바일에서는 결과 표가 자동으로 세로로 쌓여서 표시됩니다. 글자가 작게 느껴지면 핀치 줌으로 확대하세요. 개발 중에 폰으로 URL을 디버깅할 때 특히 유용합니다.

A 네, 하지만 이상한 결과가 나올 수 있습니다. 당사 파서는 프로토콜이 없으면 http://를 자동으로 추가합니다. "example.com/page?q=test"를 붙여넣으면 프로토콜은 http, 호스트는 example.com으로 표시됩니다. 대부분 잘 작동하지만 "ftp://files.example.com" 같은 URL을 접두사 없이 넣으면 전체가 경로로 처리됩니다. 정확한 분해를 위해 항상 프로토콜을 포함하세요.

A 브라우저가 기본 포트를 숨기기 때문입니다. HTTP는 80번, HTTPS는 443번 포트를 사용하지만 주소창에 표시되지 않습니다. 이 도구는 실제 연결에 사용된 포트를 보여줍니다. "https://example.com:443/page"를 붙여넣으면 브라우저가 숨겼더라도 443번 포트가 표시됩니다. 반대로 포트를 완전히 생략하면 "지정되지 않음"으로 표시됩니다. "http://example.com:8080"로 테스트해보면 차이를 확실히 알 수 있습니다.

A 네, 하지만 먼저 퍼센트 인코딩된 버전이 표시됩니다. ñ은 원시 URL에서 %C3%B1로 변환되고, 도구는 그 인코딩을 그대로 보여줘요. 실제 문자는 쿼리 파라미터 테이블에서 디코딩된 상태로 확인할 수 있습니다. 브라우저 주소창에서 그대로 붙여넣는 게 가장 정확해요. 'https://münchen.de'로 테스트해보면 차이를 바로 알 수 있습니다.

A 물론입니다. 사실 가장 흔한 사용 사례 중 하나예요. 단축된 표시 텍스트가 아니라 이메일 소스 코드에서 전체 URL을 붙여넣으세요. 각 UTM 파라미터, 클릭 ID, 캠페인 트래커가 모두 개별적으로 표시됩니다. 마케터 분들이 캠페인 URL 감사에 매우 유용하게 사용합니다. 팁 하나: 쿼리 문자열에 '?'와 '&'가 제대로 섞여 있는지 확인하세요. 이메일 플랫폼 중 약 15%가 이 부분을 엉망으로 만듭니다.

A 아니요, 둘을 혼동하면 골치 아파집니다. 파싱은 URL을 호스트, 경로, 쿼리 같은 구조적 부분으로 나눕니다. 디코딩은 퍼센트 인코딩된 문자(%20, %C3%A9)를 읽을 수 있는 텍스트로 변환합니다. 이 도구는 둘 다 하지만 별도로 처리합니다. 기본 분석에는 원시 인코딩 값이 보이고, 쿼리 파라미터 표에는 디코딩된 버전이 나옵니다. 예: 'https://site.kr/search?q=hello%20world'는 원시값이 'hello%20world'로 표시되고 표에는 'hello world'로 나타납니다. 경로에 %2F가 포함된 URL을 테스트해 보세요. 디코딩된 슬래시가 경로 구분자처럼 보이지만 실제로는 아닌 흔한 함정입니다.