26 февраля 2007 в 14:10
Добрый день всем!
Сделал локально на 5.1 сайт, перенес на хост (скопировал файлы и восстановил базу из дампа) и после этого списки категорий и контент (статьи) совсем не читабельны. Пункты меню и все остальное нормально (поставил русский язык локально, до переноса на хост).
В чем может быть причина?
Кодировка страницы Юникод.
Комментарии
Попробуйте в .htaccess на хосте добавить строку "charsetdisable on" .
Попробовал - в самый конец файла, находящегося в поддиректории на хосте. После этого вообще все упало. Загрузил .htaccess который был локально у друпала - помогло. Контент так и остался нечитабельным. Кодировки у баз одинаковые.
Что характерно, пункты меню отображаются корректно, а вот статьи - коряво.
В чем еще может быть причина?
Или может я куда то не в то место
charsetenabled on
вставлял?
У меня была точно такая ситуация: меню в cp1251, а содержание статей - в utf-8. Помогло добавление директивы "charsetdisable on" (у вас, кстати, написано "charsetenabled"!) в корневой .htaccess.
Еще рекомендуют иногда "AddDefaultCharset UTF-8", но мне не понадобилось.
Еще вариант. В dumper.php есть опция принудительной перекодировки базы данных при ее загрузке в базу:
// Кодировка соединения с MySQL при восстановлении
// На случай переноса со старых версий MySQL (до 4.1), у которых не указана кодировка таблиц в дампе
// При добавлении 'forced->', к примеру 'forced->cp1251', кодировка таблиц при восстановлении будет принудительно заменена на cp1251
// Можно также указывать сравнение нужное к примеру 'cp1251_ukrainian_ci' или 'forced->cp1251_ukrainian_ci'
define('RESTORE_CHARSET', 'cp1251');
Попробуйте указать define('RESTORE_CHARSET', 'cp1251'); или define('RESTORE_CHARSET', 'utf-8');
Вот это спасибо большое за подробную инфу. Вечерком попробую, что получится - обязательно тут отпишусь.
Кодировка в MySQL у провайдера?
utf8_general_ci - это у базы. Как у меня, локально, так и на хосте. Скрипт для создания и разворачивания скрипта dumper.php - достаточно популярная и известная штука.
А можно я тоже сюда со своим вопросом добавлюсь? тоже похожая проблема. у меня был несколько дней назад сделан бэкап БД, сегодня после некоторых дурацких манипуляций в БД пришлось ее стереть и импортировать этот самый бэкап. на тот же самый сервер, все осталось по-прежнему... только кириллица теперь отображается козявками!! почему так?! это что-то в файле .sql, экспортированном из старой БД, что ли? (экспорт шел через phpmyadmin, импортирую через mysqldumper, т.к. файл слишком большой, через phpmyadmin не пролезает).
Спасибо большое, если чем поможете, а то я просто в ужасе :(((
Да, это "слишком гибкой" работы MySQL с кодировками. "Ну ужас, да. Но не ужас!-ужас!" (с) анекдот про Швацнеггера в публичном доме.
Раз бекап есть - ничего особо страшного нет.
Попробуйте первый и третий советы (по раздельности, конечно) из моего сообщения выше.
именно то, что не ужас-ужас, меня и утешало!
в итоге от полного отчаяния проблема решилась по методу блондинки: путем ручной вставки кусков экспортированного файла БД (причем сохраненного в ANSI) в новую БД через phpmyadmin. то есть, очевидно, все-таки существует какая-то несовместимость экспортированного через phpmyadmin файла и mysqldump. а что в будущем делать? ведь БД растет и ширится, не копировать же ее вручную при каждой необходимости?
Для создания и загрузки бэкапа я пользуюсь sitekeeper dumper. Вроде работает без траблов.
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.
Он же dumper.php с http://sypex.net/. Действительно, очень удобный скрипт.
utf8_general_ci - это у базы. Как у меня, локально, так и на хосте.
в MySQL в версиях после 4.2 (по-моему, точно не помню) важна не только кодировка базы данных, но и то в какой кодировке выдаются и принимаются данные от скрипта...
http://www.linux.by/wiki/index.php/FAQ_PHP_MySQL_charset
Скрипт очень удобный, спасибо B.X. за наводку.
Но по умолчанию в нем стоит кодировка работы с БД - cp1251, имейте это в виду.
Для работы с базами в других кодировках нужно поправить скрипт "руками", поставив в настройках (в начале скрипта) нужную кодировку.
Разработчики обещали новую версию, в которой будет "автосмена" кодировки, может, уже есть.
Скрипт - имеется ввиду dumoer.php?
Действительно удобный. Я юзаю бородатую версию. Год назад (примерно) нашел его, и так он у меня и есть. А в целом, способы решения проблемы понял. Просто пока времени небыло...
В версии 1.0.8 входная (при дампе) кодировка определяется автоматически, а выходную (востановление дампа) надо ставить ручками в настройках.
Всем спасибо. Решение проблемы заняло 5 минут.
Что сделал:
- скачал свежий dumper.php (был 1.0.6 стал 1.0.8)
- поменял в нем:
define('RESTORE_CHARSET', 'utf8_general_ci');
- по новой сделал бэкап базы этим скриптом, залил бэкап и скрипт на хост - отресторил, и все красиво
Благодарю за подмогу