我正在使用“有趣”的HTML特殊字符(✰)(有关详细信息,请参阅http://html5boilerplate.com/)获取Server
HTTP标头,并且想知道每个规范是否“允许”
在Windows Xp Pro SP 3上使用Chrome中的开发工具中的网络标签我看到✰很好。
在IE8中,✰ 无法正确呈现。
w3.org HTML验证器不正确呈现它(改为显示“â°
”。
现在,我对字符编码并不太热衷......坦率地说,我并不太关心它们;我只是盲目地使用UTF-8 cus我被告知。 : - )
不同解析器/浏览/引擎/中的错误导致的差异(无论他们被称为什么)?
是否有针对此标题的规范或HTTP标头“值”的允许字符列表?
答案 0 :(得分:106)
简而言之:只保证ASCII能够正常工作。允许一些非ASCII字节用于向后兼容,但不应该是可显示的。
HTTPbis gave up并指定在标题中除了ASCII之外没有有用的编码:
历史上,HTTP允许字段内容包含文本 ISO-8859-1 charset [ISO-8859-1],仅支持其他字符集 通过使用[RFC2047]编码。在实践中,大多数HTTP标头 字段值仅使用US-ASCII字符集[USASCII]的子集。 新定义的标题字段应该将其字段值限制为 US-ASCII八位字节。收件人应该在字段中处理其他八位字节 内容(obs-text)为不透明数据。
以前,1999年的RFC 2616定义了这个:
* TEXT的字可能包含ISO-以外的字符集中的字符 8859-1 [22]仅在根据RFC 2047 [14]的规则编码时。
和RFC 2047是MIME encoding,所以它是:
=?UTF-8?Q?=E2=9C=B0?=
但我不认为很多(如果有的话)客户支持它。
答案 1 :(得分:10)
请先阅读评论,这个答案可能会从正确的来源得出错误的结论,需要编辑。
你可以使用任何可打印的ASCII字符,也没有像✰那样的特殊字符(不是ASCII)
提示:您可以使用JSON编码任何内容。
编辑:起初可能不明显,标题中定义的字符编码仅适用于响应正文,而不适用于标题本身。 (因为这会引起鸡和鸡的问题。)
我想根据Penchant链接的spec总结所有相关定义。
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
所以,我们追求的是字段值。
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代表Linear White Space。本质上,LWS是Space或Tab,但您可以通过在Space或Tab之前开始一个新行来将您的字段值分成多行。
让我们简化它:
field-value = <any field-content or Space or Tab>
现在我们正在追踪字段内容。
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是最通用的,包括所有其余的 - 所以忘了其余的 - 。 Here is the US-ASCII charset(= ASCII)
如您所见,允许使用所有可打印的ASCII字符。