webspace hosting reseller hosting|             | blog| forum| dating| free hosting| openhost| report abuse
Internet Fax To Email - Unlimited

Unlimited Faxes, No Fees, Dedicated Phone Number

Free Website Templates
 
 
 
На главную

Выбор кодировки

Средства разработки (например, текстовые редакторы) могут кодировать документы HTML в кодировках по своему выбору, и этот выбор существенно зависит от соглашений, используемых системным программным обеспечением. Эти средства могут использовать любую удобную кодировку, включающую большинство символов в документе, при условии, что кодировка корректно помечена. Некоторые символы, не включенные в эту кодировку, можно представить с помощью ссылок на символы. Это всегда относится к набору символов документа, а не к кодировке символов.

Серверы и прокси могут изменять кодировку символов (что называется транскодированием) на лету для выполнения запросов агентов пользователей (см. раздел 14.2 [RFC2068], заголовок запроса HTTP "Accept-Charset"). Серверы и прокси не должны обслуживать документ в кодировке, включающей весь набор символов документа.

Широко используемые в Web кодировки - ISO-8859-1 (также называется "Latin-1"; используется для большинства западноевропейских языков), ISO-8859-5 (с поддержкой кириллицы), SHIFT_JIS (японская кодировка), EUC-JP (еще одна японская кодировка) и UTF-8 (вариант кодировки ISO 10646, использующий разное число байт для разных символов). Названия кодировок символов не учитывают регистр, так что, например, "SHIFT_JIS", "Shift_JIS" и "shift_jis" эквивалентны.

Эта спецификация не определяет, какие кодировки символов должен поддерживать агент пользователя.

Соответствующие агенты пользователей должны корректно отображать в Unicode все символы в любых кодировках, которые они могут распознавать.

Замечания об определенных кодировках 

Когда текст HTML передается в UTF-16 (charset=UTF-16), текстовые данные должны передаваться в сетевом порядке байт ("big-endian", байт высшего порядка - первый) в соответствии с [ISO10646], раздел 6.3 и [UNICODE], положение C3, страница 3-1.

Более того, чтобы повысить вероятность правильной интерпретации, рекомендуется передавать документы UTF-16, всегда начиная с символа НЕРАЗДЕЛЯЮЩИЙ ПРОБЕЛ НУЛЕВОЙ ШИРИНЫ (шестнадцатеричный код FEFF, также называется Меткой порядка байтов (Byte Order Mark - BOM)), который при обращении байт становится шестнадцатеричным FFFE, никогда не назначаемым символом. Таким образом, агент пользователя, получивший шестнадцатеричный код FFFE в качестве первых байтов текста будет знать, что в остальном тексте байты нужно обратить.

Не следует использовать формат трансформации UTF-1[ISO10646] (зарегистрированный IANA как ISO-10646-UTF-1). Информацию об ISO 8859-8 и двунаправленном алгоритме см. в разделе двунаправленности и кодировки символов.

5.2.2 Указание кодировки символов

Как сервер определяет, какая кодировка символов применяется в документе? Некоторые серверы проверяют первые несколько байт документа или сверяются с базой данных известных файлов и кодировок. Многие современные серверы Web предоставляют администраторам больше возможностей управления конфигурацией набора символов, чем старые серверы. Администраторы серверов Web должны при возможности использовать следующие механизмы для отправки параметра "charset", но должны позаботиться о том, чтобы не установить для документов ошибочное значение параметра "charset".

Как агент пользователя узнает, какая использовалась кодировка символов? Эту информацию предоставляет сервер. Лучшим способом проинформировать агента пользователя о кодировке символов документа - использовать параметр "charset" в поле заголовка "Content-Type" протокола HTTP ([RFC2068], разделы 3.4 и 14.18) Например, следующий заголовок HTTP объявляет, что используется кодировка EUC-JP:

Content-Type: text/html; charset=EUC-JP

Определение text/html см. в разделе соответствие.