日本語のページタイトルをそのままURLに使うと、パス部分が読めない記号の羅列に変わってしまう — これはバグではなく、URLの仕様上避けられない現象で、その仕組みを知っておくとログ調査やリンク共有で無駄に戸惑わずに済む。
URLの構成要素
- プロトコル（scheme） —
https://、リソースへの接続方法を指定する。 - ホスト —
example.co.jp、サーバーのドメイン名。 - ポート — 省略可能、HTTPSでは443、HTTPでは80がデフォルト。
- パス —
/記事/ネットワーク、日本語を含むことがある。 - クエリ文字列 —
?以降、utm_sourceなど広告計測用パラメータが多い。 - フラグメント —
#以降、ブラウザだけが処理する。
なぜ日本語のパスが延々と%記号になるのか
ひらがな・カタカナ・漢字はURLの安全な文字集合に含まれていないため、各文字はまずUTF-8で複数バイトに変換され、そのバイトごとに%E3%81%82のような表記に置き換えられる。「記事」のようなたった2文字の単語でも、エンコード後は20文字を超える%表記の羅列になり、SNSやLINEでURLを共有すると本来より大幅に長く見える原因になる。
短縮URLの裏にある本当のクエリ文字列
ブログやSNSでよく使われる短縮URLサービスは、実際にはリダイレクト先の長いURLに広告計測用のクエリパラメータを付加していることが多い。短縮URLをそのまま踏む前に展開して構成要素を確認すれば、リンク先のホストと、そこに埋め込まれた計測パラメータの両方を事前に把握できる。
なぜURLを分解する必要があるのか
- デバッグやログ記録のために複雑なURLを構成要素に分解する。
- 特定のパラメータがバックエンドに届かない理由を理解する。
- エンコードのミスなくプログラムでURLを正しく構築する。
userinfoを使ったフィッシングの手口
https://accounts.google.com@evil.com/のようなURLはaccounts.google.comにつながるように見えるが、実際にブラウザが開くのはevil.comだ — @記号の前の部分は単なるユーザー名（userinfo）であり、ホストではない。そのため最近のブラウザは実際のホストを視覚的に強調しようとするし、一部のリンク短縮サービスはURL内のuserinfoを一律禁止している。