Установка под Russian Apache |
Web сервер Russian Apache способен самостоятельно перекодировать страницы русскоязычных ресурсов (из одной кодировки в другую), даже если эти страницы сгенерированы CGI программами. Эта же функция реализована и в CGI модуле поисковой системы FLUIdS (так как системные администраторы свободны в своем выборе и необязательно остановят его на Russian Apache). Если перекодировка осуществляется одновременно и Web сервером и CGI программой, то это приводит к двойной перекодировке страниц, и их текст становится нечитаемым. Здесь нужно оставить что-нибудь одно.
В такой ситуации возможно всего два варианта:
FormHeaderFile = charset-list.htm
где содержимое файла charset-list.htm может быть примерно таким:
<p> <center><hr width="90%" size=2 noshade> <table border=0><tr align="center" valign="middle"> <td><img src="charset-icon.gif"></td> <td><a href="http://www.domain.ru:8081/cgi-bin/fluids.cgi"><tt><b><big>KOI</big></b></tt></td> <td><a href="http://www.domain.ru:8082/cgi-bin/fluids.cgi"><tt><b><big>WIN</big></b></tt></td> <td><a href="http://www.domain.ru:8083/cgi-bin/fluids.cgi"><tt><b><big>ALT</big></b></tt></td> <td><a href="http://www.domain.ru:8084/cgi-bin/fluids.cgi"><tt><b><big>ISO</big></b></tt></td> <td><a href="http://www.domain.ru:8085/cgi-bin/fluids.cgi"><tt><b><big>MAC</big></b></tt></td> </tr></table> <hr width="90%" size=2 noshade></center> |
Соответственно, в конфигурационном файле CGI модуля необходимо запретить выдачу тега META с указанием текущей кодировки директивой
в разделе main.
Помимо этого, в такой ситуации CGI модуль не эскейпит русские буквы в ссылках, а подобные ссылки некоторыми (или плохо настроенными) браузерами обрабатываются неправильно.
К плюсам такого подхода можно отнести тот факт, что при следовании по ссылке со статичной страницы на страницу, сгенерированную CGI модулем, пользователь всегда остается в рамках одной кодировки, так как при этом все функции определения кодировки клиента остаются у сервера. (А CGI модуль может получить имя кодировки клиента через переменную окружения CHARSET.)
При этом, если рабочая кодировка FLUIdS отличается от базовой кодировки сервера Russian Apache (которая указывается директивой CharsetSourceEnc в файле httpd.conf), то в конфигурационном файле доступа Web сервера (access.conf) следует разместить подобные директивы:
<Location /cgi-bin/fluids.cgi>
CharsetSourceEnc koi8-r
</Location>
<Location /cgi-bin/fluids.cgi> CharsetDisable On </Location>
В этом случае CGI модуль автоматически создает список ссылок, по одной на каждую поддерживаемую им кодировку. Но при таком подходе возникает проблема определения кодировки клиента, частично разрешаемая с помощью директив раздела user-agent конфигурационного файла CGI модуля. (К сожалению, в подобной ситуации сервер Russian Apache не устанавливает переменную окружения CHARSET или ей подобную, а надо бы...). Полностью эта проблема снимается с помощью CGI параметра word.
Двойная перекодировка (даже если она не приводит к прямой порче перекодируемого текста) таит в себе еще одну проблему. CGI модуль, сгенерировав страницу, может сообщить ее кодировку через тег META (если это не запрещено в кофигурационном файле директивой Options), например:
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=koi8-r">
а Web сервер, перекодировав страницу (или даже не перекодировав, если он считает, что страница находится в "правильной" кодировке), передать ее кодировку (уже другую) в HTTP ответе:
Content-Type: charset=text/html;charset=windows-1251
Результат подобной интерферренции зависит уже от браузера. Поэтому необходимо, чтобы HTTP ответ не содержал указаний о кодировке, производимых сервером, если для CGI модуля разрешена самостоятельная перекодировка.
wget -S http://www.domain.ru/cgi-bin/fluids.cgi |
Корректное задание кодировки в форме на статичной странице. |
У CGI модуля поисковой системы FLUIdS есть специальный параметр вызова с именем cs (сокращение от charset), значением которого является имя используемой клиентом кодировки. Если этот параметр указан при вызове CGI модуля, то считается, что и пользовательский запрос на поиск тоже находится в этой кодировке. Такая ситуация вполне обычна, если бланк запроса генерируется самим CGI модулем. Тогда в нем в скрытом виде указывается кодировка клиента, например:
Совсем другое дело, если начальная форма создана на статичной странице. В этом случае есть несколько вариантов указания кодировки пользовательского запроса. Можно не задавать параметра cs, понадеявшись на то, что CGI модуль правильно определит кодировку клиента по данным о его браузере (согласно определениям в разделе user-agent конфигурацинного файла), но здесь можно и промахнуться. Другой вариант - попросить пользователя самому указать свою кодировку (вставив в форму соответствующую группу тегов SELECT), что тоже не хорошо, так тот совсем не обязан этого делать, не говоря уже о том, чтобы разбираться в кодировках вообще. При эксплуатации WWW сервера Russian Apache возможно использование механизма SSI, подставляя в форму в качестве значения для параметра cs значение переменной окружения CHARSET, но лучше применить следующий трюк. В форме вместо параметра cs указывается параметр word со значением ок (здесь буквы 'о' и 'к' - русские!):
Web сервер, отдавая пользователю страницу, перекодирует ее вместе с формой и словом "ок". Тогда после отсылки запроса CGI модуль получит в качестве значения для параметра word перекодированное слово "ок", откуда и определит пользовательскую кодировку.
Подобный же трюк можно применить и для передачи определенной Web-сервером Russian Apache кодировки к CGI модулю. В этом случае ссылка на fluids.cgi может выглядеть следующим образом:
На главную страницу | valera@sbnet.ru |