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

Question

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

Когда нет явного параметра charset предоставлено отправителем, медиа подтипы типа «текст» определены как имеющие значение набора символов по умолчанию «ISO-8859-1» при получении по HTTP.

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

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

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

Answer 1

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

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

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

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

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

Источник : 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 попытается автоматически определить кодировку , используя имя домена, чтобы определить, является ли сценарий сценарием CJK, и если да, то каким. Opera также может автоматически определять UTF-8.

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

Answer 2

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

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 - Через ссылки на символы :

&
&defined-entity;

JSON - С помощью экранирующего механизма :

\u005C
\uD834\uDD1E

Теперь, что касается протокола HTTP 1.1, RFC 2616 говорит это о кодировке :

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

Answer 6

Это немного особенное для XMLHttpRequest и описано здесь: http://www.w3.org/TR/XMLHttpRequest/