Для ответов HTTP с данными символа предложения Типов контента, какой набор символов должен быть принят клиентом, если ни один не определяется?
Если никакой параметр набора символов не определяется в заголовке Типа контента, раздел RFC2616 3.7.1, кажется, подразумевает, что ISO8859-1 должен быть принят для типов среды подтипа "текст":
Когда никакой явный параметр набора символов не обеспечивается отправителем, подтипы медиа "текстового" типа определяются, чтобы иметь значение набора символов по умолчанию "ISO-8859-1" при получении через HTTP.
Данные в наборах символов кроме "ISO-8859-1" или его подмножеств ДОЛЖНЫ быть маркированы соответствующим значением набора символов.
Однако я обычно вижу приложения, которые подают файлы JavaScript со значениями Типа контента как "application/x-javascript" (т.е. никакой параметрический усилитель набора символов), даже когда эти сценарии содержат символы UTF-8 не-ASCII, которые были бы повреждены, если интерпретируется как ISO8859-1.
Это, кажется, не создает проблемы клиентам. Как клиенты знают для интерпретации байтов как UTF-8? Существует ли правило для других подтипов символьных данных, которое подразумевает, что UTF-8 должен быть значением по умолчанию? Где это документируется?
5 ответов
Все основные браузеры, которые я проверял (IE, FF и Opera), полностью игнорируют спецификацию RFC в этой части.
Если вас интересует алгоритм автоматического определения кодировки по данным, посмотрите ссылку Mozilla Firefox .
Небольшое примечание о типах содержимого: Только текст имеет наборы символов . Разумно предположить, что браузеры обрабатывают application / x-javascript так же, как они обрабатывают текст / javascript (кроме IE6, но это уже другая тема).
Internet Explorer будет использовать кодировку по умолчанию (вероятно, хранящуюся в реестре), как указано:
По умолчанию Internet Explorer использует набор символов , указанный в содержимом HTTP . тип, возвращаемый сервером для определения этого перевода. Если этот параметр не задан, Internet Explorer использует набор символов , указанный в метаэлементе в документе . Он использует настройки пользователя , если не указан метаэлемент .
Источник : http://msdn.microsoft.com/en-us/library/ms537500%28VS.85%29.aspx
Mozilla Firefox пытается автоматически определить charset, как указано здесь:
В этой статье представлены три типа методов автоопределения для определения кодировки документов без явного объявления кодировки .
Источник : http://www.mozilla.org/projects/intl/UniversalCharsetDetection.html
Opera также использует автоматическое обнаружение, как описано в документации:
Если транспорт протокол предоставляет имя кодировки, которое используется. В противном случае Opera будет искать на странице объявление кодировки. Если он отсутствует, Opera попытается автоматически определить кодировку , используя имя домена, чтобы узнать, является ли сценарий сценарием CJK, и если да, то какой именно. Opera также может автоматически определять UTF-8.
Подчеркиваем очевидное: «application / x-javascript» не является подтипом «текст».
Кроме того, текст в RFC 2616 устарел. Следующая версия HTTP / 1.1 не будет определять значение по умолчанию. См. RFC 6657 для получения дополнительной информации.
Он немного особенный для XMLHttpRequest и описан здесь: http://www.w3.org/TR/XMLHttpRequest/
Как описано в RFC 4329, также application/javascript может иметь параметр charset. Другой вопрос - обработка реализаций браузеров. Извините, но не проверено.
RFC 4329 определяет тип носителя «application / javascript» как замену «text / javascript», «application / x-javascript», и другие подобные типы. Раздел 4.2 устанавливает кодировку символов по умолчанию как UTF-8, когда нет явного параметра «charset» и нет спецификации Unicode в начале данных.