クエリ文字列

クエリ文字列は、指定されたパラメータに値を割り当てる URL (Uniform Resource Locator) の一部です。クエリ文字列には通常、Web ブラウザやその他のクライアント アプリケーションによって基本 URL に追加されたフィールドが含まれます。たとえば、HTML ドキュメントの一部として、ページの外観を選択したり、マルチメディア コンテンツ内の位置にジャンプしたりする場合などです。

Web サーバーは、URLパスに基づいてファイル システムからファイルを読み取るか、リソースの種類に固有のロジックを使用して要求を処理することによって、ハイパーテキスト転送プロトコル(HTTP) 要求を処理できます。特別なロジックが呼び出される場合、クエリ文字列は、URL のパス コンポーネントとともに、そのロジックで処理に使用できます。

クエリ文字列を含む一般的な URL は次のとおりです。

https://example.com/over/there?name=ferret

サーバーがそのようなページのリクエストを受信すると、プログラムを実行し、クエリ文字列（この場合は ）をname=ferret変更せずにプログラムに渡します。疑問符は区切り文字として使用され、クエリ文字列の一部ではありません。^{[1] [2]}

Webフレームワークは、クエリ文字列内の複数のパラメータを何らかの区切り文字で区切って解析するメソッドを提供する場合があります。^{[3]以下のURLの例では、複数のクエリパラメータが}アンパサンド「 」で区切られています&。

https://example.com/path/to/page?name=ferret&color=purple

クエリ文字列の正確な構造は標準化されていません。クエリ文字列を解析するために使用される方法は、Web サイトによって異なる場合があります。

Web ページ内のリンクには、クエリ文字列を含む URL が含まれる場合があります。HTMLでは、ユーザー エージェントがクエリ文字列を生成する 3 つの方法が定義されています。

• 要素を介したHTMLフォーム<form>...</form>
• 要素の属性を介してサーバー側のイメージマップを作成する。ismap<img><img ismap>
• <isindex>非推奨の要素によるインデックス検索

元々の用途の 1 つは、 HTML フォーム ( Web フォームとも呼ばれます)のコンテンツを格納することでした。特に、フィールド 、 を含むフォームが送信されるとfield1、field2フィールドfield3のコンテンツは次のようにクエリ文字列としてエンコードされます。

field1=value1&field2=value2&field3=value3...

• クエリ文字列は、一連のフィールドと値のペアで構成されます。
• 各ペア内では、フィールド名と値は等号「=」で区切られます。
• 一連のペアは、アンパサンド「&」で区切られます (セミコロン「;」はW3Cでは推奨されていません。以下を参照してください)。

明確な標準はないが、ほとんどのウェブフレームワークでは、1つのフィールドに複数の値を関連付けることができる（例：field1=value1&field1=value2&field2=value3）。^{[4] [5]}

フォームの各フィールドに対して、クエリ文字列にはペアが含まれます。Web フォームには、ユーザーには表示されないフィールドが含まれる場合があります。これらのフィールドは、フォームが送信されるときにクエリ文字列に含まれます。 field=value

この規則はW3Cの勧告です。^[3] 1999年の勧告では、W3Cはすべてのウェブサーバーがアンパサンド区切り文字に加えてセミコロン区切り文字をサポートすることを推奨しました。 ^{[6]これにより、HTML文書内のURLで}application/x-www-form-urlencodedクエリ文字列をエンティティエスケープアンパサンドなしで使用できるようになりました。2014年以降、W3Cはクエリ区切り文字としてアンパサンドのみを使用することを推奨しています。^[7]

フォームのコンテンツは、フォームの送信方法がGET の場合にのみ、URLのクエリ文字列にエンコードされます。送信方法がPOSTの場合、デフォルトで同じエンコードが使用されますが、結果は変更されたURLに含まれるのではなく、HTTPリクエスト本体として送信されます。 ^[8]

