После того как на хостинге возникла проблема (не запускалась виртуальная машина вследствие сбоя на серваке), посовещавшись с техподдержкой решили поступить следующим образом: они завели новую виртуальную машину (поставили туда CentOS, было Fedora8), и туда подмонтировали файловую систему от старой. Я настроил все заново, скопировал данные и файлы с базами, все вроде завелось нормально, кроме одного - почему-то в некоторых блоках, слетела кодировка.
Например, формируемый через views блок live со ссылками на ноды с последними комментариями стал выглядеть так:
(и заголовка блока тоже нет)
В то время как например формируемый через views блок newblog со ссылками на новые ноды выглядит нормально:
Небольшое разбирательство показало, что в файле template.php
-------------
-------------
почему то выводит данные в кодировке win-1251, а
-------------
-------------
как и надо, в utf-8
Куда дальше копать? Что-то у меня даже мыслей нет...
Комментарии
1-е проверьте посты в базе и кодировку базы, как они там отображаются. Может кодировка при переносе слетела смотря чем дампились.
2-е проверяете кодировку файлов движка.
если не помогает теребите хостера.
glu2006, база не дампилась, я просто файлы с данными от прежней базы скопировал на новое место и все, т.е. все что было - таким и осталось (включая файл my.cnf).
Файлы движка тоже один к одному были скопированы.
Сайт www.funsochi.ru, можете взглянуть, в правой колонке.
mysql + русский язык = подарочный набор граблей для наступания. (
я бы постарался убедиться, что база всеже в utf8. и еще такое дурацкое предположение, в phpinfo() в разделе Environment посмотреть, что определено для LANG. и убедился бы что модуль mbstring включен.
v1adimir, вот содержимое
phpinfo() в разделе Environment:
Variable Value
TERM xterm
PATH /sbin:/usr/sbin:/bin:/usr/bin
PWD /
LANG C
SHLVL 2
_ /usr/sbin/httpd
Mbstring действительно нету, сейчас подключу.
iconv
iconv support enabled
iconv implementation glibc
iconv library version 2.5
Directive Local Value Master Value
iconv.input_encoding ISO-8859-1 ISO-8859-1
iconv.internal_encoding ISO-8859-1 ISO-8859-1
iconv.output_encoding UTF-8 UTF-8
mbstring
Multibyte Support enabled
Multibyte string engine libmbfl
Multibyte (japanese) regex support enabled
Multibyte regex (oniguruma) version 3.7.1
mbstring extension makes use of "streamable kanji code filter and converter", which is distributed under the GNU Lesser General Public License version 2.1.
Directive Local Value Master Value
mbstring.detect_order no value no value
mbstring.encoding_translation Off Off
mbstring.func_overload 0 0
mbstring.http_input pass pass
mbstring.http_output pass pass
mbstring.internal_encoding ISO-8859-1 no value
mbstring.language neutral neutral
mbstring.strict_detection Off Off
mbstring.substitute_character no value no value
phpmyadmin показывает такую инфу:
...
...
...
webform_component 7 MyISAM utf8_general_ci 3.7 КБ -
webform_roles 2 MyISAM utf8_general_ci 2.0 КБ -
webform_submissions 7 MyISAM utf8_general_ci 3.8 КБ 456 Байт
xmlsitemap_additional 0 MyISAM utf8_general_ci 1.0 КБ -
xmlsitemap_node 1,012 MyISAM utf8_general_ci 44.7 КБ 29 Байт
xmlsitemap_term 251 MyISAM utf8_general_ci 10.1 КБ -
zipcodes 0 MyISAM utf8_general_ci 1.0 КБ -
233 таблиц(ы) Всего 552,376 MyISAM utf8_general_ci 77.1 МБ 12.4 МБ
Я так понимаю, что таблицы в UTF-8 (да и на сайте все работает, за исключением 2 блоков - с последними комментариями, и "популярное за сегодня").
то что collation для таблицы указан utf8_general_ci нифига на означает, что сами данные хранятся в UTF8. но как я понял, это ссылки на комменты и, в другом месте они показываеются нормально?
тогда есть похабное предложение, устраивать на лету конвертацию cp1251 -> utf8, в template.php.
кеш пробовали сбрасывать?
Проверьте посты в таблице, зайдите в пхпмайадмин и посмотрите содержимое таблиц, есть там кракозяблы или нету?
конечно.
там все нормально (да и на всем сайте кроме 2-3 блоков ТЕ ЖЕ данные нормально отображаются).
Да, в другом месте они отображаются нормально.
придется так сделать на первое время, хотя конечно неправильно.
Так... поменял порядок блоков, поставил глючный повыше - он стал отображаться нормально.
Уже теплее... сейчас еще поэкспериментирую.
Вобщем, такая фигня происходит после блока который выводит последние темы из форума PHPBB