長いURLの「?」「#」「ref=」は何？ URLを分解・デコードできるツールを作った

Amazonの商品ページやニュース記事のURLをコピーしたとき、思った以上に長くて驚いたことはありませんか？

URLをよく見ると、?、&、#、ref=、%E6%97%A5 のような文字が並んでいます。

「この部分は何を意味しているんだろう？」「人に送るとき、どこまで残せばいいんだろう？」

そんな疑問から、URLを分解して説明し、必要な部分をコピーできる URL Inspector を作りました。

URLは、いくつかの部分に分かれている

例えば次のURLを見てみます（構造説明用の架空のURLです）。

https://example.com/products/item/ref=top?utm_source=social&view=detail#reviews

部分	役割
https://	通信方式（スキーム）。HTTPSは通信経路を暗号化する
example.com	接続先のホスト名
/products/item/ref=top	ページの場所などを表すパス
?utm_source=social&view=detail	クエリ。追加の条件や情報を渡す部分
#reviews	フラグメント。ページ内の位置や画面状態を表すことがある

特に混同しやすいのが、記号としての区切りとサイト独自の名前です。

• ? はクエリの開始、& はクエリの項目の区切り、= は名前と値の区切りです。
• # はフラグメントの開始です。通常、フラグメントはHTTPリクエストでサーバーへ送られませんが、Webアプリの画面制御に使われることがあります。
• ref= はURLの標準的な区切り記号ではありません。「参照元」を示すことがありますが、意味はサイト次第です。上の例ではクエリではなくパスの一部です。

つまり、ref= が見えたからといって、必ず削ってよいわけではありません。

長いURLを共有するとき、どこまで残せばいい？

例えば、先ほどのURLをそのまま送る代わりに、次のような候補を考えられます。

クエリとフラグメントより前を残す場合

https://example.com/products/item/ref=top

ref= の手前まで残す場合

https://example.com/products/item/

後者は今回のようなURLでは読みやすくなりますが、同じページを開ける保証はありません。view=detail のように表示内容に関係するクエリや、画面の移動先を表すフラグメントもあるためです。

だからURL Inspectorでは「これが正しい最短URL」と決めつけず、元のURLを保持したまま、共有用の候補とその理由を表示するようにしました。

読めない文字列もデコードする

URLを調べていると、エンコードされた文字列にもよく遭遇します。

%E6%97%A5%E6%9C%AC%E8%AA%9E  → 日本語
\u65E5\u672C\u8A9E           → 日本語
U+65E5                         → 日
日                       → 日
\uD83D\uDE00                   → 😀

「エンコードを復元」では、次の3形式を選べます。

1. URLエンコード：%XX 形式のUTF-8文字列。必要に応じて + を空白として扱うことも可能
2. Unicodeエスケープ：\uXXXX、\u{...}、U+XXXX など。絵文字のサロゲートペアにも対応
3. HTML文字参照：日、日、& など。名前付き参照は一般的なものに対応

二重エンコードは、必要に応じてもう一度デコードできます。変換しすぎると元の意味が変わる場合があるので、1回ずつ確認する仕様です。

URLだけで「安全」とは判定できない

URL Inspectorでは、URLの文字列から気になる特徴も表示します。

例えば、暗号化されていないHTTP、認証情報らしいパラメータ、別サイトへの移動先を指定する値、スクリプトに似た文字列、Punycode形式のドメインなどです。

ただし、これは注意点を示すための簡易チェックです。

URLに <script> という文字列が含まれていても、それだけでXSS脆弱性があるとはいえません。同様に、転送先らしいパラメータがあるだけでオープンリダイレクトが成立するわけでもありません。HTTPSであっても、アクセス先が信頼できるとは限りません。

怪しい点に気づくための補助であり、脆弱性診断や悪性URL判定の代わりにはなりません。

入力したURLはサーバーに送らない

このツールで重視したのは、入力したURLや変換前後の文字列を、解析のためにサーバーへ送らないことです。

URLの分解やデコードはブラウザのJavaScriptで実行し、入力されたリンクへ自動アクセスすることもありません。操作計測には固定の操作名を用い、入力文字列を含めません。

もちろん、ツールのページを表示するときには通常のWeb通信が発生します。「通信が一切ない」という意味ではなく、解析対象の文字列を預からないという設計です。

おわりに

URLは単に短ければよいわけではなく、どの部分に意味があるかを理解することが大切だと感じました。

「URLを短縮するツール」というより、URLを読めるようにして、自分で判断できるようにするツールを目指しています。

登録不要で試せます。サンプルURLも用意しています。

▶ Utiloop URL Inspectorを使ってみる

URLやエンコードで「こういう表記も読めると便利」という例があれば、ぜひ教えてください。