HTMLにフォームが追加される前は、ブラウザは–<isindex>要素を1行のテキスト入力コントロールとしてレンダリングしていました。このコントロールに入力されたテキストは、ベースURLまたは属性で指定された別のURLのGETリクエストに追加されたクエリ文字列としてサーバーに送信されました。[9]これは、Webサーバーが提供されたテキストをクエリ条件として使用して、一致するページのリストを返すことができるようにするためのものでした。^{[10 ]}action

インデックス検索コントロールに入力されたテキストが送信されると、次のようにクエリ文字列としてエンコードされます。

argument1+argument2+argument3...

• クエリ文字列は、テキストをスペースで単語に解析することによって、一連の引数で構成されます。
• シリーズはプラス記号「+」で区切られます。

要素<isindex>は非推奨であり、ほとんどのブラウザはもはやこれをサポートまたはレンダリングしませんが、インデックス検索の名残はまだいくつか残っています。たとえば、これはブラウザの URL パーセント エンコーディング内でプラス記号' ' を特別に処理する原因です+(インデックス検索が非推奨となった現在では、 とほとんど同じです%20)。また、CGI をサポートする一部の Web サーバ( Apacheなど) は、クエリ文字列に等号' 'が含まれていない場合、クエリ文字列をコマンド ライン引数として処理します=(CGI 1.1 のセクション 4.4 による)。一部の CGI スクリプトは、HTML に埋め込まれた URL に対してこの歴史的な動作をまだ利用しています。

