URL クエリビルダー
クエリパラメータを 1 つずつ追加・編集・無効化するクリーンなフォームで、結果の URL がライブで構築される。キーと値は `encodeURIComponent` を通る;スペースを `%20` のままにするか `+` に折りたたむ(form-urlencoded バリアント)かを選べる。無効化された行はリストに残るが出力には現れない — 失わずに代替案を一時保存するのに便利。
—
パラメータ (3)
スペースは:
構築された URL
https://api.example.com/search?q=cloudflare%20workers&page=1&sort=relevance
キーと値は encodeURIComponent で percent エンコードされる — すべてのまっとうなクライアントが使うルール。
使い方
- ベース URL を入力。既に `?` がある場合、ビルダーは `&` で残りを追加。
- キー値の行を追加。チェックボックスをトグルで削除せずに含める / 除外。
- サーバーが標準 URI エンコーディングを期待するか form エンコードを期待するかで `%20` / `+` を選ぶ。
よくある質問
- スペースに `+` を使うのはいつ?
- サーバーがクエリ文字列を `application/x-www-form-urlencoded` として扱うとき — 多くの古いフォームハンドラと CGI スクリプトがそう。モダンな REST API は通常どちらも受け入れるが、`application/json` POST 本文の安全なデフォルトは `%20`。
- 重複キーは許可される?
- はい — ほとんどのサーバーは繰り返しキーを配列として扱う。一部は最後のものだけを保持;不明な場合は API ドキュメントを確認。
- 値の中で必ず符号化しなければならない文字は?
- 構造として読まれてしまうものです。アンパサンド、等号、空白、そして何よりシャープ記号です。シャープ以降はフラグメントであり、サーバーには送られません。符号化されていないシャープがひとつあるだけで、値の残りが要求から静かに切り落とされます。スラッシュとコロンはクエリ文字列の中では正当なのでそのままでも構いませんが、符号化しても害はありません。
- パラメーターの順序は重要ですか?
- サーバーにとっては重要ではありません。どの順に読んでもよいからです。しかしそれ以外のすべての場所では重要です。キャッシュやCDNはURLの文字列そのものを鍵にするので、同じパラメーターでも順序が違えば別のキャッシュ項目になりますし、URLに署名したり比較したりするもの――解析、署名付きリンク、重複排除――は別々の文字列として扱います。強制されなくても順序は固定しておきましょう。
関連ツール
クエリ文字列 ↔ JSON 変換
URL のクエリ文字列を JSON オブジェクトに、またその逆に変換します。ブラウザ上で動作します。
開発 0 0
URL エンコーダー / デコーダー
URL 用にテキストをパーセントエンコード、または URL をデコード。
開発 0 0
URL パーサー
URL をプロトコル・ホスト・ポート・パス・クエリ・ハッシュに分解。クエリパラメータをテーブルにデコード。
開発 0 0
mailto: リンクビルダー
宛先・Cc・Bcc・件名・本文を入力して RFC 6068 準拠でパーセントエンコードされた mailto: URL を生成。<a> タグにそのまま埋め込めます。
ネットワーク 0 0
HTTP ステータスコード リファレンス
1xx-5xx の全 HTTP ステータスコードを検索 — 概要・RFC・使い時・よくある落とし穴付き。
ネットワーク 0 0
URI テンプレート展開 (RFC 6570)
独自の変数で RFC 6570 URI テンプレートを展開 — 4 レベルすべて対応:パス・クエリ・フラグメント・ラベル・パス形式演算子、explode・prefix 修飾子、ブラウザ内で。
ネットワーク 0 0