# FLUIdS
Некоторые советы

- Совет #1: установка под Russian Apache.
- Совет #2: корректное задание кодировки в форме на статичной странице.

| Установка под Russian Apache |

Web сервер Russian Apache способен самостоятельно перекодировать страницы русскоязычных ресурсов (из одной кодировки в другую), даже если эти страницы сгенерированы CGI программами. Эта же функция реализована и в CGI модуле поисковой системы FLUIdS (так как системные администраторы свободны в своем выборе и необязательно остановят его на Russian Apache). Если перекодировка осуществляется одновременно и Web сервером и CGI программой, то это приводит к двойной перекодировке страниц, и их текст становится нечитаемым. Здесь нужно оставить что-нибудь одно.

В такой ситуации возможно всего два варианта:

- Перекодировкой занимается только Web север. Тогда для CGI модуля необходимо запретить самостоятельную перекодировку. Побочным эффектом такого запрещения является отсутствие на странице с бланком запроса автоматически созданного набора ссылок, соответствующего поддерживаемым кодировкам.

    Впрочем, такой набор можно создать вручную, воспользовавшись директивой FormHeaderFile конфигурационного файла 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 с указанием текущей кодировки директивой

    `Options = noMetaCharsetTag`

  в разделе main.

  Помимо этого, в такой ситуации CGI модуль не эскейпит русские буквы в ссылках, а подобные ссылки некоторыми (или плохо настроенными) браузерами обрабатываются неправильно.

  К плюсам такого подхода можно отнести тот факт, что при следовании по ссылке со статичной страницы на страницу, сгенерированную CGI модулем, пользователь всегда остается в рамках одной кодировки, так как при этом все функции определения кодировки клиента остаются у сервера. (А CGI модуль может получить имя кодировки клиента через переменную окружения `CHARSET`.)

  При этом, если рабочая кодировка FLUIdS отличается от базовой кодировки сервера Russian Apache (которая указывается директивой CharsetSourceEnc в файле httpd.conf), то в конфигурационном файле доступа Web сервера (access.conf) следует разместить подобные директивы:

  `<Location /cgi-bin/fluids.cgi>
  CharsetSourceEnc koi8-r
  </Location>`

- Перекодировкой занимается только CGI модуль. Тогда Web серверу необходимо указать, что для данного CGI модуля не нужно перекодировать сгенерированные им страницы. Это делается путем задания в конфигурационном файле доступа Web сервера (access.conf) следующих директив:

      <Location /cgi-bin/fluids.cgi>
      CharsetDisable On
      </Location>

    В старых версиях Russian Apache директива CharsetDisable носила имя CharsetTurnOff.

  В этом случае 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 модуля разрешена самостоятельная перекодировка.

  Проверить HTTP ответ можно с помощью программы Wget, задав для нее в командной строке опцию -S:

  `wget -S http://www.domain.ru/cgi-bin/fluids.cgi`

| Корректное задание кодировки в форме на статичной странице. |

У CGI модуля поисковой системы FLUIdS есть специальный параметр вызова с именем cs (сокращение от charset), значением которого является имя используемой клиентом кодировки. Если этот параметр указан при вызове CGI модуля, то считается, что и пользовательский запрос на поиск тоже находится в этой кодировке. Такая ситуация вполне обычна, если бланк запроса генерируется самим CGI модулем. Тогда в нем в скрытом виде указывается кодировка клиента, например:

  `<input type="hidden" name="cs" value="win">`

Совсем другое дело, если начальная форма создана на статичной странице. В этом случае есть несколько вариантов указания кодировки пользовательского запроса. Можно не задавать параметра cs, понадеявшись на то, что CGI модуль правильно определит кодировку клиента по данным о его браузере (согласно определениям в разделе user-agent конфигурацинного файла), но здесь можно и промахнуться. Другой вариант - попросить пользователя самому указать свою кодировку (вставив в форму соответствующую группу тегов SELECT), что тоже не хорошо, так тот совсем не обязан этого делать, не говоря уже о том, чтобы разбираться в кодировках вообще. При эксплуатации WWW сервера Russian Apache возможно использование механизма SSI, подставляя в форму в качестве значения для параметра cs значение переменной окружения CHARSET, но лучше применить следующий трюк. В форме вместо параметра cs указывается параметр word со значением ок (здесь буквы 'о' и 'к' - русские!):

  `<input type="hidden" name="word" value="ок">`

Web сервер, отдавая пользователю страницу, перекодирует ее вместе с формой и словом "ок". Тогда после отсылки запроса CGI модуль получит в качестве значения для параметра word перекодированное слово "ок", откуда и определит пользовательскую кодировку.

Подобный же трюк можно применить и для передачи определенной Web-сервером Russian Apache кодировки к CGI модулю. В этом случае ссылка на fluids.cgi может выглядеть следующим образом:

  `<a href=".../fluids.cgi?word=ок">Поиск</a>`

На главную страницу | valera@sbnet.ru