Re: [apache-talk] meta charset problems

["Vladimir Bormotov" <bor@xxxxxxxxxxxxxx>]

            Hi!

> > Угу, для поддержки "тупых" серверов, которые не умеют выдавать
> > нормальные заголовки http.
> А при чем тут META?

 META сама по себе совершенно не причем.

> Заголовки заголовками, но эту информацию (метаданные) где-то нужно
> задавать.

 Я _второй_ раз прошу тебя не тормози, с сконцентрируйся на
_конкретных_ метаданных http-quiv.

> Никакой самый умный сервер за тебя ее не придумает.

 http-quiv? "Умный сервер" должен уметь выдавать _все_ заголовки.
 Т.е. _костыль_ в виде meta http-equiv _внутри_ html пользоваться не
 должен.

> META - это не больше и не меньше, как способ задать
> такие данные в _HTML документе_.  А еще можно в конфиге Апача.

 Еще раз - я не говорю обо всех META. Я говорю конкретно о meta http-quiv.


> Тут все непонятно. Во-первых, ниоткуда не следует, что способ указывать
> метаданные где-то в конфиге сервера - самый правильный и единственно
> верный.

http://www.w3.org/TR/REC-html40/charset.html#doc-char-set
чуть ниже по тексту

=== cut ===
 To sum up, conforming user agents must observe the following priorities when
determining a document's character encoding
(from highest priority to lowest):

  1.An HTTP "charset" parameter in a "Content-Type" field.
  2.A META declaration with "http-equiv" set to "Content-Type" and a
  value set for "charset".
  3.The charset attribute set on an element that designates an external
  resource.

=== cut ===

Надеюсь не нужно объяснять что означает "from highest priority to lowest"?

> Мы уже выяснили, что и там и там можно задать чарсет более
> одного раза. Или еще как-то ошибиться.

 Значит в отношении ошибки они критерии одного порядка, но в отношении
 стандарта HTML4 - лучше задавать заголовки правильные.

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

 Добавлено. В _работе_.

> Вот я и пытался показать, в чем META может быть правильнее.

 Достаточно узкий случай, который как показал Алекс - решается одним
 скриптом :)

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

 Вот, мне скажется что это должен делать вот тот самый, кто делает upload.
 Видимо когда FrontPage/HomeSite/etc будут в полный рост работать через
 mod_dav, и нужно будет колупать mod_dav на предмет (ок!) более эффективного
 расположения метаданных.

[skip]

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

 Для наиболее вероятных. Лично я такое решение поддерживаю, потоу как
 _других_ условий у меня не возникает.

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

 Дык, я тоже предпочитаю, только вот они поразительно совпали с
 уже имеющимися.

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

 Мне сложно представить ситуацию ".... в пределах одного каталога".
 _Всегда_ можно сделать еще одну ветку (например заменить cover.html
 на cover/index.html), и "задача сводится к предидущей" :)

                Bor.


=============================================================================
=               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                 =