URL パーサー

スキーム（プロトコル）、ホスト名、ポート、パス、クエリ文字列パラメータ（テーブル形式）、フラグメント（ハッシュ）、ユーザー名、パスワード、オリジン、検索文字列を抽出します。

はい。すべての URL エンコード文字（%20、%3A など）は読みやすさを考慮して出力時に自動的にデコードされます。

絶対 URL（http:// または https:// で始まるもの）での動作が最適です。相対 URL の場合はブラウザが自動的にベース URL を補完します。

URI は RFC 3986 で定義された総称であり、スキーム、パス、クエリ、フラグメントから構成される識別子です。URL はリソースの位置を示す URI(https://ezparser.com/url-parser)であり、URN は位置を持たずにリソースの名前を付けるもの(urn:isbn:0451450523)です。日常的な Web 開発では、ほとんどの場合 URL を指していると考えてよいでしょう。

非予約文字(A-Z、a-z、0-9、- . _ ~)以外の各バイトは、% の後に 2 桁の 16 進数を続けて表現されます。たとえばスペースは %20 になり、UTF-8 の é は %C3%A9 になります。/ ? # & = などの予約文字は URL 構造上の意味を持つため、データとして使用する際はエンコードが必要です。クエリ文字列では、古いフォームエンコーダーはスペースを + にマッピングしますが、このツールは両方の形式をデコードできます。

https://user:[email protected]:8443/v2/users?page=2#results は、スキーム(https)、ユーザー情報(user:pass@)、ホスト(api.example.com)、ポート(8443)、パス(/v2/users)、クエリ(page=2)、フラグメント(#results)に分解されます。文法は RFC 3986 のセクション 3 で定義されており、このパーサーはすべてのコンポーネントにラベルを付けて表示します。

はい。RFC 3986 のセクション 6 で正規化が定義されています。/a/./b は /a/b に、/a/../b は /b に解決され、空のセグメント // は / にまとめられます。ブラウザや HTTP クライアントはリクエスト送信前にこの処理を適用するため、ドットセグメントのみが異なる URL は通常同じリソースに到達します。スキームに基づく正規化では、ホストは小文字化され、デフォルトの :443 ポートは削除されます。

RFC 3986 には上限の規定はありません。実際には Chrome は約 2 MB まで受け付けますが、ほとんどのサーバーはリクエストラインを 8 KB 前後で制限しており(Apache のデフォルトの LimitRequestLine は 8190 バイト)、Twitter/X などの API も 2048 文字の上限を文書化しています。共有や SEO の観点では、URL を 2000 文字未満に収めるのが従来からの安全圏です。