URL 解析とは？

URL 解析（パース）とは、Uniform Resource Locator を個々の構成要素——プロトコル（スキーム）、ホスト名、ポート、パス名、クエリパラメータ、フラグメント識別子——に分解するプロセスです。あらゆる URL は RFC 3986 および WHATWG URL Standard で定義された構造に従います。URL パーサーは生の文字列を読み取り、区切り文字（://、:、/、?、#、&、=）によって各セグメントを識別し、個別にアクセス可能なフィールドとして返します。

ブラウザはアドレスを入力するたび、またはリンクをクリックするたびに URL 解析を実行します。JavaScript の URL コンストラクタ、Python の urllib.parse モジュール、Go の net/url パッケージはいずれも同じ構造ルールに従ったパーサーを実装しています。URL 解析は URL エンコードの逆の操作です——安全な転送のために文字を変換するのではなく、すでに構成された URL をその構成部品に分解します。

https://api.example.com:8080/v1/users?page=2&limit=10#section のような典型的な URL には6つの異なる構成要素が含まれています。区切り文字——://、:、/、?、&、=、#——があるため解析が決定的になります。それぞれがセクションの境界を示し、パーサーは曖昧さなくフィールドを抽出できます。

このオンライン URL パーサーを使う理由

目視で URL を分割するのはミスが生じやすく、特に文字列にエンコードされた文字、複数のクエリパラメータ、非標準ポートが含まれる場合は困難です。このツールはブラウザが使用するのと同じ WHATWG 準拠のアルゴリズムで URL を解析し、すべての構成要素を見やすくコピー可能なテーブルで表示します。

⚡

ブラウザで即座に解析

URL を貼り付けるだけで、すべての構成要素が即座に分解されて表示されます。ページの再読み込みも、サーバーへの通信も、待機も不要です。

🔒

URL のプライバシーを保護

解析はネイティブ URL API を使ってブラウザ内で完全に実行されます。入力した URL がデバイスの外に送信されることはありません。

🔍

すべての詳細を確認

プロトコル、ホスト名、ポート、パス名、クエリ文字列、ハッシュ、および各クエリパラメータのデコードされた値を個別に確認できます。

📋

個別コンポーネントをコピー

各フィールドの横にあるコピーボタンをクリックすると、正確な値を取得できます。手動でサブ文字列を選択してトリミングする必要はありません。

URL パーサーのユースケース

フロントエンドルーティングのデバッグ

パスセグメントとハッシュフラグメントがルーター設定と一致しているか確認します。誤ったスラッシュや予期しないクエリパラメータが 404 エラーを引き起こす前に発見できます。

バックエンド API エンドポイントの検証

ルートハンドラーやミドルウェアを記述する前に、受信リクエストの URL が正しいホスト名、ポート、パス構造を含んでいるか検証します。

DevOps リダイレクトルールのテスト

Nginx、Apache、または CDN のリダイレクトルールを記述する際、元の URL と対象の URL の両方を解析して、各コンポーネントが正しく対応しているか確認します。

QA リンク検証

テストレポートやバグチケットの URL を解析して、どのクエリパラメータまたはフラグメントが誤ったページの読み込みを引き起こしているかを特定します。

データパイプラインの URL 抽出

ログファイルやアナリティクスデータの URL からホスト名やパスセグメントを抽出して、ドメインレベルのレポートを作成したり、エンドポイント別にトラフィックをフィルタリングします。

URL 構造の学習

Web プロトコルを学び始めた学生や開発者は、実際の URL を貼り付けることで、どの区切り文字がどの境界を示すかをすぐに把握できます。

URL コンポーネントリファレンス

以下のテーブルは、JavaScript の URL コンストラクタが URL を解析する際に返すすべてのプロパティを示しています。Python の urlparse 結果、Go の url.URL 構造体、PHP の parse_url の出力にも同じコンポーネントが存在しますが、言語によってプロパティ名は異なります。

