[1] q 引数 (品質値quality value) は、 内容折衝等において選択肢の優先(希望)度を表す小数値です。

仕様書

定義と用語

[7] HTTP の最新仕様である RFC 7231 では、小数値のことを品質値 (qvalue)、それを値として持つ q 引数全体のことを「重み」 (weight) と呼んでいます。

[15] ただし、なぜか TE: ヘッダーでだけは小数値のことを 「階数」 (rank)、 q 引数全体のことを t-ranking と呼んでいます。

[16] 呼称と定義は別々ですが、実質的に両者は同一です。

文脈

[11] TE: ヘッダーの q 引数は、転送符号化の名前と引数の後に1つだけ指定できます >>9。

[18] Accept: ヘッダーの q 引数は、媒体範囲の後に1つだけ指定できます。 q 引数の後の引数は、媒体範囲に属するものではなく、 Accept: の引数とみなされます。

[19] Accept-Charset: ヘッダーの q 引数は、文字コード範囲の後に1つだけ指定できます。

[20] Accept-Encoding: ヘッダーの q 引数は、内容符号化の名前の後に1つだけ指定できます。

[21] Accept-Language: ヘッダーの q 引数は、言語範囲の後に1つだけ指定できます。

[22] これらいずれのヘッダーも、リスト (#) であり、 複数の値を指定することができます。 q は、 そのそれぞれの値に対する引数として記述できるものです。 TE: と Accept: では q より前に引数を指定することができ、それらは q 引数の指定対象である値の一部分と解釈されます。 Accept: では q 引数より後に引数を指定することができ、それらは q 引数と同様に値に関するオプションと解釈されます。 これら以外では、 q 以外の引数は認められていません。

[40] source-quality

構文

[10] ;、q=、値の順に記述します。ただし ; の前後には OWS を置けます。また q は大文字でも構いません。 >>9, >>17

[13] 転送符号化や Accept: など他の HTTP の引数の構文とは違って、 = の前後の BWS は認められていませんし、 値を引用文字列にすることも認められていません。

[12] 値は、0以上1以下の十進数を表すASCII数字の列です。 ただし小数点は . で表し、整数部は1桁、小数部は最大3桁とします。 整数のみや、整数と小数点のみの表記も認められています。 >>9, >>17

  1. ;
  2. |
    1. q
    2. Q
  3. =
  4. |
    1. =
      1. 0
      2. ?
        1. .
        2. *
          1. 数字
    2. =
      1. 1
      2. ?
        1. .
        2. *
          1. 0

[14] 送信者は、受け入れられるものが複数ある時に、 q 引数によって優先度を指定することができます。 1 が最も好ましいことを表し、 0.001 が最も好ましくないことを表します >>9, >>17。 0 は受け入れられないことを表します >>9, >>17。

零の値

[25] 値 0 は、その指定対象の値が受け入れられないオプションであることを表しています。

[26] ただし、それが意図通り解釈されるかどうかは不明瞭です。 q を無視するナイーブな実装では、逆に受け入れられるオプションの一つとして解釈されてしまいます。

既定値

[23] q 引数が指定されていない場合の既定値は、 1 です >>17。

[24] なぜか TE: については既定値の規定がありません。

同位の値

[27] 複数のオプションが指定されていて、それらの q が同値であるとき、どう解釈するべきなのかは不明です。

[28] 電子メールの Accept-Language: ヘッダーでは、 出現順を優先順位と考えるような言及があります。

原始品質

[29] 異体説明で使われる原始品質source quality >>28 は HTTP 本体のq値に相当するものです。構文も意味も似ていますが、 要求で要求度を示すのではなく、応答で完全度を示すために使われます。

[31] 原始品質は、当該異体に関する折衝可能資源の表現としての品質を表します。 これは当該異体を可能な最高の出力媒体に完璧なレンダリングエンジンでレンダリングした時の値です。言語の翻訳やMIME型の表現能力の品質も表します。 >>28

[32] 構文としては q 引数の値と同じものを採用しています >>28。 q= は含みません。

[33] 1未満の値は、有損失変換による劣化の度合いを表します >>28。

[34] JPEG の写真を XBM に変換すると値は小さくなりますし、 ASCIIアートにすると更に小さくなります。 >>28

[35] 逆にASCIIアートが原典なら、それを撮影して JPEG にすると値は小さくなります >>28。

[30] 次のように値の目安が定められています >>28。

      1.000  perfect representation
      0.900  threshold of noticeable loss of quality
      0.800  noticeable, but acceptable quality reduction
      0.500  barely acceptable quality
      0.300  severely degraded quality
      0.000  completely degraded quality
[36] この目安は局所異体選択アルゴリズムにおいてレンダリング方法の品質を表現するためにも使えます >>28。

文脈

[37] q 引数は次のヘッダーに存在します。

[38] Accept-Features: にはありません。

[39] 品質値はその他に異体説明でも使われます。つまり Alternates: ヘッダー内に現れることがあります。

歴史

[8] RFC 2068・2616 (HTTP/1.1) 3.9 Quality Values

HTTP content negotiation (section 12) uses short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has a quality value of 0, then content with this parameter is `not acceptable' for the client. HTTP/1.1 applications MUST NOT generate more than three digits after the decimal point. User configuration of these values SHOULD also be limited in this fashion.

[2] HTTP 内容折衝は、 各折衝可能引数の相対重要度 (「重み」) を示すために短い「浮動小数点」 数値を使います。重みは 0 から 1 の範囲の実数に正規化します。 0 が最小値で、 1 が最大値です。 引数の質値が 0 の場合、その引数が添えられた内容をクライアントは「受入れ不能」です。 HTTP/1.1 応用は、小数点以下に3桁より多くの数字を生成してはなりません。 この値の利用者設定もこの様式に制限するべきです。

  • [3] qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] )

"Quality values" is a misnomer, since these values merely represent relative degradation in desired quality.

[4] 「質値」という名前は誤りです。この値は単に望まれる質の相対的な格を表現するに過ぎないからです。

メモ

[5] >>1 のような値を紹介している解説もしばしば見かけます。。。 (名無しさん 2006-12-25 10:44:40 +00:00)