Недавно я позволил себе очень резкий наезд на блоги с некорректными RSS-фидами.

N.B. - срочно научиться не наезжать на людей.

Блог Azzie попал недавно в мое поле зрения, и я решил выяснить, что же такое с ним происходит (автор блога вряд ли виноват в этой ситуации - во всяком случае и фид и страницы закодированы правильно). Естественно, ответ на этот вопрос мне дал фалидатор фидов. Ответ переводится на русский как “проклятие русского Апача” (на него ссылался еще Влад Головач в своей заметке про CityDesk).

Виноваты кривые руки. Уверение для естествоиспытателей – mod_charset и кодировка UTF-8 вместе не живут.

Если вы пользуетесь отечественным хостингом, можете быть уверены, что бы вы там не написали, ваш замечательный хостер как всегда умнее вас, и помимо отключения php_info (чтобы вы всю жизнь, чувствуя себя идиотом, гадали, какие модули есть в вашем PHP а каких нет) шлет перед вашими документами указание, что они в кодировке windows-1251. В документации и хелпе по вашему хостингу об этом как правило нету даже строчки. А на самом деле – чистый саботаж.

Если “продуть” хедеры, получаем предсказуемый результат:

Content-Type: text/html; charset=windows-1251

Несмотря на большое количество статей, утверждающих обратное, я считаю (и всегда считал), что сервируемые документы не то чтобы не могут, а священно обязаны иметь обязательное объявление кодировки (в прологе XML или meta-теге HTML). По одной простой причине – для обработки текстовых данных программа-обработчик обязана иметь явное представление о том, в какой кодировке в нее идут данные. Страничка с сервера на mod_charset при сохранении в файл такой указатель теряет (поскольку он есть только в заголовках сервера), соответственно при открытии этого файла в текстовом редакторе, не настроенном на одну из средневековых кодировок mod_charset по умолчанию (например, моим BBEdit, включенным в UTF-8), не видно ничего кроме квадратиков и сообщения о malformed UTF document.

Резюмируя вышесказанное хочу отметить, что mod_charset и перенастройка DefaultCharset– видимо неплохие вещи. Наверняка кому-то даже нужная (навроде сервера для школьных сайтов, которые пишутся в Нетскейп Компоузере версии 3, а просматриваются - на линуксе, у которого от любой вещи кроме КОИ-8 и Win-1251 наступает немедленный segfault). Ну и самое очевидное - хостеры ставят его не для совместимости страницы с разными кодировками, а просто для того, чтобы секретарша Галя, загрузив кривой HTML из ноутпада, увидела его в браузере по русски и сохранила иллюзию, что жизнь прекрасна. Но для нормальных людей это - помеха.

Посему следует предпринимать радикальные действия и брать контроль над кодировками в свои руки (мой сайт, как хочу так и кодирую в конце концов). На Мастерхосте, где julik live крутился до этого, действия были просты (но на изыск конфигурационных строчек ушло время – оказалось, что как раз заголовок кодировки у них пробит не с помощью mod_charset, а с помощью core-директивы AddDefaultCharset).

Следует создать корневой файл .htaccess (если вы не знаете, как это сделать - вам пора в Google), и в нем прописать следующие магические строки.

AddDefaultCharset Off
<IfModule mod_charset.c>
		CharsetDisable On
        CharsetRecodeMultipartForms Off
</IfModule>

Если вышесказанное не работает (вы все равно получаете кодировку в заголовках), обратитесь в саппорт вашего хостинга (можете даже прислать им линк на эту статью, как указано в “подвале” сайта – я за свои слова отвечаю и таблетки надо пить вовремя).

Проверить, что ваш хостер вытворяет с вашими хедерами можно с помощью Live Headers для Мозиллы.