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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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

&
&defined-entity;

JSON - Через спасательный механизм:

\u005C
\uD834\uDD1E

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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