プロパティ	例	説明
protocol	https:	Scheme including the trailing colon
hostname	api.example.com	Domain name or IP address
port	8080	Port number (empty string if default)
pathname	/v1/users	Path starting with /
search	?page=2&limit=10	Query string including the leading ?
hash	#section	Fragment identifier including the leading #
origin	https://api.example.com:8080	protocol + hostname + port
host	api.example.com:8080	hostname + port
username	admin	Credentials before @ (rarely used in practice)
password	secret	Credentials before @ (avoid in production URLs)
href	(full URL)	The complete, serialized URL string

WHATWG URL Standard と RFC 3986

URL の解析方法を定義する2つの仕様があります。基本構造については一致していますが、エッジケースで異なる動作をします——その差異が、ブラウザとサーバーで URL の扱いが異なる原因となることがほとんどです。

WHATWG URL Standard

すべての現代的なブラウザと JavaScript の URL コンストラクタで使用されています。不完全な入力を受け入れて正規化します：スキームの欠落、パス区切り文字としてのバックスラッシュ、Punycode による非 ASCII ホスト名など。url.spec.whatwg.org でリビングスタンダードとして定義されています。

RFC 3986

正式な IETF 仕様（2005年）。WHATWG より厳格で、ブラウザが受け入れる一部の入力を拒否します。Go の net/url や Python の urllib.parse を含む多くのサーバーサイドライブラリで使用されています。RFC 3986 で定義されています。

実際には、ほとんどの差異は国際ドメイン名（IDN）、スキームの欠落、特殊文字を含む URL を解析するときに現れます。WHATWG パーサーは IDN ホスト名を自動的に Punycode に変換しますが、厳格な RFC 3986 パーサーはそれを拒否することがあります。このツールに URL を貼り付けてサーバーサイドコードの結果と異なる場合、WHATWG と RFC の差異が最も可能性の高い原因です。

コード例

主要な言語にはすべて組み込みの URL パーサーがあります。以下の例では同じ URL を解析してその構成要素を抽出しています。言語間でのわずかな命名の違いに注目してください：Python では protocol の代わりに scheme を使用し、Go では search の代わりに RawQuery を公開します。

JavaScript (browser / Node.js)

const url = new URL('https://api.example.com:8080/v1/users?page=2&limit=10#section')

url.protocol  // → "https:"
url.hostname  // → "api.example.com"
url.port      // → "8080"
url.pathname  // → "/v1/users"
url.search    // → "?page=2&limit=10"
url.hash      // → "#section"

// Iterate over query parameters
for (const [key, value] of url.searchParams) {
  console.log(`${key} = ${value}`)
}
// → "page = 2"
// → "limit = 10"

// Modify and re-serialize
url.searchParams.set('page', '3')
url.toString()
// → "https://api.example.com:8080/v1/users?page=3&limit=10#section"

Python

from urllib.parse import urlparse, parse_qs

result = urlparse('https://api.example.com:8080/v1/users?page=2&limit=10#section')

result.scheme    # → 'https'
result.hostname  # → 'api.example.com'
result.port      # → 8080
result.path      # → '/v1/users'
result.query     # → 'page=2&limit=10'
result.fragment  # → 'section'

# Parse query string into a dict
params = parse_qs(result.query)
params['page']   # → ['2']
params['limit']  # → ['10']

# Reconstruct with modifications
from urllib.parse import urlencode, urlunparse
new_query = urlencode({'page': '3', 'limit': '10'})
urlunparse(result._replace(query=new_query))
# → 'https://api.example.com:8080/v1/users?page=3&limit=10#section'

package main

import (
	"fmt"
	"net/url"
)

func main() {
	u, err := url.Parse("https://api.example.com:8080/v1/users?page=2&limit=10#section")
	if err != nil {
		panic(err)
	}

	fmt.Println(u.Scheme)   // → "https"
	fmt.Println(u.Hostname()) // → "api.example.com"
	fmt.Println(u.Port())     // → "8080"
	fmt.Println(u.Path)       // → "/v1/users"
	fmt.Println(u.RawQuery)   // → "page=2&limit=10"
	fmt.Println(u.Fragment)   // → "section"

	// Query params as map
	q := u.Query()
	fmt.Println(q.Get("page"))  // → "2"
	fmt.Println(q.Get("limit")) // → "10"
}

