Для ответов HTTP с Content-Types, предлагающими символьные данные, какую кодировку следует принимать клиенту, если ни один не указан?

Если в заголовке Content-Type не указан параметр charset, RFC2616 раздел 3.7.1, как представляется, подразумевается, что ISO8859-1 следует принять за типы мультимедиа подтипа "текст":

Если не указан явный параметр charset предоставленные отправителем, подтипы СМИ типа "text" определены как имеющие значение кодировки по умолчанию для "ISO-8859-1" при получении через HTTP.

Данные в наборах символов, отличных от "ISO-8859-1" или его подмножества ДОЛЖНЫ быть помечены соответствующей кодировкой значение.

Тем не менее, я регулярно вижу приложения, которые обслуживают файлы Javascript со значениями Content-Type, такими как "application/x-javascript" (т.е. параметр charset), даже если эти скрипты содержат символы, отличные от ASCII UTF-8, которые будут поврежден, если он интерпретируется как ISO8859-1.

Это не создает проблем для клиентов. Как клиенты знают, как интерпретировать байты как UTF-8? Есть ли правило для других подтипов данных символов, которое подразумевает, что UTF-8 должен быть по умолчанию? Где это документировано?

ОТВЕТЫ

Ответ 1

Все основные браузеры, которые я проверил (IE, FF и Opera), полностью игнорируют спецификацию RFC в этой части.

Если вас интересует алгоритм автоматического определения кодировки по данным, посмотрите Mozilla Firefox.

Небольшая заметка о типах контента: Только текст имеет набор символов. Разумно предположить, что браузеры обрабатывают приложение /x -javascript так же, как они обрабатывают text/javascript (кроме IE6, но этот другой объект).

Internet Explorer будет использовать кодировку по умолчанию (возможно, хранящуюся в реестре), как указано:

По умолчанию Internet Explorer использует набор символов, указанный в HTTP тип содержимого, возвращаемый сервером определите этот перевод. Если это параметр не указан, Интернет Проводник использует набор символов заданный метаэлементом в документ. Он использует предпочтения, если никакой мета элемент указано.

Источник: http://msdn.microsoft.com/en-us/library/ms537500%28VS.85%29.aspx

Mozilla Firefox пытается автоматически определить кодировку, как указано здесь:

В этом документе представлены три типа методов автоматического обнаружения для определения кодировок документов без явного объявления набора символов.

Источник: http://www.mozilla.org/projects/intl/UniversalCharsetDetection.html

Opera также использует автоматическое обнаружение:

Если транспортный протокол содержит имя кодировки, которое используется. Если нет, Opera будет смотреть на страницу для объявления кодировки. Если этого не хватает, Opera попытается автоматически определить кодировку, используя имя домена, чтобы увидеть, является ли script CJK script, и если да, то какой. Opera также может автоматически обнаруживать UTF-8.

Источник: http://www.opera.com/docs/specs/opera9/

Ответ 2

Как описано в RFC 4329, также application/javascript может иметь параметр charset. Другой вопрос - обработка реализаций браузера. Извините, но не проверен.

Ответ 3

В отсутствии параметра charset кодировка символов может быть указана в контенте. Ниже приведены некоторые подходы к нескольким типам контента:

HTML - через метатег:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

вариант HTML5:

<meta charset="utf-8">

XML (XHTML, KML) - через объявление XML:

<?xml version="1.0" encoding="UTF-8"?>

Текст. Через Значок порядка байтов. Например, для UTF-8 первые три байта файла в шестнадцатеричном формате:

EF BB BF

В отличие от набора символов, связанного с документом, обратите внимание также, что символы, отличные от ASCII, могут быть закодированы через последовательности символов ASCII с использованием различных подходов:

HTML - Через символьные ссылки:

&#nnnn;
&#xhhhh;

XML - Через символьные ссылки:

&amp;
&defined-entity;

JSON - через механизм экранирования:

\u005C
\uD834\uDD1E

Теперь, в отношении протокола HTTP 1.1, RFC 2616 говорит об этом в charset:

Параметр "charset" используется с некоторыми типами носителей для определения набор символов (раздел 3.4) данных. Когда нет явной кодировки параметр предоставляется отправителем, подтипы мультимедиа типа "текст" определяются как значения по умолчанию для кодировки "ISO-8859-1", когда полученных через HTTP. Данные в наборах символов, отличных от "ISO-8859-1" или его подмножества ДОЛЖНЫ быть помечены соответствующим значением кодировки. Видеть раздел 3.4.1 для проблем совместимости.

Итак, моя интерпретация вышеизложенного заключается в том, что нельзя принимать набор символов по умолчанию, за исключением подтипов мультимедиа типа "текст". Конечно, мы живем в реальном мире, и исполнители не всегда следуют правилам. Как описано в принятом ответе, различные поставщики веб-браузера внедрили свои собственные стратегии для определения набора символов документа, если он явно не указан. Можно предположить, что поставщики других клиентов (например, Google Планета Земля) также реализуют свои собственные стратегии.

Ответ 4

RFC 4329 определяет тип носителя "application/javascript" в качестве замены для "text/javascript", "application/x-javascript" и другие подобные типы. Раздел 4.2 устанавливает кодировку символов по умолчанию как UTF-8, если нет явного параметра "charset", и в передней части данных нет спецификации Unicode.

Ответ 6

Указывая на очевидное: "application/x-javascript" не является подтипом "text".

Кроме того, текст в RFC 2616 устарел. Следующая версия HTTP/1.1 не будет определять значение по умолчанию. См. RFC 6657 для получения дополнительной информации.