Яке кодування символів слід використовувати для заголовка HTTP?

Я використовую "веселий" HTML-спеціальний символ (✰) (див. Http://html5boilerplate.com/ для отримання додаткової інформації) для ServerHTTP-заголовка, і мені цікаво, чи дозволено це за специфікацією.

• Використовуючи вкладку «Мережа» в інструментах розробників у Chrome на Windows Xp Pro SP 3, я бачу ✰ просто чудово.

• У IE8 ✰ не відображається правильно.

• HTML-код валідатора w3.org не відображає його правильно ( â°натомість відображає " ").

Тепер я не надто захоплююсь кодуванням символів ... і, чесно кажучи, я не дуже переймаюся ними; Я просто сліпо використовую UTF-8, про що мені кажуть. :-)

Чи невідповідність викликана помилками в різних аналізаторах / переглядах / двигунах / (як би їх не називали)?

Чи є специфікація для цього чи, можливо, список дозволених символів для HTTP-заголовка "значення"?

Коротше кажучи: лише ASCII гарантовано працює. Деякі байти, що не належать до ASCII, дозволені для зворотної сумісності, але вони не мають бути відображеними.

HTTPbis відмовився і уточнив, що в заголовках немає корисного кодування, крім ASCII:

Історично склалося, що HTTP дозволив вміст поля з текстом у наборі ISO-8859-1 [ISO-8859-1], підтримуючи інші діаграми лише за допомогою кодування [RFC2047]. На практиці більшість значень поля заголовка HTTP використовують лише підмножину діаграми US-ASCII [USASCII]. Нещодавно визначені поля заголовка ДОЛЖНО обмежувати значення своїх полів октетами US-ASCII. Одержувач ОБОВ'ЯЗКОВО трактує інші октети з вмістом поля (непрозорий текст) як непрозорі дані.

Раніше RFC 2616 з 1999 року визначав це:

Слова * TEXT МОЖУТЬ містити символи з наборів символів, відмінних від ISO-8859-1 [22], лише якщо їх кодують за правилами RFC 2047 [14].

і RFC 2047 - кодування MIME , тож було б:

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

але я не думаю, що багато (якщо такі є) клієнтів підтримують це.

Будь ласка, прочитайте спочатку коментарі, ця відповідь, ймовірно, робить неправильні висновки з правильних джерел, потребує редагування.

Ви можете використовувати будь-які символи для друку ASCII, а також ніякі спеціальні символи типу ✰ (Що не є ASCII )

Порада : у JSON можна закодувати будь-що.

Правка : спочатку може бути не очевидною, кодування символів, визначене у заголовку, застосовується лише для тіла відповіді, а не для самого заголовка. (Як це може спричинити проблему з куркою - яйцями.)

Я хотів би підбити підсумки всіх відповідних визначень відповідно до специфікації, пов’язаної Penchant.

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 означає лінійний простір білого кольору. По суті, LWS - це пробіл або вкладка, але ви можете розділити значення поля на кілька рядків, запустивши новий рядок перед пробілом або вкладкою.

Давайте спростимо це до цього:

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

ТЕКСТ - найзагальніший і включає в себе все інше - щоб забути про відпочинок. Ось діаграма США-ASCII (= ASCII)

Як бачите, всі друковані символи ASCII дозволені.