Organization: [ ?? IP ??? ??????? ] http://internet.comtv.ru/
Добрый вечер!
Надеюсь, это длинное письмо будет вполне топично,
т.к. оно затрагивает проблематику именно Russian Apache,
причём самую главную проблему (mod_charset),
причём в самой последней ноябрьской версии apache_1.3.33rusPL30.21.
Прошу воспринимать не как брань, в как конструктивную критику :)
[ введение ]
Я всегда пропагандировал проект Russian Apache
поскольку считал его лучшим лекарством
от ламеров-админов не знающих слова charset.
Главным образом, я выступал с позиции пользователя,
которому не нравится видеть мусор в окне браузера.
Как-то случилось,
что как админ я с Апачем до сих пор серьёзно не сталкивался.
Но грамотная документация внушала надежду,
что и на практике перекодировка работает как следует.
Судя по написанному на http://apache.lexa.ru/intro.html ,
создатели этого замечательного дистрибутива позиционируют его так же.
Т.е. было бы логично снабдить его
минимально грамотной поддержкой вывода *всех* кодировок.
Могла бы быть отличной от желаемой вебмастером "дисковая" кодировка,
какие-то приоритеты перекодирования,
но по крайне мере я ожидал, что поставленный с нуля Русский Апач
будет уже осведомлён о способах выдачи текста
во всех имеющих хождение в Сети кодировках кириллицы.
[ conf/httpd.conf ]
И что же мы видим в httpd.conf версии PL30.21?
Нету транслита, нету макинтоша... хрен с ними, в общем-то.
Но сервер же не имеет никакого понятия об UTF-8!
Причём все потребные таблицы имеются в дистрибутиве,
но нужные директивы либо "закомментированы",
либо вообще отсутствуют!
Причём я не говорю даже о _чтении_ UTF-8 с диска.
Ладно, г-н Тутубалин считает что разбор UTF-8 потребует много ресурсов,
для перегруженных сайтов м.б. это и правда...
но сервер нагло игнорирует даже Accept-Charset: UTF-8
У софта 2004 года выпуска отсутствует встроенная поддержка UTF-8.
Бывает. Понятно, переписывать модуль лень.
М.б. оно и не особенно надо, хватает и дикарских таблиц.
Но почему эти таблицы не включены в дефолтный конфиг, чёрт возьми?
Неуж-то снова из-за экономии ресурсов?
[ conf/tables/ ]
Другая проблема.
Я прекрасно знаю, что перекодировка из одного charset
в некий другой (не являющийся над-множеством),
в принципе, _неоднозначна_.
Т.е. возможно несколько версий таблиц перекодировки.
Например, есть разногласия по поводу перевода
виндового символа номер 150 (–) в KOI8.
Некоторые считают, что ему соответствует
/box drawings light horizontal/ (─),
другие же отдают предпочтение ASCII-символу дефис.
Что же мы видим у русских апачей?
Какой плюрализм, какое богатство выбора
отличных по полноте и по комментариям таблиц!
Разночтения же этих таблиц
насчёт перевода друг в друга упомянутых узких по высоте символов
сводятся гл.обр. к тому, переводить их знаком вопроса,
пробелом, вообще не упоминать (да-да, у вас бывает и такое!),
или (ну в самом хорошем случае) дефисом.
Такое впечатление, что таблицы создавались каким-то глупым автоматом
и никто из имеющих зрение не соизволил даже слегка пройти по ним шкуркой,
не то что напильником ;)
Но почему бы тогда не засунуть этот автомат внутрь самого сервера?
Нахрена нужны допотопные таблицы "с поддержкой буквы ё" и без всего остального?
Или м.б. команда Russian Apache опасается насчёт backward compatibility? :)
[ заключение ]
Моё мнение: для каждого маршрута перекодировки
в дистрибутиве должна иметься _одна_,
обточенная и выверенная специалистами таблица.
А ещё лучше научить модуль перекодировки Юникоду
и заставить его самостоятельно генерировать бОльшую часть объёма таблиц
на основе тупого сравнения кодов символов.
Оставить явные полные таблицы перекодировки
лишь как дань традиции и для подправки мелких шероховатостей.
Я мог бы попробовать этим заняться,
если это ещё кому-нибудь интересно.
Ещё раз:
очень хорошо что существует такой "русский" дистрибутив,
его создатели сделали полезную и своевременную работу,
но нынешнее состояние проекта, мягко говоря,
не тянет на современный мировой уровень :(
Уже можно встретить в некоторых конфах,
как всякие чмошники пишут что-де Russian Apache ─ дерьмо
(поскольку якобы не поддерживает UTF-8),
я лезу в httpd.conf и вижу что частичная поддержка всё-таки есть,
но какого-то хрена отключена.
Это не есть хорошо, что грамотный админ вынужден сразу хвататься за напильник
и включать в сервере то, что должно быть включено с самого начала.
Причём, если не сделано чтение
то конфликты с настоящим и будущим софтом использующим эту кодировку
при _выдаче_ информации (ну скрипты всякие интернациональные)
всё равно гарантированы.
Может, кто-то уже пробовал заниматься внедрением UTF-8 в mod_charset?
Иннокентий Маресин
--
qq~~~~\ [ ЗА IP БЕЗ ЦЕНЗУРЫ ]
/ /\ \ [ FAQ you ] http://entresol.roger.net.ru/~av95/chainik.html
\ /_/ /
\____/ Linux console notes http://entresol.roger.net.ru/linux/console/
"Russian Apache" includes software developed
by the Apache Group for use in the Apache HTTP server project
(http://www.apache.org/) See
Apache LICENSE.
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C)
1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.