Re: [apache-rus] FORCE_SOURCE_CHARSET

["Khimenko Victor" <khim@sch57.msk.ru>]

In <199903081325.TAA04250@Sky.inp.nsk.su> Eugene B. Byrganov (E.B.Byrganov@inp.nsk.su) wrote:
EB> Hi!

>>  alr> Этот patch добавляет определение оригинальной кодировки документа из тега
>>  alr> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=...">
>>  alr> при его удалении через strip-meta-http Handler.
>>  alr> Побочным действие - возможность писать utf-8 документы в 8-битовом
>> Вот второе побочное действие не может быть одобрено т.к. содержимое документа и
>> заголовок расходятся.
EB> Как раз в этом случаи совпадают -), смотри сам: что бы получить
EB> документ в utf-8 нужно ее выбрать. Не совпадение будет, только если
EB> пользователь выбрал, например, koi8-r, в META Content-Type стоит iso8859-1.




EB> Но с выбором есть проблемы:

EB> Первая, если пользователь выдал "Accept-Charset: koi8-r, *", и теперь
EB> даже если пользователь выбрал по порту или по dirpref utf-8, он ее
EB> не получит. И если для всех других кодировок русского языка это правильно,
EB> то для utf-8 нет, т.к. koi8-r по мощности не эквивалент utf-8.

Пользователь четко указал на то, что он utf-8 не поддерживает -- чего еще
он хочет ?

EB> Более того когда ставим другой язык (CharsetDecl utf-8 en), то все равно
EB> получаем koi8-r, что совсем грустно, сервер явно слаб в работе с utf-8.

Сервер четко выполняет инструкции: если browser "не умеет" utf-8, то зачем
его мучить ?

EB> Второе, есть весьма нужная команда 'CharsetByExtension', но работает она
EB> весьма странно - если перекодировка происходит, то в HTTP заголовке
EB> появляется charset=, а если нет, то нету -))). А это могло бы частично
EB> решить предыдущую проблему (CharsetByExtension utf-8 .utf) и само
EB> по себе было бы весьма правильно - выдать всю известную информацию.

Гм. Вообще-то CharsetByExtension должно указывать на кодировку документа НА
СЕРВЕРЕ. Посколько RA не умеет перекодировать ИЗ utf-8, то
CharsetByExtension utf-8 .utf как-то неясно что может значить...