Re: [apache-talk] meta charset problems

["Khimenko Victor" <khim@xxxxxxxxxxxx>]

In <001001befc12$77a4c310$0100007f@localhost> Serge Shikov (shikov@xxxxxxxx) wrote:
SS> ----- Original Message -----
SS> From: Vladimir Bormotov <bor@xxxxxxxxxxxxxx>
SS> Subject: Re: [apache-talk] meta charset problems


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

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

Это -- костыль. Он В МАССЕ случаев менее удобен, чем Apache'вский. Для того,
чтобы суметь извлечь какую бы то ни было информацию из HTML-документа мы УЖЕ
должны знать информацию о кодировке (зачем? ну например затем, чтобы найти в
файле teg'и, ибо вовсе не во всех кодировках символы "<meta http-equiv"
задаются байтами 3C 6D 65 74 61 20 68 74 74 70 2D 65 71 75 69 76 и не везде
эти байты обозначают "<meta http-equiv" -- вспомните хотя бы про EBCDIC), а
если вы УЖЕ имеете эту информацию, то зачем она еще раз внутри документа.

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

Этот способ требует ЗНАЧИТЕЛЬНО меньше теледвижений от сервера (BTW AFAIK
IIS тоже не получает этой информации из тега "META"). Он не требует разбора
документа и применим к документам любого типа (а не только к .html в
нескольких наиболее распространенных кодировках). Так как данные о типе
документа не могут в нем храниться в любом случае и должны храниться где-то
еще, то хранение части информации о типе документа вне его, а части внутри
выглядит черезвычайно неестественно.

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

Для начала определите понятие "правильность". То что имеющийся способ удобнее,
более общ, требует менее сложного сервера и РЕАЛИЗОВАН -- очевидно. А вот
правильнее ли он... Это вопрос. BTW вы можете привести пример хотя бы одного
сервера, который бы использовал этот способ ? Тогда можно было бы говорить
конкретнее...

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

Даже если ты его не отдаешь наружу, то он замедляет сервер и уже хотя бы
поэтому вреден.

SS> Никто этого не предлагает, можешь перечитать еще раз и убедиться.

Но никто пока не предложил способа этого избежать :-) Как говорит в таких
случаях Linus "where is your code". На чем дискуссию предлагаю закончить...

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

Опять же -- что значит полезен или вреден. Для меня вреден == порождает
больше проблем, чем решает. Так как web-cервер должен уметь определять
кодировку НЕ ТОЛЬКО этим способом, то он неизбежно усложняет работу
web-сервера. Переносимость информации между web-серверами я вижу как
единственную проблему, которая решается, но это -- чистая теория, так как
пока что я не встречал даже одного сервера, который бы этот способ
использовал, а говорить о переносимости можно при наличии хотя бы двух...

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

Как быть с заменой документа "под ногами" у web-сервера ? А если мы на сервер
(машину, а не web-сервер) документы помещаем только с помощью
специализированной процедуры, то почему все необходимое не сделать в ней и
не перенести информацию в .htaccess ?

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

Есть разница. .htaccess МОЖНО распарсить ибо его кодировка известна. А вот
.HTML распарсить (не имея информации о его кодировке) нельзя :-))

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

Если кодировка указана вне документа, то она может быть только одна :-)

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

Только одна вещь: сервер не может его из документа извлечь. Мелочь, но зато
рушащая все остальные построения :-))

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

Пожалуйста -- пишите свой сервер. И нефиг использовать Apache. А еще
лучше -- написать свою OS. Только при чем тут тогда apache-talk вообще ?

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

А причем тут сервер, извините ? Есть еще и третий способ о котором вы не
упомянули: эту информацию можно включить в название документа.

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

А если что-то делается не сервером, а где-то как-то кем-то "сбоку", то причем
тут сервер вообще ?



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