Вижу вопросы перехода на UTF8 не так просты как, кажутся с первого взгляда.
Так, как же всё-таки безболезненно перевести свой сайт с кодировки 1251 на UTF8?
1. Первым делом любой занимающийся этим должен посмотреть какие Системные переменные MySQL он имеет.
Если они имеют приблизительно такой вид, а такой вид они имеют у большинства российских хостеров, то можно смело двигаться дальше.
2. Перед тем как конвертировать базу надо сделать дамп существующей базы. Лучшим инструментом сделать дамп я считаю Sypex Dumper
Как пользоваться Sypex Dumper? a) Достать файл dumper.php из архива и положить в корень сайта, можно почитать инструкцию readme.txt она тоже в архиве. Имя файла dumper.php не менять, иначе работать не будет! б) Открыть файл dumper.php с помощью текстового редактора Notepad++ если у вас Windows, BBEdit если Mac OS X или встроенным редактором в nix. в) Если мы делаем это на локальной машине localhost параметры оставляем как есть. Если сервер хостера заполняем
Код:
// mysql сервер
define('DBHOST', 'название сервера MySQL : ПОРТ на котором висит сервер');
// Базы данных, если сервер не разрешает просматривать список баз данных,
// и ничего не показывается после авторизации. Перечислите названия через запятую
define('DBNAMES', 'Ваша база');
г)Создаём в корневой папке сайта папку backup и устанавливаем для этого каталога CHMOD 777. д) Запускаем скрипт
Код:
http://www.ваш_сайт.ру/dumper.php
понятное дело что сюда мы вписываем логин и пароль для подсоединения к базе данных MySQL. е) Попадаем сюда
и выбираем БД: которую будем архивировать
Если дело происходит на сервере хостера не забываем установить сжатие но не BZip2(проблемы с ним), а GZip, дабы потом не убивать трафик загружая дамп на ПК.
вот и всё дамп сделан и находится в корне вашего сайта в каталоге backup
Теперь загрузим архив на свой ПКизвлечём из архива .sql файл и откроем его текстовым редактором, который советовал выше и обратим внимание на места обозначенные стрелками. Это места подтверждающие то, что дамп имеет кодовую страницу Windows 1251.
Для перекодировки в UTF8 достаточно просто сохранить этот файл с параметрами в BBEdit
если ваша оп систем Windows то Notepad++ имеет специальную опцию в файловом меню для работы с кодировками и вы должны выбрать там перекодировать Unicode UTF8 без BOM после чего сохранится.
Свидетельство того, что конверт успешен наличие правильных русских символов в дампе кодировка текста у меня показана стрелкой соответствует UTF8.
Важно! Далее по тексту дампа осуществить поиск ctrl+f Windows и nix или cmd+f для Mac Os X и заменить все вхождения CHARSET=cp1251 на CHARSET=utf8, конечно же только в тех местах где это надо!!!
После этого конвертация завершена. Конверт вашей базы .sql надо расположить в папке backup созданную нами ранее в корне сайта. Если это не localhost сожмите ваш.sql файл gzip, чтобы не гонять трафик и положите хостеру в корень сайта в папку backup.
3 Создадим новую базу данных с помощью phpMyAdmin
создаём новую не трогаем старую базу!
Я создал nikiza_utf8
Предлагаю вам файл dumper_local.php, это тот же Damper, но преобразованый мной для работы с кодировкой UTF8 так же там прописаны необходимые параметры. Этот файл надо скинуть в корень сайта и запустить:
Код:
http://www.ваш_сайт.ру/dumper_local.php
Имя файла dumper_local.php не менять, иначе работать не будет! Как видите ничего сверхъестественного всё тоже самое только в UTF8.
Выбираем Восстановление БД из резервной копии. Моя БД: (пустая) nikiza_utf8 выбираю, вы выбирайте свою, что создали. Файл: - тут укажите тот файл, который вы получили при конвертации. Я выбрал свой.
Жмём Применить!
Готово!!!
Проверяем что получилось через phpMyAdmin.
Всё прекрасно парни и девчата, база в UTF8!
4. Теперь, для того чтобы не уничтожить старый сайт создадим новую папку в корневом каталоге. В эту папку перенесём все файлы вашего старого сайта и в config.php пропишем в $cfg['mysqldb'] новую UTF8 базу созданную нами ранее. Теперь нужно используя текстовый редактор один из тех о которых мы говорили выше преобразовать в UTF8 файлы скинов, языковые файлы и только после этого войти на сайт
Так как скины и языковые файлы преобразованы в UTF8 то после входа вы увидите нечто
для того чтобы всё стало на свои места выполняем следующие действия:
изменяем кодировку в браузере на UTF8
теперь видим русский текст переходим Админ панель -> Конфигурация -> Скины, каждый раз переключая в браузере кодировку если вы визуально не знаете где это. Меняем значение HTML кодировка : на UTF8.
Жмите обновить теперь всё более менее приемлемо за исключением нескольких но...
Иногда системные переменные отличны от тех что вверху на рисунке. Например хостер провайдер Agava
у большинства клиентов виртуального хостинга AGAVA кодовая страница 1251 и естественно сервер настроен таким образом, чтобы максимально благоприятствовать таким пользователям. А как же быть вам?
Первым делом надо прописать в файле .htaccess строки
Код:
CharsetDisable On
CharsetDefault utf8
CharsetSourceEnc utf8
AddDefaultCharset utf8
Далее вы можете заметить странную особенность не правильный вывод букв "ш" и "И", для того чтобы это не происходила потребуется открыть файл common.php и сразу после соединения с базой данных прописать строку
while ($row = sed_sql_fetcharray($sql_config))
{
if ($row['config_owner']=='core')
{ $cfg[$row['config_name']] = $row['config_value']; }
else
{ $cfg['plugin'][$row['config_cat']][$row['config_name']] = $row['config_value']; }
}
mb_internal_encoding($cfg['charset']);//motor
Это усовершенствование предложил Асмо при переводе сайта neocrome.ru на UTF8
Ну и последнее в файле functions.php надо заменить функцию усечения строк, для того чтобы в местах где строка усекается, обрезается не образовывались не читаемые символы. Функцию переписал Асмо
Находим в functions.php
Код:
function sed_cutstring($res,$l)
{
global $cfg;
$enc = strtolower($cfg['charset']);
if ($enc=='utf-8')
попробовал, безболезненно перевести не получилось
для себя сделал вывод, лучше это делать в начале разработки сайта.
проблема походу была в том, что сайт работал в кодировке windows-1251, а база была в utf-8, в итоге он в кое каком виде записывал данные в таблицы, и при включении на сайте utf-8 все отображалось нормально, кроме всего что на русском грузилось из базы, а это все новости, и в том числе слоты меню и т.д., все буквы ромбиками.
в итоге откат и снова windows-1251
If you want to change the table default character set and all character columns (CHAR, VARCHAR, TEXT) to a new character set, use a statement like this: ALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name; For a column that has a data type of VARCHAR or one of the TEXT types, CONVERT TO CHARACTER SET will change the data type as necessary to ensure that the new column is long enough to store as many characters as the original column. For example, a TEXT column has two length bytes, which store the byte-length of values in the column, up to a maximum of 65,535. For a latin1 TEXT column, each character requires a single byte, so the column can store up to 65,535 characters. If the column is converted to utf8, each character might require up to 3 bytes, for a maximum possible length of 3 × 65,535 = 196,605 bytes. That length will not fit in a TEXT column's length bytes, so MySQL will convert the data type to MEDIUMTEXT, which is the smallest string type for which the length bytes can record a value of 196,605. Similarly, a VARCHAR column might be converted to MEDIUMTEXT.
Как вы понимаете, ручное конвертирование файла с базой не подразумевает автоматическую замену, например, VARCHAR на MEDIUMTEXT. Вследствие чего текстовые данные вполне могут обрезаться.
Залил на хост 125RC4 оттестить все пашит кроме руссификатора скинутого со 121 седа, как положено поменял все на русский в конфиге в профиле выставил ру.Как с этим бороться?
я так понял сам руссификатор продолжает работать ни на UTF-8 а на 1251 где надо поменять чтобы все нормально отображалось
Все просто оказалась теже самые файлы надо было сохранить в блокноте в кодировке UTF-8, вот руссификатор только с кодировкой UTF-8 кому понадобится 426-utf-8-localization-ru.zip
Я сам ещё не пробовал 125RC4. Предполагаю, надо посмотреть, если тексты отображаются корректно и не вылазят разнообразные закарючки, то править не обязательно.
Вроде поюзал проблем пока не было, думаю править не обязательно хотя хз время покажет но предварительно выше указанных проблем на 125RC4 в статье не всплыло