URL을 소문자로 바꾸면 열리지 않을 때 보존할 것

보이는 글자가 다른 주소를 숨길 수 있습니다

행사 프로그램을 보내려는데 원래 링크는 문서를 열고 게시된 버전은 같아 보여도 실패합니다. 파일을 다시 올리기 전에 게시된 링크의 실제 주소를 복사해 원본과 비교하세요. 화면의 글자만 읽어서는 부족합니다. 편집기는 한 라벨을 표시하면서 다른 주소를 연결할 수 있습니다. 문제는 파일 자체가 아니라 저장된 목적지에 있을 수 있습니다.

살펴본 질문에는 URL 대소문자에 대한 의문과 표시 글자는 유지되지만 실제 목적지가 소문자로 바뀐 사례가 있습니다. 실제 필요를 보여 주는 자료이지 모든 플랫폼에 현재 같은 결함이 있다는 뜻은 아닙니다. 이 안내는 공개 프로그램과 WikiURL로 차이를 찾습니다. 글자 변경이 언제나 오류를 낸다고 가정하거나 검사기가 다른 사이트 설정을 자동으로 고친다고 주장하지 않습니다.

도메인과 경로의 규칙은 다릅니다

RFC3986은 스킴과 호스트 이름이 대소문자를 구분하지 않으며, 다른 요소는 특별한 반대 규칙이 없으면 구분한다고 설명합니다. 따라서 EXAMPLE.invalid를 example.invalid로 바꾸는 것은 Guias를 guias로, AB12를 ab12로 바꾸는 것과 다릅니다. 두 예시는 작동하지 않는 가상 도메인을 씁니다. 연결 테스트 전에 허가된 실제 목적지로 바꾸세요. 여기서는 텍스트 비교에만 사용합니다.

서버가 경로 해석과 애플리케이션 매개변수 처리를 결정합니다. 일부 사이트는 다른 표기를 리디렉션하지만 다른 사이트는 별도 자료나 오류를 줄 수 있습니다. 도메인이 소문자를 허용한다고 경로도 그렇다고 추정하지 마세요. Google Search도 /APPLE과 /apple을 서로 다른 URL로 다룬다고 설명합니다. 관리 사이트의 일관성에는 도움이 되지만 외부 제공자의 링크를 마음대로 바꿀 수 있다는 뜻은 아닙니다.

https://EXAMPLE.invalid/Guias/PlanA.pdf?edicion=AB12
https://example.invalid/guias/plana.pdf?edicion=ab12

변환하기 전에 구성 요소를 비교하세요

JavaScript 예시는 URL로 호스트, 경로, 쿼리를 나눕니다. MDN은 pathname을 경로 요소로 설명하고 쿼리 매개변수는 포함되지 않는다고 밝힙니다. 실행은 문자열만 분석하며 가상 사이트에 연결하지 않습니다. 호스트는 정규화되지만 Guias, PlanA, AB12는 표기를 유지합니다. 이 구분은 도메인과 자료 식별자를 혼동하지 않고 두 복사본에서 무엇이 달라졌는지 정확히 지목하도록 돕습니다.

주소 전체에 toLowerCase를 적용해 정리하지 마세요. 다른 애플리케이션의 식별자라면 글자 조합이 중요한지 알 수 없습니다. 매개변수 이름과 값도 발행자가 제공한 대로 보존하세요. 새로운 자체 캠페인 라벨은 만들 때 표기를 정할 수 있지만 이미 자료를 가리키는 링크를 사후에 변환하는 것과 다릅니다. 변경본만 남기지 말고 원본도 보관해 나중에 비교할 수 있게 하세요.

const u = new URL("https://EXAMPLE.invalid/Guias/PlanA.pdf?edicion=AB12");
console.log(u.hostname); // example.invalid
console.log(u.pathname); // /Guias/PlanA.pdf
console.log(u.search);   // ?edicion=AB12

공개 버전을 WikiURL로 각각 확인하세요

비밀이 없는 공개 주소라면 WikiURL URL 검사기에서 HTTP 상태와 감지된 최종 목적지를 확인하세요. 원본과 변경본 비교가 필요하면 따로 검사하세요. 비공개 관리 링크, 토큰, 기밀 주소는 제출하지 마세요. 가진 구체적인 버전만 시험하고 식별자를 열거하거나 다른 사람의 자료를 찾지 마세요. 응답 차이는 문제의 시작점을 찾는 데 도움이 되지만 그 자체가 원인 증명은 아닙니다.

원본은 작동하고 소문자 복사본이 오류라면 배포 전에 원래 표기를 복원하세요. 모든404를 대소문자 탓으로 돌리지 마세요. 자료 삭제나 경로 복사 실수도 원인일 수 있습니다. 둘 다200이라면 페이지를 열어 프로그램, 날짜, 내용을 확인하세요. 상태만으로 동등성을 증명할 수 없습니다. 리디렉션이 있으면 감지된 끝점을 본 뒤 독자의 브라우저에서 실제 자료를 확인하고 숫자만으로 판단하지 마세요.

라벨만 고치지 말고 버튼 목적지를 고치세요

메시지를 작성하는 도구의 링크 편집에서 버튼 글자뿐 아니라 주소 필드를 확인하세요. HTML 예시는 href와 PDF 라벨을 분리합니다. 가상 주소는 사용 전에 바꿔야 합니다. 짧거나 대문자인 라벨을 보여도 실제 주소의 글자는 바꿀 필요가 없습니다. 중요한 것은 저장한 목적지가 승인된 주소와 일치하는 것입니다. 시각적 표시와 실제 연결은 각각 확인해야 합니다.

저장하거나 게시한 후 최종 링크 주소를 다시 복사하고 독자가 사용할 환경에서 여세요. 내보낸 문서라면 내보낸 파일을, 메시지라면 받은 메시지를 확인하세요. 보내기 전 편집기의 내용은 게시 결과를 증명하지 않습니다. 예상치 못한 변환이 있으면 해당 필드를 고치거나 플랫폼 담당자에게 문의하세요. 관찰한 변화의 증거로 두 버전을 보관하고 실제 배포본에서 수정 결과를 다시 시험하세요.

<a href="https://example.invalid/Guias/PlanA.pdf?edicion=AB12">PDF</a>

확인한 주소로 짧은 링크나 QR을 만드세요

목적지가 맞으면 WikiURL에 정확히 붙여 넣어 공유할 짧은 링크나 QR을 만드세요. 도구가 돌려준 표기도 유지하고 최종 결과를 시험하세요. 디자인 때문에 URL 전체를 대문자로 바꾸거나 어떤 짧은 코드든 글자를 바꿀 수 있다고 가정하지 마세요. QR은 담긴 텍스트를 나타낼 뿐 작성자가 의도한 경로 버전을 추측하지 않습니다. 생성 후에도 실제 배포물을 확인해야 합니다.

사이트 관리자이고 말로 전하기 쉬운 주소가 필요하다면 안정적인 경로나 의도적인 리디렉션을 만들고 확인하세요. 보기 좋은 표기를 적는 것만으로 없는 목적지가 생기지는 않습니다. 인쇄하거나 보내기 전에 승인 주소, 사용 위치, 검사 내용을 기록하세요. 실용적인 원칙은 라벨은 디자인에 맞추되 주소는 자료 담당자가 작동하는 대안을 확인할 때까지 그대로 보존하는 것입니다.