Кодировка Apache Content-Type меняется с UTF-8 на iso-88591 из каталога в каталог

У меня есть сайт, работающий на Apache 2.2.8 (Plesk 9.5.4)

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

http://globalmit.com/
Заголовки ответа
Дата Ср, 04 мая 2011 00:57:26 GMT
Сервер Apache
Дата последнего изменения: понедельник, 04 апреля 2011 г. 21:09:05 GMT
Этаг "15013bf-5a7-4a01e2b6efe40"
Accept-Ranges байты
Cache-Control max-age=300
Истекает ср, 04 мая 2011 года 01:02:26 мск
Vary Accept-Encoding
Контент-кодировка gzip
Контент-длина 564
Content-Type text/html; кодировка =UTF-8

Затем я установил osTickets в этот каталог, и я сделал перевод на испанский язык, и для его работы необходимо установить кодировку типа контента в UTF-8, и это прекрасно работает.

http: // globalmit.com/ tickets /
Заголовки ответа
Дата Ср, 04 мая 2011 01:04:37 GMT
Сервер Apache
Истекает четверг, 19 ноября 1981 г. 08:52:00 по Гринвичу
Cache-Control без хранения, без кэширования, обязательная повторная проверка, пост-проверка =0, предварительная проверка = 0
Прагма без кеша
Vary Accept-Encoding
Контент-кодирование gzip
Keep-Alive timeout = 15, max = 100
Keep-Alive соединения
Передача-кодирование
Content-Type text/html; кодировка =UTF-8

Здесь возникает проблема для этого каталога, админ-панели osTickets, Apache меняет кодировку на iso-8859-1 без причины.

Я попытался добавить AddDefaultCharset UTF-8 в файл конфигурации виртуального каталога Apache, добавив файл.htaccess с тем же AddDefaultCharset UTF-8, но мне не повезло.

http://globalmit.com/tickets/scp/
Заголовки ответа
Дата Ср, 04 мая 2011 01:05:26 GMT
Сервер Apache
Истекает четверг, 19 ноября 1981 г. 08:52:00 по Гринвичу
Cache-Control без хранения, без кэширования, обязательная повторная проверка, пост-проверка =0, предварительная проверка = 0
Прагма без кеша
Vary Accept-Encoding
Контент-кодировка gzip
Keep-Alive timeout = 15, max = 100
Keep-Alive соединения
Передача-кодирование
Content-Type text/html; кодировка = изо-8859-1

Как я могу избежать этого странного поведения Apache?

1 ответ

Решение

Апач ведет себя правильно; PHP нет.

К сожалению, поскольку все строковые данные генерируются из PHP, вы в значительной степени зависите от приложения, в котором вы работаете, с хорошей поддержкой набора символов - посмотрите, есть ли какие-либо настройки, которые вы можете изменить в приложении, чтобы включить UTF Поддержка -8.

Другие вопросы по тегам