Russian Apache Switch to English
Switch to Russian koi8-r
windows=1251
cp-866
iso8859-5
Russian Apache Как это работает Рекоммендации Где взять Как установить Как настроить Статус и поддержка
Краткий обзор FAQ Список рассылки Благодарности Поиск по серверу Powered by Russian Apache
Russian Apache mailing list archive (apache-rus@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[apache-rus] no UTF-8 in default httpd.conf



Добрый вечер!

Надеюсь, это длинное письмо будет вполне топично, 
т.к. оно затрагивает проблематику именно 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/






Спонсоры сайта: Информация о smtp relay для отправки локальных, электронных сообщений.

[ Russian Apache ] [ Как это работает ] [ Рекомендации ] [ Где взять ] [ Как установить ] [ Как настроить ] [ Статус и поддержка ] [ Краткий обзор ] [ FAQ ] [ Список рассылки ] [ Благодарности ] [ Поиск по серверу ] [ Powered by Russian Apache ] [ Apache-talk archive ]

"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.