URLクエリパラメータを解析・検証する方法
任意のURLをプロトコル、ホスト、パス、クエリに分解し、APIテスト用に値を個別変更。パーセントエンコードのデコードも一括で。
なぜ重要か
QAがチェックアウトファネルを追っています。マーケはUTM付きURLを渡しますが、検証環境が一部リクエストを拒否。その原因：UTMのcontent値にエンコードされない&がありクエリストリングパーサを壊しました。キーバリューを1行ずつ表示し編集できるURLインスペクタなら、そのバグは数秒で露見です。
実際の3つのシーン
リクエストURLを貼り、値の中の未エンコード&を見つけます。
悪パラメータを特定
URLを分解し、utm_source/medium/campaign/content/termの有無と形式を確認します。
きれいなアトリビューション
部品ごと組み立て自動エスケープし、最終URLをコピーします。
単一のAPI往復で完了
手順
URLパーサーを開きます。
URLを貼る
http/https/ws/ftp/customスキームなど標準準拠。貼り付け時に分解されます。
各部分を確認
プロトコル、ユーザー／パスワード（あれば）、ホスト、ポート、パス、
#、完全クエリ。テーブルでパラメータを見る
各行にクエリ項目、rawとデコード済み。エンコードの食い違いが一目で分かります。
値を編集する
1項目だけ変更し、ツールが正しく再エンコードしてURL全体を組み替えます。
再構成URLまたは値だけコピー
QA共有用には正規化済み全体、コードへは個別デコード値。
URL
https://shop.example.com/cart/checkout?
cart_id=A1%26B2&
utm_source=newsletter%2520Q1&
ref=abc%20123分解結果
Protocol: https
Host: shop.example.com
Path: /cart/checkout
Params:
cart_id → "A1&B2"
utm_source → "newsletter%20Q1" ← double-encoded!
ref → "abc 123"
実践テクノ
- 値ごとにデコード。 文字列全体に
decodeURIComponentすると&``=の意味まで変わります。値単位が正しい—パーサがそう処理します。 - 二重エンコードに注意。
%2520は%20をまたエンコード（スペース→%20→%2520）。デコード後にさらに%が残るなら異常です。 - バグ共有には再構成URL—空白やエスケープを正規化して渡せます。
- **SPAでは
#も。**状態がクエリでなくフラグメント側にあることを確認します。
よくある落とし穴
よくある誤り
スペースが「+」になる／「%20」になる問題
フォーム送信エンコードはクエリで+もスペース、URIエンコードは%20。両方クエリとしては復号同じでも、フォームでないAPIは+を拒否することがあります。
よくある誤り
パスセグメント喪失
パス本体にエンコードなし?があるとクエリが早過ぎに始まります。パスに残すべきなら %3F に。
よくある誤り
パラメータ値のスラッシュ
一部ルータは値の/をパス境界と見なします。センシティブなら %2F に。
向いていない用途
- 大規模URL分析は
jq/awkやNodeのURLAPIへのパイプ向きです。 - クロール／スクレイピング—レート制御付き専用スクリプトへ。
- OAuthフロー—ライブラリ利用を。手組みはセキュリティ上ミスりやすいです。
FAQ
URL内のIPv6ホストも？
はい。[2001:db8::1]:8080/path?x=1 もパースされます。
相対URLは？
ベースURLと一緒に入力すれば、その基準で解決されます。
URLは送信される？
いいえ。ブラウザ組み込み**URL API**のみでローカル解析です。
次のステップ
- ホストのIPとASNはIPルックアップツール。
- レスポンスコードはHTTPステータス。
- バイナリ値を載せるならBase64/Hexコーデック。