PHP

<?php
$url = 'https://api.example.com:8080/v1/users?page=2&limit=10#section';
$parts = parse_url($url);

$parts['scheme'];   // → "https"
$parts['host'];     // → "api.example.com"
$parts['port'];     // → 8080
$parts['path'];     // → "/v1/users"
$parts['query'];    // → "page=2&limit=10"
$parts['fragment']; // → "section"

// Parse query string into an array
parse_str($parts['query'], $params);
$params['page'];    // → "2"
$params['limit'];   // → "10"

よくある質問

URL と URI の違いは何ですか？

URL（Uniform Resource Locator）は、識別子とアクセス手段（https:// などのスキーム）の両方を含む URI（Uniform Resource Identifier）の一種です。すべての URL は URI ですが、すべての URI が URL であるわけではありません。urn:isbn:0451450523 のような URN は、取得方法を指定せずに名前でリソースを識別する URI です。Web 開発では、遭遇するほぼすべての URI が URL であるため、両用語はしばしば互換的に使用されます。

URL コンストラクタは相対 URL をどのように処理しますか？

JavaScript の URL コンストラクタは相対パスを解析する際にベース URL が必要です。new URL('/path?q=1') を呼び出すと TypeError がスローされます。ベースを指定する必要があります：new URL('/path?q=1', 'https://example.com')。Python の urljoin と Go の url.ResolveReference も同じ目的を果たします。このツールはスキームを含む完全な絶対 URL を想定しています。

URL にポート番号がない場合はどうなりますか？

ポートが省略されると、パーサーは port プロパティに空文字列を返します。ブラウザはスキームに対応するデフォルトポートを想定します：https は 443、http は 80、ftp は 21 です。origin または host プロパティを通じて有効なポートにアクセスできますが、明示的なポートが指定されていないため port フィールド自体は空のままです。

URL に Unicode 文字を含めることはできますか？

はい、ただし転送のためにエンコードする必要があります。WHATWG URL Standard はこれを自動的に処理します：国際ドメイン名は Punycode（xn-- プレフィックス）に変換され、ASCII 範囲外のパス・クエリ文字はパーセントエンコードされます。Unicode を含む URL をこのツールに貼り付けると、解析結果に正規化された ASCII 安全なバージョンが表示されます。

URL の最大長はどのくらいですか？

最大 URL 長を定義する標準はありません——RFC 3986 はこの点について言及していません。実際には、ブラウザが制限を設けています：Chrome はアドレスバーで約 2MB をサポートし、Internet Explorer（レガシー）は 2,083 文字の制限がありました。ほとんどの Web サーバーはリクエストラインに対してデフォルトで 8KB（Nginx）または 8KB（Apache）を設定しています。大量のデータを渡す必要がある場合は、クエリ文字列の代わりに POST リクエストのボディを使用してください。

完全な URL なしにクエリ文字列だけを解析するにはどうすればよいですか？

JavaScript では new URLSearchParams('page=2&limit=10') を使用して、単独のクエリ文字列を解析します。Python では urllib.parse.parse_qs('page=2&limit=10') を使用します。どちらもパラメータをキーと値のペアとして返します。これは、フォーム送信やクエリ部分のみがキャプチャされたログエントリなど、クエリ文字列を単独で持っている場合に便利です。

URL 解析と URL デコードは同じものですか？

いいえ。URL 解析は URL を構造的な構成要素（スキーム、ホスト、パス、クエリ、フラグメント）に分割します。URL デコードはパーセントエンコードされた文字を元の形式に戻します（%20 はスペースに、%26 は & になります）。この2つの操作は補完的なものです：通常は最初に URL を解析し、その後で個々のコンポーネントの値をデコードします。解析前にデコードすると、デコードされた & や = などの区切り文字が誤って解釈されるため、URL 構造が壊れる可能性があります。

URL パーサー