URLビルダー
スキーム、ホスト、パス、クエリパラメータ、フラグメントでURLをインタラクティブに構築します。
仕組み
- スキームとホストを選択: プロトコル(http、https、ftp)を選択し、ターゲットドメインを入力します。
- パスとクエリパラメータを追加: パスを入力し、必要に応じてキー/値ペアを追加します。
- フラグメントを追加(オプション): ページの特定のセクションを指すアンカーまたはハッシュを追加します。
- 組み立てられたURLをコピー: 生成されたURLはライブで更新されます。コード、マーケティング、テストで使用するためにコピーします。
なぜURLビルダーを使うのか?
URLを手動で組み立てることはエラーが発生しやすい, 欠落したスラッシュ、エンコードされていないスペース、失われたクエリパラメータがディープリンク、API呼び出し、リダイレクトを壊す可能性があります。このURLビルダーは、各コンポーネントが正しく配置およびエンコードされていることを保証し、毎回有効なURLを生成します。追跡されたマーケティングリンクの作成、開発中のAPIエンドポイントの構築、メールキャンペーンのディープリンクの組み立て、URL構造の文書化に最適です。
機能
- 複数のスキーム: http、https、ftpがデフォルトでサポートされています。
- 自動エンコーディング: パラメータ値のスペースと特殊文字はURL用に正しくエンコードされます。
- 複数のクエリパラメータ: 必要な数だけキー/値ペアを追加します。
- クリップボードにコピー: 生成された完全なURLのワンクリックコピー。
- ライブプレビュー: 結果を即座に確認するために、入力中にURLが更新されます。
よくある質問
URLの部分は?
完全なURLには、スキーム(https)、ホスト(example.com)、オプションのポート(:8080)、パス(/api/v1)、クエリ(?key=value)、フラグメント(#section)が含まれます。このビルダーは各コンポーネントをカバーします。
特殊文字を処理しますか?
はい。パラメータ値のスペース、アクセント付き文字、記号、その他の非ASCII文字は自動的にエンコードされ、結果のURLが任意のブラウザまたはAPIクライアントで有効になります。
URLパラメータはSEOに影響しますか?
追跡パラメータ(UTMタグなど)は通常、オーガニック検索ランキングに影響しません。多くのタグ付きURLが共存する場合の重複コンテンツのペナルティを回避するには、正規タグが各ページのクリーンバージョンを指していることを確認してください。
URL の解剖、コンポーネントごとに
ウェブ上のすべての URL を定義する文法は、RFC 3986「Uniform Resource Identifier (URI): Generic Syntax」(Berners-Lee、Fielding、Masinter、2005 年 1 月)に存在します。ブラウザは実際には WHATWG URL Living Standard で定義されているわずかに寛容なバリアントを使用します。どちらもコンポーネントについて一致しています:
- スキーム,
https、http、ftp、mailto、data、tel、sms、magnet、加えてカスタムアプリスキーム(myapp://)。RFC 3986 は小文字を要求します;WHATWG は正規化します。IANA URI Scheme レジストリには登録されたスキームの公式リストがあります。 - 権限,
userinfo@host:port。user:password@の埋め込み資格情報形式は、セキュリティのために非推奨になりました:Chrome 64(2018 年 1 月)は、フィッシングトリックを可能にしていたため、URL に資格情報を持つサブリソースのロードをブロックします。 - ホスト, ドメイン名または IP リテラル。
президент.рфのような国際化ドメイン名は、Punycode(RFC 3492、2003 年 3 月)を介して ASCII に変換されます:その例はxn--d1abbgf6aiiy.xn--p1aiになります。ブラウザは表示のために変換を透過的に行います。 - ポート, スキームのデフォルトでない場合のみ含まれる。デフォルト:80(http)、443(https)、21(ftp)、22(ssh)、25(smtp)、5432(postgres)、3306(mysql)、6379(redis)。
- パス, スラッシュで区切られたセグメント。各セグメントは、RFC 3986 §3.3 で定義された
pcharセットの外側のすべてをパーセントエンコードします。ドットセグメント.と..には削除セマンティクスがあります(§5.2.4)。 - クエリ, 慣例により
&で区切られたキーと値のペアですが、RFC 3986 は「?の後の不透明な文字列」とだけ言っています。慣例は WHATWG のapplication/x-www-form-urlencodedアルゴリズムで形式化されています。 - フラグメント,
#の後のすべて。サーバーには決して送信されません。シングルページアプリケーションルーター、アンカーリンク、OAuth インプリシットフロートークンによって使用されます。
パーセントエンコーディング:+ と %20 のトラップ
RFC 3986 §2.3 では、エンコーディングを必要としない 非予約文字 を定義しています:A-Z a-z 0-9 - . _ ~。それ以外のすべては、URL コンポーネント内のデータとして出現すると、%XX になります。ここで XX はバイトの 16 進値です。マルチバイトの UTF-8 文字は複数のパーセントトリプレットに展開されます:é(U+00E9、UTF-8 C3 A9)は %C3%A9 としてエンコードされます。古典的な落とし穴はスペース文字です:通常の URL パスまたはフラグメントでは、スペースは %20 としてエンコードされます;フォームエンコードされたクエリ文字列(HTML フォームと WHATWG クエリ文字列シリアライザによって共有される application/x-www-form-urlencoded アルゴリズム)では、スペースは + としてエンコードされます。フォームデータをデコードするサーバーは + をスペースに変換し戻します;クエリを汎用 URI として扱うサーバーはそうしません。2 つの慣例を混在させると、データが静かに破損します。JavaScript で安全なパターン:クエリには new URLSearchParams、個々の値には encodeURIComponent を使用します;仕様の準拠は処理されます。
実際に URL ビルダーが必要な場所
- Google Analytics 用の UTM タグ付きマーケティングリンク(Urchin Tracking Module、2005 年から GA で):5 つの正規パラメータは
utm_source、utm_medium、utm_campaign、utm_content、utm_termで、Google 自身のガイダンスに従ってすべて小文字です。 - OAuth 2.0 認可リクエスト(RFC 6749、2012 年 10 月):仕様は、認可エンドポイントでのクエリパラメータとして
response_type、client_id、redirect_uri、scope、stateを義務付けます。 - モバイルディープリンク:ブラウザではなくインストール済みのアプリに OS がルーティングする
app://スキーム、またはドメインから提供される Android App Link / iOS Universal Link。 - API クライアントテスト:
https://api.example.com/v2/users?expand=projects&since=2024-01-01。これらを手で入力すると、「値内のスペース」ステップで一貫して失敗します。 - CDN キャッシュバスター:デプロイがキャッシュバージョンを無効化するように、静的アセット URL に追加される
?v=2026-05-12-1。クエリ文字列はキャッシュキーの一部です。 - 画像変換サービス(Cloudinary、imgix、Cloudflare Images):変換はクエリパラメータまたはパスセグメントとしてエンコードされます。典型的な呼び出しは
?w=800&q=85&fm=webpのように見えます。 - メールテンプレートでは、ランディングページが JS でパラメータを読み取り、しばしば UTM タグを受信者ごとの追跡のためにユニークな
tokenまたはuidと組み合わせます。
よくある間違い
- 値内の
&のエンコードを忘れる。値「猫 & 犬」を素朴に?species=猫 & 犬にドロップすると、キーspecies値猫プラス迷子の空のキーになります。常にencodeURIComponentを通してください。 - 二重エンコーディング。すでにエンコードされた文字列で
encodeURIComponentを呼び出すと、%20が%2520になります。値が「防御的にエンコードする」2 つのシステムを通過するときに簡単に発生します。 - 末尾スラッシュの不一致。RFC 3986 では、
https://example.com/apiとhttps://example.com/api/は異なるリソースであると述べています。ほとんどの REST API はそれらを同一に扱いますが、一部は 308 リダイレクトを返します;1 つの正規形式を選択し、それを文書化してください。 +と%20の混在。フォームエンコードされたクエリ文字列はスペースに+を使用します;一般的なパーセントエンコーディングは%20を使用します。リテラル+を持つパスはコピー&ペーストで生き残りますが、フォームデコーダーがそれを読み取るときに失敗します。- 埋め込み資格情報。
https://user:pass@example.comは非推奨であり、Chrome 64+ でサブリソースのロードがブロックされています。Authorizationヘッダーを使用してください。 - IDN スプーフィング。キリル文字「а」(U+0430) は視覚的にラテン文字「a」と同一です。ブラウザは、ドメインがスクリプトを混合する場合に Punycode を表示しますが、
аpple.com(キリル文字 а)を指す手動で構築された URL は、apple.comとは別のサイトを開きます。安全のために Punycode(xn--...)を使用するか、ASCII にこだわってください。 - 使用しないスキームに
//を追加する。mailto:、tel:、sms:、magnet:はすべて//をスキップし、直接パスに進みます。mailto:user@example.comは正しい;mailto://...は違います。
その他のよくある質問
URL の最大長は何ですか?
RFC 3986 は制限を設けていません。実際には:ブラウザはアドレスバーで約 2,000 文字に制限します(Internet Explorer 11 は 2,083;Chrome と Firefox はより長いものを許容しますが、表示を切り捨てます);ほとんどの CDN とプロキシは 4,096 または 8,192 で上限;Apache や Nginx のようなサーバーはリクエスト行のデフォルトが 8,192 バイトです。2,000 文字以上必要な場合は、POST ボディに切り替えてください。
同じクエリパラメータを複数回含めることができますか?
はい。?tag=red&tag=blue&tag=green は有効です。サーバーがそれをどう解釈するかはフレームワークに依存します:Express / Node.js は req.query.tag = ['red', 'blue', 'green'] にパースします;PHP は角括弧の慣例 ?tag[]=red&tag[]=blue を必要とします;Rails は tag[] 角括弧を使用した場合に配列にパースします。URLSearchParams.getAll('tag') メソッドは、括弧スタイルに関係なく、常にすべての値を配列として返します。
クエリパラメータは SEO に影響しますか?
トラッキングパラメータ(UTM、fbclid、gclid)は一般的にオーガニック検索ランキングに影響しません。リスクは 重複コンテンツのインデックス作成 です:タグ付きの URL とそのクリーンバージョンは、クローラーには 2 つの異なるページのように見えます。修正は、すべてのタグ付きバリアントを同じ正規 URL に向ける <link rel="canonical" href="clean-url"> タグです。
URI テンプレートとは何ですか、それを使用すべきですか?
RFC 6570(2012 年 3 月)は URI テンプレートを定義します:プレースホルダーを使用したパラメータ化された URL の構文。OpenAPI / Swagger 仕様、JSON Hyper-Schema、および一部の HATEOAS API で使用されます。日常的な URL 構築では、このビルダーを介したプレーンな文字列連結の方が単純です;URI テンプレートは、API サーフェスを文書化し、クライアント SDK を生成するときに輝きます。
何かがサーバーに送信されますか?
いいえ。入力するすべてのコンポーネント、エンコーディング、および最終 URL はブラウザの JavaScript で構築されます。URL を組み立てるためにネットワーク呼び出しは行われません。DevTools のネットワークタブを開いてツールを試してください:構築中に送信リクエストがゼロであることがわかります。