HTTPヘッダーにはどの文字エンコードを使用すればよいですか?


122

HTTPヘッダーに「楽しい」HTML特殊文字(✰)(詳細についてはhttp://html5boilerplate.com/を参照)を使用しており、Server仕様に従って「許可」されているかどうか疑問に思っています。

  • Windows Xp Pro SP 3上のChromeの開発ツールの[ネットワーク]タブを使用すると、theは問題なく表示されます。

  • IE8では、✰が正しくレンダリングされません。

  • w3.org HTMLバリデーターはそれを正しくレンダリングしません(â°代わりに" "を表示します)。

今、私は文字エンコーディングにあまり熱心ではありません...そして率直に言って、私はそれらについてあまり気にしません。私は言われたように盲目的にUTF-8 cusを使用しています。:-)


異なるパーサー/ブラウザ/エンジン/(何でも呼ばれる)のバグが原因で格差は発生していますか?

これの仕様や、HTTPヘッダーの「値」に使用できる文字のリストはありますか?


29
この質問は、一般に、「httpヘッダー値で許可されている文字はどれですか」
Akrikos


2
「今、私は文字エンコーディングにあまり熱心ではありません...率直に言って、それらについてあまり気にしません。言われたとおりにUTF-8 cusを盲目的に使用しています:-)」<--- - への必須リンク joelonsoftware.com/2003/10/08/...
d4nyll

回答:


124

つまり、ASCIIのみが動作することが保証されています。一部の非ASCIIバイトは、下位互換性のために許可されていますが、表示可能ではありません。

HTTPbisはあきらめ、ヘッダーにASCII以外の有用なエンコーディングがないことを指定しました。

歴史的に、HTTPはISO-8859-1文字セット[ISO-8859-1]のテキストを含むフィールドコンテンツを許可しており、[RFC2047]エンコーディングの使用を通じてのみ他の文字セットをサポートしていました。実際には、ほとんどのHTTPヘッダーフィールド値はUS-ASCII文字セット[USASCII]のサブセットのみを使用します。新しく定義されたヘッダーフィールドは、フィールド値をUS-ASCIIオクテットに制限する必要があります(SHOULD)。受信者は、フィールドコンテンツ(obs-text)内の他のオクテットを不透明なデータとして扱う必要があります(SHOULD)。


以前は、1999年のRFC 2616で次のように定義されています。

* TEXTの単語には、RFC 2047 [14]の規則に従ってエンコードされている場合にのみ、ISO-8859-1 [22]以外の文字セットの文字を含めることができます。

RFC 2047はMIMEエンコーディングなので、次のようになります。

=?UTF-8?Q?=E2=9C=B0?=

しかし、私は(もしあれば)多くのクライアントがそれをサポートしているとは思いません。


7
それはどういう意味ですか?「✰」は有効/許可されていますか?
デビッドマードック

8
「UTF-8」は文字セットであり、「Q」は値が「quoted-printable」になることを意味します。「B」は、値をBASE64でエンコードする場合にも使用できます。
GargantuChet 2014年

1
@porneL、「不透明なデータ」とはどういう意味ですか?これらの「不透明なデータ」を受信したとき、HTTP受信者正確に何をすべきですか?
パセリエ2014

1
@Pacerierの「不透明なデータ」とは、アプリケーションが表示または解釈してはならない大量のバイトを含むブラックボックスであることを意味します(バイナリデータなど)。何が発生するかはヘッダーによって異なり、「なし」から「破棄」までさまざまです。
Kornel 2014

@Kornel、ところでユーザー名をkornelに変更したのはなぜですか?
Pacerier

10

最初にコメントを読んでください、この回答はおそらく正しい情報源から間違った結論を導き出し、編集が必要です。


印刷可能な任意のASCII文字を使用でき、✰などの特殊文字は使用できません(ASCIIではありません)。

ヒント:JSONで何でもエンコードできます。

編集:最初は明らかではないかもしれませんが、ヘッダーで定義された文字エンコーディングは、応答本体にのみ適用され、ヘッダー自体には適用されません。(鶏と卵の問題が発生するため。)


Penchantによってリンクされた仕様に従って、関連するすべての定義をまとめたいと思います。

message-header = field-name ":" [ field-value ]
field-name     = token
field-value    = *( field-content | LWS )

したがって、私たちはfield-valueのにいます

LWS            = [CRLF] 1*( SP | HT )
CRLF           = CR LF
CR             = <US-ASCII CR, carriage return (13)>
LF             = <US-ASCII LF, linefeed (10)>
SP             = <US-ASCII SP, space (32)>
HT             = <US-ASCII HT, horizontal-tab (9)>

LWSは線形ホワイトスペースの略です。基本的に、LWSはスペースまたはタブですが、スペースまたはタブの前に新しい行を開始することにより、フィールド値を複数の行に分割できます。

これを簡単にしましょう:

field-value    = <any field-content or Space or Tab>

今、私たちはfield-contentの後にいます

field-content  = <the OCTETs making up the field-value
                 and consisting of either *TEXT or combinations
                 of token, separators, and quoted-string>
OCTET          = <any 8-bit sequence of data>
TEXT           = <any OCTET except CTLs,
                 but including LWS>
CTL            = <any US-ASCII control character
                 (octets 0 - 31) and DEL (127)>
token          = 1*<any CHAR except CTLs or separators>
separators     = "(" | ")" | "<" | ">" | "@"
                 | "," | ";" | ":" | "\" | <">
                 | "/" | "[" | "]" | "?" | "="
                 | "{" | "}" | SP | HT

TEXTは最も一般的であり、残りのすべてが含まれているため、残りについては忘れてください。 これがUS-ASCII文字セット(= ASCII)です

ご覧のとおり、印刷可能なすべてのASCII文字が許可されています。


3
あなたが引用た一節に矛盾しています。なぜ「andのような特別な文字はありません」と言うのですか?特殊文字は単なるOCTETsであり、TEXTOCTETを除くなので0 - 31、これはOCTETから32までのすべてのs 255 が許可れることを意味します。ある✰のオクテット226156および176、それらのすべての3つが許可されているが、そのため✰あなたが引用された通路に応じて許可されています。
Pacerier 2014

2
@Pacerierあなたは完全に正しいようですが、私が私がした結論を下した理由はわかりません。
zupa

@Pacerierはまだ仕様を再確認する必要があるため、編集する準備ができていません。追加の詳細がUS-ASCII文字セットに制限されていると思います。これは、結論をサポートしますが、理由付けを不十分にします。
zupa

1
「何でもJSONでエンコードできる」と言うのは少し誤解を招きます。JSONではUnicode文字を使用できますが、HTTPヘッダーはUS-ASCIIにする必要があります。Unicode文字は「不透明」データとして扱われるため、動作はHTTP仕様では定義されていません。そうは言っても、\ uXXXXエスケープシーケンスを介してUnicode文字をエスケープすることにより、JSONをHTTPヘッダーに安全に含めることができます。
ジェイコブ

@zupa、もう1つの問題は... " exceptCTLs "はどういう意味ですか?キャラクターCR、という意味LFですか?それとも、連続したシーケンス「/ 」のみが許可されるという意味ですか?(換言すれば、値は単一含むヘッダができ、または、又は?缶ヘッダの値が文字を含む、および任意の順序および量で?)CR LF SPHTCRLFHTCRLFHT
Pacerier
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.