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 は含む文字列を表すもので、作者の意図したパスの版を推測しません。作成後も実際の配布物の確認が必要です。

サイト管理者として口頭で伝えやすい住所が必要なら、安定したパスか意図的な転送を作り、検証します。きれいな表記を書くだけでは存在しない宛先は生まれません。印刷や送信前に承認住所、使用場所、確認内容を記録します。実用上の原則は、ラベルはデザインに合わせても、住所は資源責任者が機能する代案を確認するまで維持することです。