QUERY_STRING

query (URL)

[9] URI の仕様書で使われている規則 query は、 URI照会部分 (最初の ? より後で、 # より前の部分) を表します。

仕様書

より具体的な構文

[11] 照会 (query) は非階層的方法で資源を識別するものとされています RFC 3986 3.4. が、それ以上の構文や意味は各 URI scheme に任されています。 (そして scheme によっては更に下位の名前空間管理者に任されています。) しかし、実際の使われ方はおおむねいくつかのパターンに当てはまります。

[12] param 方式: 名前と値の組を複数個列挙します。最もよく使われるのは名前と値の間に = を挟み、名前・値の組同士の間に & を挟んで name1=value1&name2=value2 のようにします。

などにより、幾つかのバリエーションがあります。

主な使用例:

[17] 次の場面では application/x-www-form-urlencoded が使われています。

[64] 次の場面では application/x-www-form-urlencoded+ 構文を使わないパーセント符号化が使われています。

[13] isindex 方式: 複数の値を与える時に + で区切ります。 単純な一次元配列です。

主な使用例:

[60] ismapハイパーリンク接尾辞形式

[14] Specifying time intervals in URI queries and fragments of time-based Web resources (2006-05-06 10:39:46 +09:00 版) <http://annodex.net/TR/URI_fragments.html#rfc.section.3>

[15] coffee: URL scheme では , 区切りのリストとなっています。

[22] z39.50r: / z39.50s: では、 値の後に ; 区切りで名前、=、値の組をいくつか指定できます。

メモ

  • [3] 2396 によれば、問い合わせでの予約文字は [;/?:@&=+,$] です。 ? は問い合わせのそれ以前との分離のための予約。 [&$;=] HTTP などで問合せを引数的に解釈するのによく使われるもの。残る [/:@,] はどうでしょうね? これらも CGIスクリプトなんかが意味を持たせて使っていたりするのかな。
  • [4] >>3 + が抜けてました。これはよく間隔の意味で使いますね。で、これを含めた10文字が、丁度 2396 の reserved でした。つまり、予約文字全部が予約ですと、ただそれだけの意味でした。
  • [5] >>3 / はへたれ実装対策で escape encode した方が安全というのもあるでしょう。

[8] (>>3-5 の話は間違っていませんし RFC 3986 でも変わっていませんが、 query 固有の話としては出てこなくなりました。 このあたりの話については予約文字百分率符号化の項を参照して下さい。)

[194] hypertext references and the query component (Erik van der Poel 著, 版) <http://lists.w3.org/Archives/Public/public-iri/2009Jul/0008.html>

URI query: The query component is indicated by the first question mark ("?") character and terminated by a number sign ("#") character or by the end of the URI.

[18] HTTP 上で動作するプロトコルである IPPipp: URL は、http:URL scheme を変えたものとして規定されており、 query について特別な規定はありませんでした。後に IPP over HTTPS のために規定された ipps:https:URL scheme を変えたものにあたりますが、 query は一貫性のために認めるものの、 の実装依存であることからクライアントは指定するべきではない >>19 とされています。

演算

[62] フォームの提出では、 URL記録クエリー全体を置き換える操作が行われることがあります。

[63] OAuth 1.0要求引数クエリーとする場合、 クエリーの末尾に値を追加する操作が行われます。

[65] フォームの提出では、 mailto: URL の場合、 クエリーの末尾に値を追加する操作が行われます。

用法

[79] Webアプリケーションから読み込む JavaScriptCSSキャッシュの制御のために使われることがあります。

クライアント側での query の利用

[34] Webアプリケーションは、 クライアント側で動作する JavaScript の処理により、 URL query が指定されていればその値を解釈し、 その結果に基づき動作を変化させることがあります。

[35] 素片識別子もそのように使われることがあり、一般的にはそちらが好ましいと考えられています。 しかし、サーバー側クライアント側で協調して処理したい場合など、 query を使う方が好ましい状況もあります。

第三者による query の利用

[24] 本来 query の利用方法は著者の管理下にあるものですが (もちろん任意の利用者がどのような query を使って要求を送信するかまでは制御できませんが、 本来なら想定外の query を含む場合は何も考えずに拒絶できるはずです)、 実際には第三者が query を勝手に利用することがあります。

[30] 著者 (やサーバーWebサービスの開発者) は、実用上、 query を次のように扱うべきです。

アクセス元明示のための用法

[26] リンクする時に、リンク元Webサイトがどこであるか示すことを目的にリンク先URL に何らかの query の値を付与するものがあります。

[27] 例えば SNS は、利用者URL を投稿した時に、 ?from=snsname のような query を自動的に付加するかもしれません。

[28] 例えば広告配信システムは、出稿者の指定した URL に広告配信に関する必要な情報を query として付加するかもしれません。

既読管理のための用法

[23] アンテナは、リンク先URLURL query として更新(検知)日付などの値を付け足すことがありました。 これと Webブラウザー既読リンク (:visited) と未読リンク (:link) で色を変えるなどして表示することにより、 更新後に当該 URL を表示したかどうかを Webブラウザーに管理させることができます。

[25] 本来サーバーの管理下にある query を第三者であるアンテナが勝手に使うため、 サーバーの処理に悪影響を及ぼすおそれがあります。そうでなくてもサーバーアクセスログ著者の意図せぬ query の記録が残るため、不審に思われる可能性があります。 そのため素片識別子を使うのがより良い方法と考えられていました。 ただし IE素片識別子を除いた部分で既読管理していたため、 IE で意図通り動作させるためには query を使うのもやむを得ないと考えられていました。

[29] 例えば http://www.example.com/ が 2000年1月2日に更新されていた場合、 http://www.example.com/?20000102 のような URL が示されるかもしれません。

Location インターフェイス search 属性

性質

[57] この属性は、 Unforgeable です >>36

取得器

[37] location.search取得器は、次のようにしなければなりません >>36

  1. [38] 文脈オブジェクト関係するDocument起源入口設定群オブジェクト起源同じ起源ドメインでなければ、
    1. [39] SecurityError 例外投げ、ここで停止します。
  2. [40] URLを、文脈オブジェクトURL に設定します。
  3. [41] URLquerynull空文字列なら、
    1. [42] 空文字列を返します。
  4. [43] それ以外なら、
    1. [44] ?URLquery を連結したものを返します。

設定器

[45] location.search設定器は、次のようにしなければなりません >>36

  1. [58] 入力を、与えられた値を USVString として解釈した結果に設定します。
  2. [46] 文脈オブジェクト関係するDocument起源入口設定群オブジェクト起源同じ起源ドメインでなければ、
    1. [47] SecurityError 例外投げ、ここで停止します。
  3. [48] 複製を、文脈オブジェクトURL に設定します。
  4. [49] 入力空文字列なら、
    1. [50] 複製queryを、 null に設定します。
  5. [51] それ以外なら、
    1. [53] 入力の先頭が ? なら、これを削除します。
    2. [54] 複製queryを、空文字列に設定します。
    3. [55] 入力基本URL構文解析を適用します。 URL複製状態上書きquery state とします。 符号化上書きは、文脈オブジェクト関係するDocument文書の文字符号化とします。
  6. [56] 文脈オブジェクト複製について Location-object-setter navigate を実行します。

メタ変数 QUERY_STRING (CGI)

[200] CGIメタ変数 QUERY_STRING には要求された URLquery 部分が含まれます。

仕様書

構文

[201] 構文は次のように定義されています >>202

      QUERY_STRING = query-string
      query-string = *uric
      uric         = reserved | unreserved | escaped

[203] PATH_INFO とは違って勝手にパーセント復号されることはありません。

NULL

[204] はこの値を必ず設定しなければなりませんURLquery が含まれていなければ空文字列としなければなりません>>202

[205] >>204 の規定は CGI において一般に空文字列と値の未設定を区別しないこととどう関係するのか不明瞭です。 このメタ変数に限って特別扱いしているとも読めますし、 query空文字列であっても存在しなくても一貫してメタ変数を設定しないなら良いと解釈できないこともありません。

[196] CGI の実装では Apache などは URI が /foo の場合も /foo? の場合もメタ変数 QUERY_STRING は空文字列になりますが、サーバーによっては前者は変数未定義になることもあるようです。

[197] >>196 [NCSA] 的には妥当だけど、 [COAR] 的には不当ですね。

[199] >>196 IISiPlanetQUERY_STRING をその場合設定しないそうです。

歴史

[195] [NCSA]:

The information which follows the ? in the URL which referenced this script. This is the query information. It should not be decoded in any fashion. This variable should always be set when there is query information, regardless of command line decoding.

そのスクリプトを参照する URL 中で ? に続く情報です。 これは問い合わせ情報です。 これはどんな形でも復号するべきではありません。 この変数は、問い合わせ情報があるときには常に設定するべきです。 命令行復号にかかわらずです。

[3] [COAR 03]:

A URL-encoded string; the <query> part of the Script-URI. (See section 3.2.)

URL 符号化文字列: Script-URI<query> 部分です。

  • QUERY_STRING = query-string
  • query-string = *uric

The URL syntax for a query string is described in section 3 of RFC 2396 [4].

問合せ文字列の URL 構文は RFC2396の3章で説明されています。

Servers MUST supply this value to scripts. The QUERY_STRING value is case-sensitive. If the Script-URI does not include a query component, the QUERY_STRING metavariable MUST be defined as an empty string ("").

サーバーはこの値をスクリプトに供給しなければなりません (MUST)QUERY_STRING 値は大文字・小文字を区別します。 Script-URI が問合せ部品を含まないときは、 QUERY_STRING メタ変数は空文字列 ("") として定義しなければなりません (MUST)

実装

[198] PHP では (古い書き方では) QUERY_STRING の部分を構文解析して変数名 = 引数名で値に access できますね。 ?foo=bar$foo とか。

関連

[206] query はこのメタ変数の他、スクリプト命令行としてCGIスクリプトに引き渡されることがあります。

歴史

[10] 定義の変遷:

  1. [1] query := *( uchar / reserved ) ;; RFC 1808
  2. [2] query := *uric ;; RFC 2396
  3. [6] query := *( pchar / "/" / "?" ) ;; RFC 3986

[7] RFC 3986 の定義の詳細: RFC 3986pcharunreserved / pct-encoded / sub-delims / ":" / "@" です。すなわち URI で使える文字のうち、 "#" / "[" / "]" だけが使えません。 定義としては RFC 2396 と同じです。

[207] Form of the GET method used with searches ( ( 版)) <http://www.w3.org/Protocols/HTTP/Methods/GetSearches.html>

[208] Web Application Description Language ( ( 版)) <http://www.w3.org/Submission/2009/SUBM-wadl-20090831/#x3-130002.6.1>

[210] IRC logs: freenode / #whatwg / 20131217 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20131217>

[211] Bug 23822 – Should the EventSource, Worker, and SharedWorker constructors resolve the URL using utf-8? ( ( 版)) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23822>

[212] Clean up set the input algorithm now all URLs have a query · 217cf06 · whatwg/url ( ( 版)) <https://github.com/whatwg/url/commit/217cf06b9d2b7fbbbf65eec9d1ea9fce66fec8bf>

[20] Do not encode ` in query. Fixes #17. · whatwg/url@f54c44d ( 版) <https://github.com/whatwg/url/commit/f54c44d1f790dd2b8913e955ba6d334c6f14a048>

[21] Bug 26338 – Limit query encoding override to http/https ( 版) <https://www.w3.org/Bugs/Public/show_bug.cgi?id=26338>

[52] Comment out query/queryAll/Elements for now · whatwg/dom@10b6cf1 ( 版) <https://github.com/whatwg/dom/commit/10b6cf1ba02806220d5461a3bdb7939728b73635>

[59] Merge effective script origin into origin · whatwg/html@8a843f2 ( 版) <https://github.com/whatwg/html/commit/8a843f2169a6864a3024c4329528dccb2051d275>

[61] Remove isindex handling from application/x-www-form-urlencoded · whatwg/url@c85fb5d ( 版) <https://github.com/whatwg/url/commit/c85fb5d527f822e089aecc9207f077c6b886aed5>

[66] Align with changes in Selectors ( (annevk著, )) <https://github.com/whatwg/dom/commit/1594aa52357371354780750413ad88e9e8a2b56b>

[67] 284474 – Converting to UTF-8 a url with an unescaped non-ASCII chars in the query part leads to an incompatibility with most server-side programs ( ()) <https://bugzilla.mozilla.org/show_bug.cgi?id=284474>

[68] URL 生成ツール - アナリティクス ヘルプ () <https://support.google.com/analytics/answer/1033867?hl=ja>

[69] URL パラメータ ツールでパラメータを分類する - Search Console ヘルプ ( ()) <https://support.google.com/webmasters/answer/6080550?hl=ja>

アクティブ パラメータ

アクティブ パラメータは、ページのコンテンツを変えることができます。たとえば、brand、gender、country、sortorder はアクティブ パラメータです。以下に、アクティブ パラメータによる一般的なコンテンツ変更を示します。

並べ替え(例: sort=price_ascending): コンテンツが表示される順番を変更します。

絞り込み(例: t-shirt_size=XS): ページのコンテンツをフィルタリングします。

特定(例: store=women): ページに表示されるコンテンツを特定します。

翻訳(例: lang=fr): コンテンツの翻訳版を表示します。

ページ指定(例: page=2): 長いリストや記事の特定のページを表示します。なお、直接コンテンツをページ指定することもできます。

パッシブ パラメータ

パッシブ URL パラメータは、ユーザーに表示されるコンテンツには影響しません。多くの場合、アクセスやリファラーを追跡する目的で使用しますが、実際のページのコンテンツに影響することはありません。たとえば、次の URL はすべて同じコンテンツを指しています。

http://www.example.com/products/women/dresses?sessionid=12345

http://www.example.com/products/women/dresses?sessionid=34567

http://www.example.com/products/women/dresses?sessionid=34567&source=google.com

パッシブ パラメータには、sessionid、affiliateid などがあります。

[70] Apache Tomcat Configuration Reference (6.0.45) - The HTTP Connector (Craig R. McClanahan著, ) <http://tomcat.apache.org/tomcat-6.0-doc/config/http.html>

URIEncoding

This specifies the character encoding used to decode the URI bytes, after %xx decoding the URL. If not specified, ISO-8859-1 will be used.

useBodyEncodingForURI

This specifies if the encoding specified in contentType should be used for URI query parameters, instead of using the URIEncoding. This setting is present for compatibility with Tomcat 4.1.x, where the encoding specified in the contentType, or explicitly set using Request.setCharacterEncoding method was also used for the parameters from the URL. The default value is false.

[71] Editorial: give URL syntax components their own terms (annevk著, ) <https://github.com/whatwg/url/commit/451696e4297c4c676fae21dbc926aeafb2477e6c>

[73] Signature Calculations for the Authorization Header: Transferring Payload in a Single Chunk (AWS Signature Version 4) - Amazon Simple Storage Service () <http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html>

CanonicalQueryString specifies the URI-encoded query string parameters. You URI-encode name and values individually. You must also sort the parameters in the canonical query string alphabetically by key name. The sorting occurs after encoding.

[74] Web Annotation Protocol () <https://w3c.github.io/web-annotation/protocol/wd/#h-container-representations>

The IRI of the Container provided in the response should differentiate between whether the pages contain just the IRIs, or the full descriptions of the Annotations. It is recommended that this be done with a query parameter.

[75] Versioning · API.AI ( ()) <https://docs.api.ai/docs/versioning>

All API.AI requests should be made with the versioning v parameter in the URL.

The approach is similar to the Foursquare versioning policy. So, for example, the query requests should be made to the endpoint /query?v=20150910.

The v parameter is formatted as YYYYMMDD.

The parameter indicates that you are ready to handle API version as of the specified date.

[76] documentation/API.md at master · tootsuite/documentation () <https://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md>

When an array parameter is mentioned, the Rails convention of specifying array parameters in query strings is meant. For example, a ruby array like foo = [1, 2, 3] can be encoded in the params as foo[]=1&foo[]=2&foo[]=3. Square brackets can be indexed but can also be empty.

[77] java - Tomcat 8 is not able to handle get request with '|' in query parameters? - Stack Overflow ( ()) <http://stackoverflow.com/questions/41053653/tomcat-8-is-not-able-to-handle-get-request-with-in-query-parameters>

[78] RFC 8141 - Uniform Resource Names (URNs) () <https://tools.ietf.org/html/rfc8141#section-2.3>

[80] BitBake User Manual () <http://www.yoctoproject.org/docs/2.4/bitbake-user-manual/bitbake-user-manual.html#http-ftp-fetcher>

Because URL parameters are delimited by semi-colons, this can introduce ambiguity when parsing URLs that also contain semi-colons, for example:

SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git;a=snapshot;h=a5dd47"

Such URLs should should be modified by replacing semi-colons with '&' characters:

SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47"

In most cases this should work. Treating semi-colons and '&' in queries identically is recommended by the World Wide Web Consortium (W3C). Note that due to the nature of the URL, you may have to specify the name of the downloaded file as well:

SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47;downloadfilename=myfile.bz2"

[81] Use the API URL character encoding for XMLHttpRequest (annevk著, ) <https://github.com/whatwg/xhr/commit/6f14c60f5ae81381c12ff50f5f6898a1583b570d>

[82] Use document encoding for URL parser · Issue #159 · whatwg/xhr () <https://github.com/whatwg/xhr/issues/159>

[83] Use document encoding for URL parser · Issue #159 · whatwg/xhr () <https://github.com/whatwg/xhr/issues/159>

[84] Use the API URL character encoding for XMLHttpRequest by annevk · Pull Request #172 · whatwg/xhr () <https://github.com/whatwg/xhr/pull/172>

[85] Meta: remove query/queryAll comments (annevk著, ) <https://github.com/whatwg/dom/commit/510fa87968f0db76d7e86e0abb3f32e9ed2ac811>

[86] Do not throw for query() and queryAll() · Issue #39 · whatwg/dom () <https://github.com/whatwg/dom/issues/39>

[87] WebSub () <https://w3c.github.io/websub/#subscriber-sends-subscription-request>

Subscribers MAY also include additional HTTP [RFC7230] request parameters, as well as HTTP [RFC7230] Headers if they are required by the hub.

Hubs MUST ignore additional request parameters they do not understand.

[88] 62273 – Add support for alternate URL specification () <https://bz.apache.org/bugzilla/show_bug.cgi?id=62273>

[89] Change query state slightly to better deal with non-UTF-8 encodings (annevk著, ) <https://github.com/whatwg/url/commit/f0e4390bf882446445e944215524ff3877aac95a>

[90] "html" error mode somewhat incompatible with URLs · Issue #139 · whatwg/encoding () <https://github.com/whatwg/encoding/issues/139>

[91] Change query state slightly to better deal with non-UTF-8 encodings by annevk · Pull Request #386 · whatwg/url () <https://github.com/whatwg/url/pull/386>

[92] 795733 - '&' and ';' should not be percent-encoded in URL queries - chromium - Monorail () <https://bugs.chromium.org/p/chromium/issues/detail?id=795733>

[93] Editorial: avoid setting encoding multiple times (annevk著, ) <https://github.com/whatwg/url/commit/b385374e5d1b48f82b8040395786469ae655f435>

[94] Change query state slightly to better deal with non-UTF-8 encodings by annevk · Pull Request #386 · whatwg/url () <https://github.com/whatwg/url/pull/386>

[95] Percent-encode ' in queries of URLs with special schemes (achristensen07著, ) <https://github.com/whatwg/url/commit/6ef17ebe1220a7e7c0cfff0785017502ee18808b>

[96] percent-encode ' in queries of URLs with special schemes · Issue #348 · whatwg/url () <https://github.com/whatwg/url/issues/348>

[97] percent-encode ' in queries of URLs with special schemes by achristensen07 · Pull Request #395 · whatwg/url () <https://github.com/whatwg/url/pull/395>