TEXT

URL パーサー — ブラウザで URL をコンポーネントに分解

URL をコンポーネントに分解 —— scheme、host、port、path、query、fragment。RFC 3986 準拠、すべてローカルで動作。アップロードなし、サインアップ不要。

● ローカル動作 · クリップボード対応ページ読み込み以降のツールによる通信：0件

URL Parser

Parse URLs to extract protocol, hostname, path, query params, and more.

Enter URL

こんなツールも

行をソート MD5 ハッシュ UUID ジェネレーター JSON → CSV Base64 エンコード PDF 分割 HAR → cURL TOML ツール .env ヘルパー MsgPack インスペクター PDF 圧縮 PDF → EPUB

パーサーを開く

URL は一見すると 1 本の文字列ですが、実際には 2005 年から変わっていない構文によって結びつけられた 6 つの独立したコンポーネントです。scheme はブラウザにどのプロトコルを使うかを伝え、authority はリクエストの送信先を示し、path はリソースを選び、query はパラメータを追加し、fragment はレスポンス内のセクションを指します。これらの名前を上げられない Web 開発者はいませんが、userinfo（user:pass@host）や IPv6 アドレス（[::1]:8080）、scheme と一致しないポートを含む URL を正しく解析できる人ははるかに少数です。URL パーサーはその推測を取り除きます。文字列を貼り付ければ、構造化された分解結果が得られ、どのコンポーネントが誤っているかがわかります。

URL のバグの最も一般的な原因は、あるものに見えて実は別物であるコンポーネント間の相互作用です。scheme が https の URL でポート 8080 を使うと、ネットワーク層では動作しますが、TLS は 443 を期待するため証明書検証で失敗します。fragment #/route はクライアントサイドルートに見えますが、ブラウザは HTTP リクエストがマシンを離れる前にこれを取り除きます。path /foo/../bar は、サーバーに届く前に HTTP クライアントによって /bar に解決されます。パーサーはこうした相互作用を解決せず、各コンポーネントを記述された通りに表示しますが、コンポーネントを分けて表示することで、1 行の URL 文字列では見えなかった相互作用が見えるようになります。

最後に引き継ぎについてです。query string を構造化して解析する必要がある場合は、query コンポーネントを当サイトの Query String Parser ツールに入力して JSON 出力を得てください。URL がより大きな HTTP デバッグ作業の一部である場合は、URL パーサーと HTTP Headers Parser、cURL-to-Python を組み合わせて、URL からワイヤーフォーマットまでのリクエストチェーン全体を追跡してください。サイト移行中に多数の URL をまとめて確認する場合は、リスト全体をコピーして 1 つずつ解析してください。構造化された出力により、同じ URL の 2 つのバージョンを diff することが簡単になります。

使い方

URL を貼り付ける
任意の URL を入力欄にドロップしてください —— 絶対 URL（`https://example.com/path?q=1#top`）、相対 URL（`/path/to/resource`）、またはプロトコル相対 URL（`//cdn.example.com/lib.js`）。パーサーはそれを構造化されたコンポーネントに分解します。
各コンポーネントを確認する
scheme、authority（userinfo、host、port）、path、query string、fragment はそれぞれ別のフィールドに表示されます。host はさらに subdomain、domain、TLD に分割され、すぐに参照できます。
解析結果を JSON としてコピーする
「Copy as JSON」をクリックすると、スクリプトやデバッグに使える構造化出力を取得できます。各コンポーネントはトップレベルのキーとなり、URL の生の文字列値が対応します。

よくある質問

パーサーは不正な形式や部分的な URL も扱えますか？

はい。Web URL には WHATWG URL Standard、非ブラウザ URL には RFC 3986 にフォールバックします。不正な形式の URL は警告が表示され、どのコンポーネントの解析に失敗したかが示されます。`/api/users` のような部分的な URL は、scheme も authority もない path のみとして解析されます。

host と hostname の違いは何ですか？

host にはポートが含まれます（`example.com:8080`）が、hostname はドメインのみです（`example.com`）。ポートは別フィールドとして表示されます。URL でポートが省略されている場合は scheme から推測され（HTTP は 80、HTTPS は 443）、括弧付きで表示されます。

クエリパラメータはどのように処理されますか？

生の query string はそのまま表示されます（`q=hello&page=1`）。パラメータを構造化して抽出するには、Query String Parser ツールをご利用ください。query を JSON オブジェクトとして解析し、配列の処理、ネストされたキー、重複キーのマージをサポートします。

解析結果の URL エンコードされたテキストはどうなりますか？

パーサーは各コンポーネントのデコードされた形式で表示します。`/my%20file` という path は `/my file` として表示され、元のエンコード形式は別の「raw」フィールドに保持されます。これにより、人間可読版本與ワイヤーフォーマット版本を並べて確認できます。

制限事項

punycode から Unicode へのドメイン変換は非対応`xn--mnchen-3ya.de` のような国際化ドメイン名は Punycode 形式で表示されます。エンコーディングは不可逆であるため、Unicode 形式を復元するには別途 IDN ライブラリが必要です。
URL の正規化は非対応パーサーは URL を正規化しません（例：`../` セグメントの解決、重複スラッシュの圧縮、過剰エンコードされた文字のデコード）。URL は記述された通りにそのまま解析されます。
リダイレクトの追跡や DNS 解決は非対応このツールは純粋な構文パーサーです。ホスト名の解決、リダイレクトの追跡、URL が実在するリソースを指しているかの検証は行いません。

プラットフォーム別の注意点

macOS: Foundation に内蔵された `NSURLComponents` も同じことをしますが、Swift または Objective-C が必要です。Safari のアドレスバーからコピーしたものをコードを書かずに確認したい場合、ブラウザツールが適切な選択肢です。
Linux: CLI での代替例：`python3 -c 'from urllib.parse import urlparse; print(urlparse("https://example.com"))'`。チャットやドキュメントページからコピーした URL をアドホックに確認する場合は、ブラウザツールが便利です。
Windows: PowerShell の `[System.Uri]` クラスも同じ RFC 3986 ルールで URL を解析しますが、.NET ランタイムが必要です。ブラウザツールは依存関係ゼロでオフラインでも動作します。
Web: 完全にクライアントサイドで動作します。API 開発中に URL をデバッグする際に便利です —— コンソールのエラーログから URL を貼り付ければ、どのコンポーネントが不正なのかを一目で確認できます。