一部の文字はURL の一部にはならず (たとえばスペース)、その他の一部の文字は URL で特別な意味を持ちます。たとえば、 文字は文書のサブセクション (またはフラグメント#)をさらに指定するために使用できます。HTML フォームでは、 文字は名前と値を区切るために使用されます。URI 汎用構文ではこの問題に対処するためにURL エンコードを使用しますが、HTML フォームではこのような文字すべてにパーセントエンコードを適用するのではなく、追加の置換を行います。スペースは ' ' または " "としてエンコードされます。^[11]=+%20

HTML 5 では、 HTML フォームを「GET」メソッドで Web サーバーに送信するための次の変換が指定されています。次に、アルゴリズムの簡単な概要を示します。

• 正しい文字セットに変換できない文字は、HTMLの数値文字参照に置き換えられます^[12]
• +スペースは ' ' または ' %20'としてエンコードされます
• 文字（A-Zとa- z）、数字（0- 9）、および文字「~'」、「-'」、「.'」および「 ' _」はそのまま残ります
• +%2Bでエンコードされています
• %HH その他の文字はすべて16進数表現としてエンコードされ、非ASCII文字は最初にUTF-8（またはその他の指定されたエンコード）としてエンコードされます。

チルダ (" ~") に対応するオクテットは、RFC3986 によってクエリ文字列で許可されていますが、HTML フォームでは " " にパーセントエンコードする必要があります%7E。

SPACE を ' ' としてエンコードし+、「そのまま」の文字を選択することで、このエンコードは RFC 3986 と区別されます。

フォームが次のようにHTMLページに埋め込まれている場合:

<フォーム アクション= "/cgi-bin/test.cgi" メソッド= "get" > 
  <入力 タイプ= "text" 名前= "first"  /> 
  <入力 タイプ= "text" 名前= "second"  /> 
  <入力 タイプ= "submit"  /> 
</フォーム>

ユーザーが 2 つのテキスト フィールドに「これはフィールドです」および「(すでに)クリアされましたか?」という文字列を入力し、送信ボタンを押すと、プログラム(上記の例の要素の属性test.cgiによって指定されたプログラム) は次のクエリ文字列を受け取ります 。 action form first=this+is+a+field&second=was+it+clear+%28already%29%3F

フォームがCGIスクリプトによってサーバー上で処理される場合、スクリプトは通常、クエリ文字列をという名前の環境変数として受け取ります。 QUERY_STRING

クエリ文字列を受信したプログラムは、その一部または全部を無視することができます。要求された URL がプログラムではなくファイルに対応する場合、クエリ文字列全体が無視されます。ただし、クエリ文字列が使用されているかどうかに関係なく、それを含む URL 全体がサーバーログ ファイルに保存されます。

これらの事実により、クエリ文字列を使用して、HTTP クッキーによって提供される方法と同様の方法でユーザーを追跡できます。これを機能させるには、ユーザーがページをダウンロードするたびに、一意の識別子を選択し、そのページに含まれるすべてのリンクの URL にクエリ文字列として追加する必要があります。ユーザーがこれらのリンクの 1 つをクリックするとすぐに、対応する URL がサーバーに要求されます。このようにして、このページのダウンロードは前のページとリンクされます。

たとえば、次のような内容を含む Web ページが要求された場合:

 < a  href = "foo.html" >私のページを見てください! </ a > 
 < a  href = "bar.html" >私のページの方が良いです</ a >

のような一意の文字列e0a72cb2a2c7が選択され、ページは次のように変更されます。

 < a  href = "foo.html?e0a72cb2a2c7" >私のページを見てください! </ a > 
 < a  href = "bar.html?e0a72cb2a2c7" >私のページの方が良いです</ a >

クエリ文字列を追加しても、ページがユーザーに表示される方法は変わりません。たとえば、ユーザーが最初のリンクをたどると、ブラウザはfoo.html?e0a72cb2a2c7サーバーにページを要求しますが、サーバーは後続のリンクを無視して?、期待どおりにページを送信しfoo.html、そのリンクにもクエリ文字列を追加します。

こうすることで、このユーザーからの以降のページ リクエストに同じクエリ文字列が含まれるようになり、これらすべてのページが同じユーザーによって閲覧されたことを確認できます。クエリ文字列は、多くの場合、 Web ビーコンe0a72cb2a2c7と組み合わせて使用​​されます。

追跡に使用されるクエリ文字列と HTTP クッキーの主な違いは次のとおりです。

1. クエリ文字列は URL の一部を形成するため、ユーザーが URL を保存したり別のユーザーに送信したりする場合に含まれます。Cookie はブラウジング セッション間で維持されますが、URL と一緒に保存または送信されることはありません。
2. ユーザーが 2 つ (またはそれ以上) の独立したパスで同じ Web サーバーに到達した場合、保存される Cookie は同じですが、2 つの異なるクエリ文字列が割り当てられます。
3. ユーザーは Cookie を無効にすることができますが、その場合、追跡に Cookie を使用することは機能しません。ただし、追跡にクエリ文字列を使用することは、あらゆる状況で機能するはずです。
4. ページへの異なるアクセスによって渡されるクエリ文字列が異なると、ページがブラウザ (またはプロキシ (存在する場合)) のキャッシュから提供されなくなり、Web サーバーの負荷が増加し、ユーザー エクスペリエンスが低下します。

HTTP仕様によると:

実際には、リクエストラインの長さにはさまざまなアドホックな制限があります。すべてのHTTP送信者と受信者は、少なくとも8000オクテットのリクエストラインの長さをサポートすることが推奨されます。^[13]

URL が長すぎる場合、Web サーバーは414 Request-URI Too Long HTTP ステータス コードで失敗します。

これらの問題に対する一般的な回避策は、GETの代わりにPOST を使用し、パラメータをリクエスト ボディに格納することです。リクエスト ボディの長さ制限は、通常、URL の長さ制限よりもはるかに高くなります。たとえば、POST サイズの制限は、IIS 4.0 ではデフォルトで 2 MB、IIS 5.0 では 128 KB です。この制限は、Apache2 のディレクティブを使用して構成できます。このディレクティブは、リクエスト ボディで許可されるバイト数を 0 (無制限を意味する) から 2147483647 (2 GB) まで指定します。^[14]LimitRequestBody

• URIフラグメント
• URI 正規化
• URL (ユニフォーム リソース ロケータ)
• クリーンなURL
• クリック識別子
• 共通ゲートウェイ インターフェース(CGI)
• HTTP クッキー
• ハイパーテキスト転送プロトコル(HTTP)
• セマンティック URL
• URI スキーム
• UTMパラメータ
• ウェブビーコン