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

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

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

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

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

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


http content-type default character-encoding rfc2616
person rewbs    schedule 24.02.2010    source источник

Ответы (6)


arrow_upward
15
arrow_downward

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

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

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

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

По умолчанию Internet Explorer использует набор символов, указанный в типе содержимого HTTP, возвращаемом сервером, для определения этого преобразования. Если этот параметр не задан, Internet 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/

person Sagi    schedule 27.02.2010

arrow_upward
2
arrow_downward

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

person Arne Burmeister    schedule 28.02.2010

arrow_upward
2
arrow_downward

При отсутствии параметра 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» используется с некоторыми типами мультимедиа для определения набора символов (раздел 3.4) данных. Когда отправитель не предоставляет явного параметра набора символов, подтипы мультимедиа типа «текст» определяются так, чтобы иметь значение набора символов по умолчанию «ISO-8859-1» при получении через HTTP. Данные в наборах символов, отличных от «ISO-8859-1» или его подмножеств, ДОЛЖНЫ быть помечены соответствующим значением набора символов. См. раздел 3.4.1 о проблемах совместимости.

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

person DavidRR    schedule 10.10.2013
comment
Ссылки на символы или escape-последовательности не имеют ничего общего с кодировкой символов прилагаемого документа... - person Julian Reschke; 10.10.2013
comment
@ Джулиан - Согласен. Я соответствующим образом изменил структуру своего ответа. (Я чувствую, что стоит включить упоминание об отсылках к персонажам и побегах.) - person DavidRR; 10.10.2013

arrow_upward
1
arrow_downward

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

person Remy Lebeau    schedule 05.03.2010
comment
Моя интерпретация раздела 4.2 состоит в том, чтобы не предполагать, что UTF-8 является кодировкой символов по умолчанию. Кроме того, во вступлении к разделу 4 говорится: То, как реализации определяют схему кодирования символов, может зависеть от правил обработки, которые выходят за рамки этого документа. - person DavidRR; 10.10.2013

arrow_upward
0
arrow_downward

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

person Sam Dark    schedule 24.02.2010

arrow_upward
0
arrow_downward

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

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

person Julian Reschke    schedule 24.02.2010
comment
Согласитесь - поэтому вопрос: существует ли правило для подтипов символьных данных, отличных от текста? Если да, то где это задокументировано? - person rewbs; 24.02.2010
comment
Общего правила нет, так как тип носителя может быть не основан на символах... - person Julian Reschke; 26.02.2010
comment
Вопрос конкретно о тех типах носителей, которые предлагают символьные данные. Если нет общего правила, существуют ли специальные правила для разных типов носителей? Где они задокументированы? Должны существовать как минимум некоторые правила, учитывая, что клиенты должны принимать решение о том, как интерпретировать байты. - person rewbs; 26.02.2010
comment
Конкретные правила должны быть указаны в документе, на который указывает регистрация типа носителя, например tools.ietf. org/html/rfc3023#section-3.2 для приложения/xml. - person Julian Reschke; 01.03.2010