Jakiego kodowania znaków należy używać w nagłówku HTTP?

Używam „zabawnego” specjalnego znaku HTML (✰) (zobacz http://html5boilerplate.com/, aby uzyskać więcej informacji) dla Servernagłówka HTTP i zastanawiam się, czy jest on „dozwolony” według specyfikacji.

• Korzystając z karty Sieć w narzędziach programistycznych w przeglądarce Chrome w systemie Windows Xp Pro SP 3, widzę ✰ w porządku.

• W IE8 ✰ nie jest poprawnie renderowane.

• Walidator HTML w3.org nie renderuje go poprawnie ( â°zamiast tego wyświetla „ ”).

Otóż, nie przepadam za kodowaniem znaków… i szczerze mówiąc nie przejmuję się nimi zbytnio; Po prostu ślepo używam UTF-8, bo tak mi powiedziano. :-)

Czy rozbieżność jest spowodowana błędami w różnych parserach / przeglądarkach / silnikach / (jakkolwiek one się nazywają)?

Czy jest na to specyfikacja, czy może lista dozwolonych znaków dla „wartości” nagłówka HTTP?

W skrócie: tylko ASCII gwarantuje działanie. Niektóre bajty inne niż ASCII są dozwolone ze względu na wsteczną kompatybilność, ale nie powinny być wyświetlane.

HTTPbis zrezygnował i stwierdził, że w nagłówkach nie ma żadnego użytecznego kodowania poza ASCII:

Historycznie, HTTP zezwalał na zawartość pola z tekstem w zestawie znaków ISO-8859-1 [ISO-8859-1], obsługując inne zestawy znaków tylko poprzez użycie kodowania [RFC2047]. W praktyce większość wartości pól nagłówka HTTP wykorzystuje tylko podzbiór zestawu znaków US-ASCII [USASCII]. Nowo zdefiniowane pola nagłówka POWINNY ograniczać ich wartości do oktetów US-ASCII. Odbiorca POWINIEN traktować inne oktety w treści pola (obs-text) jako nieprzezroczyste dane.

Wcześniej RFC 2616 z 1999 definiował to:

Słowa * TEXT MOGĄ zawierać znaki z zestawów znaków innych niż ISO-8859-1 [22] tylko wtedy, gdy są kodowane zgodnie z zasadami RFC 2047 [14].

a RFC 2047 to kodowanie MIME , więc byłoby:

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

ale nie sądzę, że wielu (jeśli jacyś) klientów to obsługuje.

Najpierw przeczytaj komentarze, ta odpowiedź prawdopodobnie wyciąga błędne wnioski z właściwych źródeł, wymaga edycji.

Możesz użyć dowolnych drukowalnych znaków ASCII i żadnych specjalnych znaków, takich jak ✰ (co nie jest ASCII )

Wskazówka : w JSON możesz zakodować wszystko.

Edycja : na początku może nie być oczywiste, kodowanie znaków zdefiniowane w nagłówku dotyczy tylko treści odpowiedzi, a nie samego nagłówka. (Ponieważ spowodowałoby to problem z kurczakiem i jajkiem).

Chciałbym podsumować wszystkie istotne definicje zgodnie ze specyfikacją, do której link zawiera Penchant.

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

Więc szukamy wartości pola .

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 oznacza Linear White Space. Zasadniczo LWS to spacja lub tabulator, ale możesz podzielić wartość pola na wiele wierszy, rozpoczynając nowy wiersz przed spacją lub tabulatorem.

Uprośćmy to do tego:

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

Teraz szukamy treści terenowych .

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

TEKST jest najbardziej ogólny i zawiera całą resztę - więc zapomnij o reszcie -. Oto zestaw znaków US-ASCII (= ASCII)

Jak widać, wszystkie drukowalne znaki ASCII są dozwolone.