Re: [apache-rus] так где язык и где его кодировка?

[Sergey Vovk <vsv@macomnet.ru>]

On Sun, 28 Dec 1997, Alex Tutubalin wrote:

>  alr> Если маньяк администратор поставил strict, то он знал на что шел. А
>  alr> вот с тем, что совсем отключать обработку charset - это да, как-то
>  alr> неправильно в таком случае.. погорячился..
;-) это кто тут чикотила? ;-)

Я позволю себе еще одно отступление от subj...
Дело тут вот в чем, IMHO:
Нынешний apache-rus можно использовать разными
способами. ;-)
Очевидно, прижились несколько схем построения, но они как бы
недокументированы, отсюда и недопонимание. Каждый понимает, как он
привык строить свой сайт. Сайт - это httpd + config + документы + cgi +
... - то есть все вместе, когда работает. ;)

Почему бы не собрать пару-тройку вариантов построения www-site на
apache-rus, и включить их в дистрибутив, в таком составе:
    1) конфиг. файлы
    2) примеры документов htdoc (где надо, cgi, и т.п.)
    3) пояснениями, что хорошо, что плохо в таком варианте.

Понятно, что это можно сделать и без Alex, но задачу ему можно (И следует)
облегчить. Это уже обсуждали, такая "рыба", будет всяко полезной.
От себя могу предоставить комплект на случай, когда предпочтение отдано
AutoDetect на всем сайте,
принудительный выбор кодировки - только по префиксу дерева,
ссылки на images от корня сервера (как правило), ссылки в документах друг
на друга - только относительные, на сайте исключительно статические
документы (c точки зрения httpd). Всегда выдается charset=., где уместен.

> Давайте все-таки расставим точки над Ъ.
> 
> 1) Механизм Language Negotiation уже существует в Apache (MultiViews),
> каким-то образом он работает, хотя на практике неприменим из-за лени 
> пользователей.

И тем не менее, это не тот language Negotiation, который нужен
в связи с построением многоязыкового сайта (на общем конфиге),
если заняться выдачей charset=.
IMHO, он хорош для тех языков, у которых один и тот же charset =
iso8859-1, не более того. Я бы предпочел от всего, что связано с
MultiViews, отказаться полностью. Не в лени юзеров дело, не буду
повторяться.

> 2) mod_charset вступает в дело на предпоследней стадии обработки запроса,
> когда известен окончательный URL (после всех Alias/Redirect) и так далее.

OK

> 
> 3) на этом этапе модулю известны:
>  a) URL и Filename
>  b) Language документа (if any)
>  c) Заголовки запроса - Accept/Accept-Charset/Accept-Language/User-Agent
>  d) естественно, всякие настройки
> 
> 4) Задача заключается в том, чтобы выяснить charset документа, выдаваемый
> в строке Content-Type и правила перекодировки из кодировки сервера в кодировку 
> клиента.

2) и 3) я бы по другому сформулировал.
 a) известна кодировка хранения,
    может быть определена по Filename
 b) известна (предпочтительная) кодировка представления,
    м.быть определена по URL или по CharsetAgent

Очевидно, что язык определяет как бы (в общем случае
несимметричный, вспомним про транслит) комплект
таблиц преобразования между двумя кодировками - хранения и представления,
    Еще одно отступление (про 3 кодировки) сейчас делать не
    буду. ;-) Впрочем, если незнание теории будет мешать, придется...
Так что оно, по сути, называется даже не язык (Language), а....
Комплект, что ли. ;-)
Короче, он и есть то самое _правило_. Которое лично мне
хочется привязать к поддиректориям /en/, /ru/, но можно и другими
способами. Сейчас проблема только в том, что правило не весь конфиг -
одно.

> 5) Предлагается:
> a) сделать какой-то механизм объявления серверу, что такому-то Document 
> Language может соответствовать такой-то возможный список charsets.
>    Вариантов два:
>   - CharsetDecl koi8-r ru ua by
>   - CharsetLanguageBind ru koi8-r windows-1251 iso-8859-5
> 
>   При этом в обоих случаях _удобно_ (мне как программисту) понимать под
>   Charset   внутреннее название таблицы перекодировки (в большинстве
>   случаев оно  совпадает с выдаваемым пользователю
>   Content-Type:... charset=name)

С точки зрения написания конфига - эти варианты идентичны,
если приводят к однозначному определению _комплекта_ таблиц и названий
для charset=. (то есть разница между ними в компромиссе сложности
реализации и преемственности конфигов от предыдущих версий).
От понимания под charset внутреннего названия таблицы придется, похоже,
отказаться. Их ожидается больше одной.

>  б) для случая, когда внутреннее имя и имя выдаваемое пользователю не
>   совпадают, нужна какая-то директива вида:
> 
>   CharsetOverrideName internal_name language displayed_name

Похоже на OK, но что-то еще не совсем стройно выходит....
Не помешает, в любом случае.

>  в) Заголовок Accept-Charset должен обрабатываться таким образом,
>    что во внимание принимаются только charsets, определенные для данного
>    языка документа.

OK

>  г) К механизму MultiViews это не должно иметь почти никакого отношения, за
>    исключением того факта, что Document Language определяется директивой
>    AddLanguage (благо она уже есть).

Лучше бы совсем никакого отношения... Она на другую тему, эта директива.
Хотя может помочь выбрать тот самый _комплект_. Я бы предпочел его
указывать в конфиге, не опираясь на MultiViews.

> 
>  г) Этот режим должен быть выключен по умолчанию. Для включения нужна отдельная
>    директива. Я предлагаю расширить CharsetMatchLanguage  - ввести режим
>    strict который и будет делать вышеописанное.

Не факт, что это правильно. Карты Карно говорят, что кроме on/off/strict
должен быть еще 4й вариант. ;-) То есть что-то здесь "не так". ;-)


Sergey Vovk,	| http://www.macomnet.ru/~vsv/
sysadmin	| voice: +7(095)973-4002, 973-4003