WWW
Ввиду того, что документы на русскоязычных серверах могут храниться в различных кодировках, а пользователь-клиент может понимать далеко не все кодировки, возникает задача корректной передачи электронных документов пользователю и отображения текста программой, с помощью которой пользователь просматривает электронный документ.
Наилучшим решением была бы реализация такого подхода, который предоставил бы пользователю возможность работы с электронными документами в языковой (кодовой) среде, используемой его операционной системой, автоматически производя перекодировку всех данных. Отметим, что задача перекодировки данных является не такой уж простой, как кажется на первый взгляд. Основные трудности порождаются наличием преобразований кодировок, не имеющих обратных преобразований. Поэтому при применении ошибочного преобразования часть информации может быть утеряна.
Проблема кириллических кодировок может решаться различными методами в зависимости от способов хранения документов на сервере, организации взаимодействия сервера с клиентской программой и от пользовательской оболочки, которая применяется для просмотра документов. Однако пока ни один из существующих методов не дает решения проблемы.
Наиболее простой для администратора сервера метод решения проблемы - предоставление доступа ко всем документам в какой-либо одной кодировке. Как правило, по этому пути идут последователи Relcom'а - приверженцы UNIX-систем, которые размещают файлы в кодировке KOI8-R.
Существует достаточно устойчивое мнение считать кодировку KOI8-R универсальной для внутреннего представления документов не только на серверах, но и для текстовых процессоров типа TeX. Это мнение обосновывается тем, что в UNIX-системах отсутствует механизм внутренней перекодировки типа TCP, а шрифты с другими кодировками пока еще не имеют достаточного распространения
Если WWW-сервер работает только в одной кодировке, то пользователь должен сам позаботиться об установке необходимых шрифтов и о конфигурировании своей программы просмотра. До середины 1996 г. (т.е. до принятия стандарта HTML 3.2) пользователю это сделать в большинстве случаев было несложно. Графические просмотрщики, работающие в средах MS Windows и XWindows (например, программные оболочки Netscape Navigator, MS Internet Explorer или Mosaic), позволяют принудительно задать шрифт с нужной кодировкой для отображения текста документов, а соответствующие шрифты имеются для разных кодовых таблиц.
При стандартном просмотре документа через графический просмотрщик, как правило, применяются два семейства графических шрифтов, установленных в используемой графической оболочке: это пропорциональный шрифт (обычно Times Roman) и равноширинный шрифт (обычно Courier). Просмотрщики, поддерживающие стандарт HTML 3.2 (Netscape и MS Internet Explorer), могут использовать и другие шрифты, установленные в системе. В HTML 3.2 считается стандартным применение в качестве дополнительного пропорционального шрифта третьего семейства шрифтов, которое называется шрифт без отсечек (семейство шрифтов типа Arial, Lucida, Sans, Helvetica). Однако для дополнительного шрифта пока не предусмотрена возможность устанавливать его имя принудительно. Здесь и возникает основная трудность, связанная с использованием одной кодировки. Если используемая для просмотра кодировка не является кодировкой операционной системы клиента, то он вынужден держать на своем компьютере два2 или более семейства шрифтов одного наименования, присвоив второму семейству нестандартное имя. Поэтому вместо текста, который набран дополнительным шрифтом, пользователь получит бессмысленный набор символов (поскольку стандартное имя шрифта, как правило, соответствует кодировке компьютера пользователя-клиента).
Стандарт HTML 3.2 допускает использование любого семейства шрифтов, если вам известно его имя на пользовательской машине. В случае, если данное семейство отсутствует, происходит подстановка пропорционального шрифта.
С другой стороны, если сервер организован правильно (то есть с соответствующими указателями charset в поле Content-Type), то пользователь может не устанавливать дополнительные шрифты на свой компьютер, но, к сожалению, пока нет просмотрщика, который бы полностью и корректно проводил перекодировку для всех кодовых таблиц русского языка. Netscape Navigator в среде MS Windows (кроме Windows NT) корректно работает пока только с кодировками CP1251 и ISO-8859-5, а для кодировки KOI8-R он требует установки дополнительных шрифтов. MS Internet Explorer пока не понимает кодировку ISO-8859-5, а для кодировки KOI8-R некорректно работает со специальными символами, такими, как, например, "тире" (встроенная система перекодировки правильно перекодирует только текст). Mosaic не имеет средств поддержки MIME.
Таким образом, принудительный выбор кодировки имеет большие неудобства. Во-первых, в настоящее время вы вынуждены отказаться от полного использования возможностей языка HTML 3.2 (дополнительных шрифтов, спецсимволов и др.). Во-вторых, "блуждая" по сети и переходя с сервера на сервер, вы будете вынуждены менять настройки своего просмотрщика, так как разные серверы работают с разными кодировками. В-третьих, теряется возможность копировать фрагменты текста документа в буфер обмена и переносить их в текстовые процессоры без дополнительной перекодировки.
Несмотря на то, что современные просмотрщики WWW-страниц имеют возможность выбора кодовой страницы и уже в своем большинстве понимают MIME, абсолютно корректно они работают пока только в "родной" языковой среде операционной системы.
Поэтому в настоящее время единственно правильным решением проблемы, связанной с отображением русскоязычных текстов, является предоставление пользователю информации во всех кодировках русского языка (по крайней мере, в наиболее распространенных кодировках KOI8-R и CP1251). Отметим, что этот способ пока является наиболее распространенным и используется на большинстве российских серверов. Чаще всего пользователю предлагается выбор из двух кодировок: KOI8-R и CP1251 (MS Windows). Кодировки CP866 (MS DOS), ISO-8859-5 и MacOS на российских серверах представлены значительно реже (заметим, что встречаются серверы, предлагающие русские тексты с латинской транслитерацией русских букв).
При использовании нескольких кодировок русского языка право выбора кодировки предоставляется, как правило, пользователю, хотя встречаются и исключения. Чаще всего на начальной странице WWW-сервера предлагается выбрать кодировку, в которой пользователь-клиент предпочитает общаться с сервером. В этом случае на сервере должно быть организовано хранение копий документов в нескольких кодировках (что требует дополнительного дискового пространства) или динамическое перекодирование документов в реальном времени перед отправкой их пользователю.
В целом выбор кодировки пользователем из меню пока является наиболее приемлемым решением, однако оно вынуждает пользователя считывать лишнюю страницу с сервера лишь для того, чтобы выбрать на ней нужную кодировку, что не очень удобно, особенно для медленных линий связи.
Используя возможности протокола HTTP, можно упростить задачу для пользователя, заставив сервер попытаться самостоятельно распознать кодировку программы-клиента, после чего перекодировать документы из локальной кодировки, принятой на сервере, в кодировку клиента или автоматически переключить пользователя на страницы с нужной кодировкой. Для этого в заголовке запроса перечисление допустимых форматов документов (Content- Type) должна указываться требуемая кодировка. Программа-клиент должна быть для этого специальным образом сконфигурирована. В этом случае пользователь может не задумываться о том, в какой кодировке хранится информация на сервере.
Перечислим все наиболее распространенные способы представления документов на сервере с использованием множественности кодировок русского языка.
Хранение всей базы документов одновременно в нескольких кодировках в разных подкаталогах либо на разных виртуальных серверах.
Использование одной базы документов и динамическая перекодировка в зависимости от подкаталога или адреса виртуального сервера.
Определение кодировки клиента по ключевым словам в имени просмотрщика (браузера).
Установка сервера на разных портах для разных кодировок над одной (с перекодировкой) базой документов.
Установка сервера (или нескольких серверов) на разных портах для разных кодировок над несколькими базами документов, соответствующих разным кодировкам.
Хранение базы адресов клиентов и их кодировок.
Обработка всех выдаваемых документов с помощью специальной программы на сервере (например, CGI-script).
В свою очередь, язык HTML позволяет подсказать клиенту используемую в документе кодировку путем добавления специальной команды (тэга - tag) МЕТА в заголовок документа (<META HTTP-EQUIV ...>).
Тег <META HTTP-EQUIV ...> был разработан и введен в стандарт HTML (он, как минимум, упоминается в Draft на HTML 3.2) для того, чтобы указать HTTP-серверу какие именно заголовки HTTP он может выставить. Как написано в draft HTML-3.2, это именно пожелание для сервера и не более. Драфт HTML 4.0 в этом смысле более четок - он позволяет WWW-клиенту учитывать тег <META HTTP-EQUIV> при определении кодировки, но при наличии HTTP-заголовка "Content-Type:... charset=...", кодировка должна определяться по HTTP-заголовку.
К сожалению, авторы WWW-броузеров (это относится и к Netscape Navigator и к Microsoft Internet Explorer) либо не читают стандартов, либо читают их как-то странно. Возможно, у них даже благие намерения. Когда такие броузеры встречают в документе таг
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows1251">
они перестают обращать внимание на корректный (т.е. соответствующий реальной кодировке) HTTP-заголовок Content-Type: и отображают документ в соответствии со своими представлениями об этом Charset (т.е. Netscape меняет шрифт на тот, который установлен для koi8-r, а MS IE перекодирует из KOI8 в cp1251). Более того, эти броузеры обращают внимание на этот тег даже в том случае, когда он встречается внутри <BODY> ... </BODY>, что уже ни в какие ворота не лезет (интересно, что они будут делать, когда в документе есть несколько противоречивых <META HTTP-EQUIV...> ?).
В стандарте языка HTML-3.2 утверждается, что команда МЕТА НТТР-EQUIV имеет смысл, только когда документ получен с помощью протокола НТТР. НТТР-серверы должны использовать значение данного атрибута для добавления его в заголовок НТТР-ответа (RFC-822). Этот атрибут не может применяться для задания некоторых особенных полей заголовка. Например, для того чтобы указать, что в документе используется кодировка KOI8-R, можно включить в заголовок документа (то есть в области между <HEAD> и </HEAD>) следующую строку:
По идее, эта МЕТА-информация должна относиться только к тому моменту, когда документ выдается сервером. Нет требования к клиенту обращать внимание на эти тэги, однако большинство продолжает их обрабатывать со времен протокола HTTP/0.9. Здесь следует отметить, что просмотрщики корректно обрабатывают эти указатели в случае, если они правильно сконфигурированы, но часть информации выдается просмотрщиком так называемым системным шрифтом (это касается окна status, Java-script'ов и выбора из меню). Системный шрифт определяется локализацией языка в операционной системе и не изменяется просмотрщиком.
|