Re: [apache-talk] meta charset problems

["Serge Shikov" <shikov@xxxxxxxx>]

----- Original Message -----
From: Vladimir Bormotov <bor@xxxxxxxxxxxxxx>
Subject: Re: [apache-talk] meta charset problems


> Угу, для поддержки "тупых" серверов, которые не умеют выдавать
> нормальные заголовки http.
А при чем тут META? Заголовки заголовками, но эту информацию
(метаданные) где-то нужно задавать. Никакой самый умный сервер за тебя
ее не придумает. META - это не больше и не меньше, как способ задать
такие данные в _HTML документе_.  А еще можно в конфиге Апача.

>> В данном случае нет ни поддержки, ни хромого ;-)
>
> ПОддержка есть. Именно в _сервере_. И Именно выдаются верные
заголовки.
> Хромого действительно нет. Давно уже. :)
Ну да, выдаются. Но другим способом. Откуда "очевидно", что все
остальные способы кривые? Представь себе, что ты сайт свой мирроришь
куда-нибудь под IIS. Что мы делаем с META? А ничего - отдаем как было. А
что с .htaccess? Выбрасываем - потому что в отличие от это -
специфически апачевская фича. Это такой условный пример, почему META
(как фича, описанная не где-то там, а в стандарте HTML) может быть более
прямым способом, чем апачевский. Причем _может_, а не является.

>> Так вот - в полном соответствии со стандартом META - один из
разрешенных
>> способов. Ну и?
>
> Что и? При пользовании Rassian Apache этот способ _не_рекомендуется_,
> потому как сервер пооддерживает более правильный способ. Что тут не
> понятно?
Тут все непонятно. Во-первых, ниоткуда не следует, что способ указывать
метаданные где-то в конфиге сервера - самый правильный и единственно
верный. Мы уже выяснили, что и там и там можно задать чарсет более
одного раза. Или еще как-то ошибиться.

Рекомендация - это и есть рекомендация. Ну например Тутубалин так
считает (на основе своего опыта). У других может быть другой опыт, и
самое главное - другие потребности/условия. Поэтому от слов
"правильный" - никакого толку. Надо добавлять в чем правильнее. Вот я и
пытался показать, в чем META может быть правильнее. Но я не настаиваю -
опровергни, на здоровье. Только фактами, а не словами "этот способ
гораздо лучше вон того" ;-)

>Причем даже можно сказать больше - этот способ _вреден_.
Вреден он потенциально, при условвии, что ты META _отдаешь наружу_.
Никто этого не предлагает, можешь перечитать еще раз и убедиться.

>> > Угу, а сам meta выкусывать :)
>> А почему бы и нет? Например charset выкусывать, а остальные - без
>> изменений. И опять это было бы в полном соответствии, потому что
>> "использовать" не означает "отдавать клиенту".
>
> Ну не знаю, тут нужно послушать Алекса, он как-то уже рассказывал
> почему именно он так поступает с meta charset
Ну так я уже слушал, причем неоднократно. Поступает он так по простым
соображениям эффективности, которые в общем всем хорошо видны, и с
которыми никто опять же не спорит. И откуда вывод, что способ "вреден"?
Он неэффективен, причем _при такой организации обработки_ в Апаче. А при
другой возможно будет полезен.

>> > Только вот как быть с тем, что этих самых meta может быть _куча_ по
>> > документу?
>> Во-первых, не по документу, а только внутри HEAD, рекомендуется - как
>> можно раньше. Но опять же - и что? Это не более, чем небольшая
>> недоработка в спецификации.
>
> Обработку которой достаточно сложно реализовать в сервере.
А ее вовсе не надо _на каждый запрос_ организовывать. Надо из META _один
раз_ взять метаданные при обновлении документа, и потом _использовать_
их при каждом запросе. Отпарсить документ вообще-то не сложно, если это
часть процедуры upload страницы на сайт.

>> А как прикажете быть с тем, что где-то в .htaccess тоже можно указать
>> кодировку для одного и того же файла более одного раза?
>
> А как это обрабатывается апечем? Ведь действовать то будет только
одна?
А я помню? Главное что никакой принципиальной разницы с несколькими META
тут не будет. И .htaccess все равно нужно парсить, хотя конечно это
делается более эффективно.

> Так проблема в том, что если мне нужно в одном документе три куска
> русского текста, в разных черсетах, то как сервер перекодирует все
> в один?
Да нет конечно. Еще раз - META внутри HEAD, какие еще три куска в разных
чарсетах? Для этого есть другие средства в HTML 4.0, но к META они
отношения не имеют. Кстати как Апач такой документ переварит - мне
непонятно.

>> уточню - про эффективность я ничего не говорил и не стану. Речь о
>> другом - с META можно работать по стандарту, используя его по
>> основному назначению.
>
> Я вот, например не уверен что это всегда возможно.
Ну я тоже не пробовал, но не вижу никакой причины, которая бы помешала
использовать META как тэг _для сервера_, который клиенту не отдается.

> Так вот и решили, что лучше пользовать "другую часть стандарта",
Кто решил, и для каких условий? Не люблю я такие решения, честно говоря.
Предпочитаю свои выводы делать, ясно понимая, как и почему.

> правильно настроить сервер чтоб он отдавал всю информацию, правильно.
Что значит "настроить"? Представь что у тебя сайт делают разные люди. В
разных продуктах, разных ОС etc. В том числе - в разных кодировках, и в
том числе - в пределах одного каталога. Что проще:
 - научить их правильно ставить META (это умеют практически все средства
разработки), и написать скрипт, который при выкладывании файла на сайт
использовал бы META, и сам генерировал .htaccess;
- научить их же ставить кодировку где-то в .htaccess (а для этого
сначала пустить их туда - и что они там направят)?

То есть речь как раз о технологии настройки - я не предлагаю динамически
что-то с тэгами делать все по тем же очевидным причинам - это медленно.


=============================================================================
=               Apache-Talk@xxxxxxxxxxxxx mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =