URLパーサー差チェッカー
URLを1つまたは複数行で貼り付け、ブラウザー/WHATWGパーサーと一部バックエンド言語で使われる旧来のRFC 3986方式パーサーが、URLの実際の宛先をどう異なって解釈するかを確認します。書式だけでなくセキュリティ問題となる場合があります。
ブラウザー内でローカルに処理します。ファイルがアップロードされることはありません。
使い方 ツール
- URLを1つ、または1行に1つずつ貼り付けます。内容はブラウザー外へ送信されません。
- 「URLを確認」を選びます。
- 指摘ごとに、解析動作の差、影響するパーサー、理由を確認します。
- 安全な書き換えが提案された場合は使います。userinfoの混同と非ASCIIホストは意図したホストを推測できないため、意図的に未解決とします。
前提条件
- 空でない各行をURL全体として扱います。長文中のURLらしい部分を検索しません。空白、バックスラッシュ位置、userinfoなど複数検査は文字列全体の解析を必要とします。
- スキーム（例：https:）も`//`の相対形式接頭辞もない行は通常テキストとして無視し、問題にしません。
- WHATWG側はシミュレーションでなく、このブラウザーで動作する実際の`URL`コンストラクターを使います。「影響なし」は当該入力を実際に試した結果です。
- RFC 3986厳格・旧式側は旧式または厳格パーサーの文書化された挙動の説明であり、稼働する第2パーサーではありません。別言語の信頼できないコードを実行しません。
出典と参考データ
方法論
各候補URLをWHATWG式の寛容な解析とRFC 3986式の厳格解析における7つの文書化された差と照合します：バックスラッシュ正規化、userinfo/ホスト混同、先頭の余分なスラッシュ、非ASCII/IDNホスト、スキームなし相対URL、埋め込み空白・制御文字、未エンコード空白。曖昧さなく安全な場合（バックスラッシュ正規化、余分な空白削除、余分なスラッシュ整理、空白のパーセントエンコード）のみ書き換えます。userinfo混同と非ASCIIホストは意図したホストを判断できないため自動変換しません。
計算例
userinfoの`@`による混同
入力項目: https://trusted.com@evil.com/
結果: ブラウザーは`@`より前をuserinfo、後を実ホストと解釈するため、このURLはtrusted.comでなくevil.comを指します。文字列一致だけで宛先を検査するコードを回避する典型例としてエラーにします。
通常のスラッシュの代わりにバックスラッシュ
入力項目: https:\\example.com\path
結果: ブラウザーはhttpsのような特殊スキームでバックスラッシュを通常のスラッシュに正規化し、`https://example.com/path`と同じように解析します。非ブラウザーパーサーは正規化せず、別ホストとして解析または失敗する場合があります。エラーとして指摘し、安全な表記へ書き換えます。
先頭の余分なスラッシュ
入力項目: https:///example.com
結果: スキームのコロン後の3本のスラッシュはパーサー間で処理が異なります。警告として指摘し、正規形`https://example.com`を提案します。
userinfo内の信頼できそうなホスト
入力項目: https://trusted.com@evil.com/
結果: `trusted.com`は`@`より前のuserinfoで、ホストは`evil.com`です。解析せず部分文字列を探す信頼済みドメイン検査を誤認させる場合があります。このチェッカーは文字列を分析するだけで、URLへ移動・取得しません。
実用的なアドバイス
- `url.startsWith(...)`や`url.includes(...)`の文字列一致でURLの信頼性・オリジンを検証せず、実際のURLライブラリで解析して結果のホストを確認してください。
- 正規化しないパーサーに渡す前にバックスラッシュをスラッシュへ正規化してください。URLのバックスラッシュは書式選択でなく警告として扱います。
- 複数システムが解析する場合、基底URLなしでもすべてのパーサーが受け付けるとは限らないプロトコル相対URLより、スキームを明示してください。
よくある間違い
- 信頼できるドメインに見えるURLが実際にそこを指すと思うこと。userinfo混同は視覚確認や部分文字列検査を欺く形です。
- 例外なく解析できたURLは正しく解釈されたと思うこと。userinfo、バックスラッシュ、非ASCIIホストは正常に解析されても、ホストやパスが異なる場合があります。
よくある質問
userinfo混同はエラーで、非ASCIIホストは警告なのはなぜ？
userinfo混同は一般的な正当用途がなく、実際に悪用されている文書化済みのセキュリティ回避手法です。非ASCIIホストは国際化ドメイン名として正当な場合が多く、問題はパーサー間の扱いの差であり、URL自体が不審という意味ではありません。
URLを実際に取得・正規化して本当のホストを調べないのはなぜ？
貼り付けたURLへの移動、取得、クリック可能リンクとしての表示はしません。URL混同攻撃を教えるツール自体が攻撃経路にならないよう、ブラウザー内で静的な文字列分析だけを行います。
問題なしなら安全なURLですか？
このツールが検査する7つの具体的な解析差を検出しなかったという意味に限られます。取得して安全であることや、解析差以外の理由で悪意がないことを保証しません。
最終確認日： 2026-09-25
静的文字列チェッカーであり、動作する第2パーサーではありません。RFC 3986側は文書化された実際の挙動を説明し、他言語のURLライブラリを入力に実行しません。相対URLの解決、リダイレクト追跡、列挙した7パターン以外の悪意判定も行いません。
テーマとツールの設定、保存済みリストと最近使用したリストは、このブラウザー内にのみ保存されます。