Offtop. HTTP header vs Meta tag. Источники кракозябр.
alekciy
public-mail at alekciy.ru
Fri Mar 13 16:13:55 MSK 2009
Немного поофтоплю, но сейчас у меня
возник довольно жаркий спор, а
авторитетного судьи который мог бы его
рассудить нет. Вопрос касается
протоколов, веб серверов и браузеров.
Избитая тема о кракозябрах.
Когда то я написал у себя короткую
заметочку http://alekciy.ru/articles/what_priority/index.php и
именно из за ней разгорелся спор.
Рассматриваем статический файл, хотя по
сути это не важно. Позиции две. Моя:
1) В ФС сервера храниться HTML файл в
кодировке указанной в META, например <meta
http-equiv="Content-Type" content="text/html; charset=utf-8" />
(рассматриваю случай нормального ПО или
разработчика у которых данные в meta
совпадают в реальной кодировкой в ФС).
Браузер посредством Accept-Charset заголовка
говорит веб серверу в какой кодировке он
готов принять данные. Браузер сам ни
когда не перекодирует данные, а просто
производит переключение кодовых
страниц. В ходе получения страницы имеем
два случая, реальный и идеальны.
а) идеальный вариант. Клиент шлет
Accept-Charset, веб сервер смотрит (7.4.4 Meta data, META
and HTTP headers в HTML 4.01 спеце) метаинформацию
файла (на проблеме корректного чтения
файла из ФС не заостряемся) находит <meta
http-equiv="Content-Type" ... /> и заменяет свой HTTP
заголовок указанным (в контексте апача
это AddDefaultCharset директива, в nginx charset)
производя перекодирование файла и
отдавая его уже в требуемой клиенту
кодировке (директивы модуля mod_charset_lite в
Apache и ngx_http_charset_module в nginx).
б) на практике, поскольку в спеце сказано
что данные из meta http-equiv могут быть
использованны, то ни один веб сервер
реально meta http-equiv из файла не читает и
автоматического перекодирования (т.е.
без явного прописывания директив в
конфиге) не делает (оно и понятно, лишняя
нагрузка). Отсюда и получаем кракозябры
при рассогласовании данных в HTTP header, meta
http-equiv и отсутствии перекодирования.
Т.е. вкратце имеем туже ситуацию как и при
соединении с MySQL сервером. Есть кодировка
таблицы, есть кодировка соединения и
между собой они в принципе не связаны.
Браузер же как клиентская сторона
полученные данные ни когда не
перекодирует, а просто в зависимости от
обстоятельств делает переключение
применяемых кодовых страниц.
2) Написано было много, процитирую один
кусок наиболее показательный: "У меня
есть кодировка файла (в которой я пишу) и
браузер ОБЯЗАН предоставить мне в той
кодировке, в которой мне нужно (мета) и
разхлёбывать проблемы с заголовками
сам!".
Т.е. человек считает, что Content-Type с
указанной кодировкой в HTTP заголовке это
не более, чем дефолтное значение, а
браузер должен смотреть значение в meta
http-equiv и уже сам перекодировать на
стороне клиента если это нужно.
Процитирую кусок переписки:
alekciy (16:54:50 13/03/2009)
>чтобы браузер понял в какой кодировке
ЕМУ отдают, а не в какой ОТОБРАЖАТЬ
т.е. ты согласен с тем, что в нттр
заголовке указывается кодировка
соединения? Т.е. в какой кодировке пришли
данные? А браузер должен исходя из этого
и данных в meta http-equiv перекодировать из HTTP
кодировки в meta http-equiv и уже в этой
кодировке показывать? Так?
... (16:55:25 13/03/2009)
да
alekciy (16:55:30 13/03/2009)
ок, принято. а Accept-Charset нужен для того, что
бы указать, какие же типы кодировок в
соединении готов поддержать клиент, так?
... (16:57:28 13/03/2009)
да, вернее какие он понимает
Я конечно понимаю, что это может быть
очень сильно отходит от формата
рассылки, но проблема с кракозябрами и
непониманием принципов работы веб
сервера с кодировками по мне довольно
актуальная. Может я и сам где-то что-то не
так понимаю, хотелось бы знать и
разобраться в этом раз и навсегда. И
мнение Игоря тут было бы крайне
авторитетным и весомым.
В общем прошу высказаться всех, кому
данная проблематика близка.
More information about the nginx-ru
mailing list