Перейти к контенту
  • 0

Конвертер базы на PHP для русской IP.Board 3


Ritsuka

Вопрос

На данный момент в инструкции очень много сложного понаписано про экспорт базы, конвертирование через iconv и обратный импорт... Но почему бы не задействовать PHP и MySQL, они же прекрасно умеют конвертировать базы сами!

 

Вот примерный скрипт:

 <?php
// Database info

include("conf_global.php");

$dbhost = $INFO['sql_host'];
$dbuser = $INFO['sql_user'];
$dbpass = $INFO['sql_pass'];
$dbname = $INFO['sql_database'];

//---------------

header('Content-type: text/plain');

$dbconn = mysql_connect($dbhost, $dbuser, $dbpass) or die( mysql_error() );
$db = mysql_select_db($dbname) or die( mysql_error() );

$sql = "ALTER DATABASE `".$dbname."` DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci";
$result = mysql_query($sql) or die( mysql_error() );
print "Database changed to UTF-8.\n";

$sql = 'SHOW TABLES';
$result = mysql_query($sql) or die( mysql_error() );

while ( $row = mysql_fetch_row($result) )
{
$table = mysql_real_escape_string($row[0]);
$sql = "ALTER TABLE $table DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci, CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci";
mysql_query($sql) or die( mysql_error() );
print "$table changed to UTF-8.\n";
}

mysql_close($dbconn);
?>

 

Что думают об этом специалисты ibresource?

 

Только что успешно сконвертировал этим скриптом свой немалый форум, заняло порядка 20 сек... Для крупных форумов конечно имеет смысл сделать потабличное конвертирование через ajax...

Изменено пользователем Ritsuka
  • Лайк 1
Ссылка на комментарий
Поделиться на других сайтах

  • Ответы 103
  • Создана
  • Последний ответ

Лучшие авторы в этом вопросе

Лучшие авторы в этом вопросе

Загружено фотографий

Рекомендуемые сообщения

  • 0
Кстати никогда не понимал, почему нет простого запроса, которым можно было бы сконвертировать всю базу в одну кодировку. Вот блин обязательно нужно колупаться, каждую таблицу, каждое поле отдельно.. Изменено пользователем WildRAID
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Ан нет, не все так просто после отработки этого скрипта, проверил: phpMyAdmin показывает кодировку полей utf8, но реально кодировка данных не изменилась. Заметил это, играясь с настройками кодировки в админке.
Ссылка на комментарий
Поделиться на других сайтах

  • 0

FarStar, то что вы говорите в принципе невозможно. Если бы кодировка поменялась только в описании таблиц, а данные остались бы прежними, форум бы просто не запустился, ибо mysql по всем запросам начал бы выдавать шлак.

 

To change the character set (and collation) for all columns in an existing table, use...

ALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name [COLLATE collation_name];

 

Кстати никогда не понимал, почему нет простого запроса, которым можно было бы сконвертировать всю базу в одну кодировку. Вот блин обязательно нужно колупаться, каждую таблицу, каждое поле отдельно..

WildRAID, как показывает практика, скорее всего такой запрос есть, но лежит где-нибудь в уголке документации и не известен широким массам)) Запрос для конвертирования таблицы нашелся же.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
В настройках форума (Settings: Server Environment) стоит кодировка windows-1251, поэтому информация из базы отображается корректно. Если поставить рекомендованное UTF-8, то получается крякозябры. Из phpMyAdmin тоже крякозябры при просмотре страницы в UTF-8, следовательно данные остались в старой кодировке.
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Из phpMyAdmin тоже крякозябры при просмотре страницы в UTF-8, следовательно данные остались в старой кодировке.

У вас хостинг или VDS?

Если VDS, смотрите my.cnf секцию [mysqld]

 

default-character-set=

default-collation=

init-connect=

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Хостинг, к тому же американский. Там изначально кодировка latin1 на таблицах была. Вообщем выгрузил базу supex dumper, пересохранил дамп в UTF8 редактором Winsyntax. Создал новую базу со сравнением utf8_general_ci и дампером загрузил все. В phpMyAdmin отображаются список форумов, посты нормально по-русски в кодировке UTF8.

Только что снова поставил (upgrade, точнее) 3-ку (английскую), в результате вместо русских символов получаем знаки вопроса. :D

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Только что снова поставил (upgrade, точнее) 3-ку (английскую), в результате вместо русских символов получаем знаки вопроса.

Как видим, мой скрипт конвертера тут не при чем, так что советую еще раз внимательно прочитать инструкцию по обновлению (особенно где про conf_global.php и про .htaccess), и если не поможет - открыть отдельную тему с вашим вопросом.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Хостинг, к тому же американский.

Странно. Обычно глюки происходит на русских настройках хостинга.

 

Там изначально кодировка latin1 на таблицах была. Вообщем выгрузил базу supex dumper, пересохранил дамп в UTF8 редактором Winsyntax.

Советую скрипт от Ritsuka. Я пока делаю тестовые прогоны, готовлюсь к переезду, и уже заметил, что им пользоваться удобнее, чем другими способами.

 

Только что снова поставил (upgrade, точнее) 3-ку (английскую), в результате вместо русских символов получаем знаки вопроса. :D

Не вы первый, не вы последний. ;) Я уже заметил, что конвертация сильно зависит от настроек хостинга. Хоть устанавливай локально все и делай конвертацию.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Напоминаю снова - приведенный скрипт полностью конвертирует базу данных в utf-8. Откройте таблицы через phpMyAdmin до и после конвертирования и убедитесь в этом. Все остальное - уже вопросы для других тем, не для этой.
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Только что снова поставил (upgrade, точнее) 3-ку (английскую), в результате вместо русских символов получаем знаки вопроса.

Как видим, мой скрипт конвертера тут не при чем, так что советую еще раз внимательно прочитать инструкцию по обновлению (особенно где про conf_global.php и про .htaccess), и если не поможет - открыть отдельную тему с вашим вопросом.

Скрипт нипричем конечно. Выше ведь написал, что данные не конвертнулись в UTF-8. У меня, по крайней мере. А ручками все конвертнулось нормально.

----------------

Поборол знаки вопроса!!! Надо в conf_global.php добавить:

$INFO['sql_charset'] = 'UTF8';

 

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

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Поборол знаки вопроса!!! Надо в conf_global.php добавить:

$INFO['sql_charset'] = 'UTF8';

Да вы что? Правда что-ли? Это вы сами придумали? Вы наверное очень умный человек.

 

Вы проверили и убедились, что "данные не конвертнулись", всего лишь потыкав настройки кодировки в админцентре форума. И phpMyAdmin вам соврал, и скрипт соврал, и mysql врет, вы это точно это знаете. Ведь в админцентре форума, в котором в conf_global.php выставлена иная кодировка, чем UTF-8, в админке вы потыкали в настройки кодировки и лично убедились, что "данные не конвертнулись". Воистину, страна не оскудеет...

Изменено пользователем Ritsuka
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Поборол знаки вопроса!!! Надо в conf_global.php добавить:

$INFO['sql_charset'] = 'UTF8';

Да вы что? Правда что-ли? Это вы сами придумали? Вы наверное очень умный человек.

Конечно не сам, нашел здесь, в этом форуме. :D

 

Вы проверили и убедились, что "данные не конвертнулись", всего лишь потыкав настройки кодировки в админцентре форума. И phpMyAdmin вам соврал, и скрипт соврал, и mysql врет, вы это точно это знаете. Ведь в админцентре форума, в котором в conf_global.php выставлена иная кодировка, чем UTF-8, в админке вы потыкали в настройки кодировки и лично убедились, что "данные не конвертнулись". Воистину, страна не оскудеет...

Я привык доверять своим глазам. Если страница phpMyAdmin русская (язык оформления), открытая браузером в кодировке UTF8 и текстовые данные в таблице отображаются крякозябрами, то следоватедьно, они не в UTF8.

У себя, кстати смотрели?

------------------------------------------

Кажется я нашел причину, по которой разработчики IPB не советуют использовать подобные скрипты, и они предпочли другой путь к конвертации:

Такой подход может привести к изменению типов данных и их усечение по-тихому, что делает такой вариант неприемлемым для наших целей.

Читать: тут на русском , а тут на английском .

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Ваша цитата ведет на один сайт - sysadminonline.ru. IPB - это разработка sysadminonline.ru? Или может быть это разработка mysqlperformanceblog.com?

 

а) я специально выложил скрипт и спросил, что о нем думают разработчики, читайте первый пост;

б) разработчики IPB еще ни слова не сказали об этом скрипте.

 

Хватит уже врать.

 

У себя, кстати смотрели?

У меня, кстати, уже месяц как тройка, начиная с RC, и вот теперь 3.0.1 RUS. И сконвертирована она именно этим скриптом. Может быть это чем-то и черевато, но пока все работает, и разработчики IPB никаких замечаний в этой теме не оставляли.

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Скрипт конвертации нормально работает.

 

сконвертировал базу с 400000 сообщений.

 

глюки могут быть, если в браузере жестко задана кодировка, я такое словил на Опере

или если в конфиге апача стоит defaultcharasterset не UTF8

 

если такое есть, то в инструкции по обновлению написано, что необходимо прописать в htaccess

 

Ваша цитата ведет на один сайт - sysadminonline.ru. IPB - это разработка sysadminonline.ru? Или может быть это разработка mysqlperformanceblog.com?

 

а) я специально выложил скрипт и спросил, что о нем думают разработчики, читайте первый пост;

б) разработчики IPB еще ни слова не сказали об этом скрипте.

 

Хватит уже врать.

 

У себя, кстати смотрели?

У меня, кстати, уже месяц как тройка, начиная с RC, и вот теперь 3.0.1 RUS. И сконвертирована она именно этим скриптом. Может быть это чем-то и черевато, но пока все работает, и разработчики IPB никаких замечаний в этой теме не оставляли.

 

тем не менее они опубликовали ссылку на Ваш конвертер на вики в статье по обновлению форума до версии 3.0.1

Изменено пользователем olmer2002
Ссылка на комментарий
Поделиться на других сайтах

  • 0

Давайте заглянем в БД:

post-75890-1249905984_thumb.png

 

1) критические поля изначально имеют формат LONGTEXT.

2) поля типа TEXT и правда переводятся в MEDIUMTEXT. Знаете почему? Потому что unicode - это два байта на символ против одного, и чтобы не потерять данные, размер текстового поля увеличивается дважды.

3) а вот и документация mysql - http://dev.mysql.com/doc/refman/5.1/en/sto...uirements.html:

BLOB, TEXT				L + 2 bytes, where L <  2^16
MEDIUMBLOB, MEDIUMTEXT 	L + 3 bytes, where L < 2^24
LONGBLOB, LONGTEXT 		L + 4 bytes, where L < 2^32

Интересно мне, если MEDIUMTEXT в два раза больше TEXT, то какого "усечения по-тихому" так боятся на sysadminonline.ru? Ну если они идиоты, это же не значит что глупости нужно за нимим повторять? Или вы пытаетесь накопать что-нибудь на этот скрипт, чтобы морально реабилитироваться? =)

 

А теперь скажите мне, что корректнее - сконвертировать ДАННЫЕ в utf-8 в дампе, не увеличив размер поля в два раза и таким образом теоретически потеряв текст в полях длиной больше > 2^16 + 2 байта, или сконвертировать нормально, штатными средствами MySQL?

 

Да, я утверждаю, что изложенный в инструкции к конвертации на ibresource метод экспортом и конвертированием дампа базы НЕКОРРЕКТЕН. Он ведет к потере данных длинных записей. А мой метод - не ведет.

 

Итак, теперь ваш ответ, сударь.

Изменено пользователем Ritsuka
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Да, я утверждаю, что изложенный в инструкции к конвертации на ibresource метод экспортом и конвертированием дампа базы НЕКОРРЕКТЕН. Он ведет к потере данных длинных записей. А мой метод - не ведет.

 

Итак, теперь ваш ответ, сударь.

Ваш метод уже включён в официальную инструкцию. :D

 

А ваше заявление о некорректности весьма интересно. Я тут уже которые сутки бьюсь с переносом форума.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Да, я утверждаю, что изложенный в инструкции к конвертации на ibresource метод экспортом и конвертированием дампа базы НЕКОРРЕКТЕН.

 

Наверное нам не попадались длинные такие длииииинные записи, как у вас, но у всех кого обновляли таких проблем не было, что мы делаем не так?

 

А ваше заявление о некорректности весьма интересно. Я тут уже которые сутки бьюсь с переносом форума.

У вас проблема не в длинных записях, какие может и есть, но не составляют 80% всех тем форума. Проблема похожая вашей была у одного из бета-тестеров форума, нормальное конвертирование и обновление решило проблему.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Давайте заглянем в БД:

У меня, кстати, поле post имеет тип mediumtext.

 

Да, я утверждаю, что изложенный в инструкции к конвертации на ibresource метод экспортом и конвертированием дампа базы НЕКОРРЕКТЕН. Он ведет к потере данных длинных записей. А мой метод - не ведет.

 

Итак, теперь ваш ответ, сударь.

Ну работает и хорошо что работает, зачем так нервничать? :D Все способы конвертации хороши, если позволяют добиться конечной цели. Почему мне не повезло и данные не подверглись конвертации, я не знаю. Но это не суть важно, когда отработаю все модули и буду переносить рабочую базу, то попробую еще раз ваш скрипт и если он отработает нормально, то не поленюсь и напишу спасибо еще раз ;) .

Ссылка на комментарий
Поделиться на других сайтах

  • 0
У вас проблема не в длинных записях, какие может и есть, но не составляют 80% всех тем форума. Проблема похожая вашей была у одного из бета-тестеров форума, нормальное конвертирование и обновление решило проблему.

:D

 

1. Удалил полностью все записи из БД

2. Удалил всё с ФТП, кроме указанных директорий

3. Поднял backup БД

4. Теперь пытаюсь конвертировать в utf-8 данным вариантом. Будете смеяться - и он не работает. Глохнет на posts (582 Мб) - предыдущие уже все в utf-8.

Ссылка на комментарий
Поделиться на других сайтах

  • 0

max_execution_time надо поднять

 

Либо в шелле в mysql выполнить ALTER TABLE ibf_posts DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci, CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci

 

Префикс свой вместо ibf_

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Да, я утверждаю, что изложенный в инструкции к конвертации на ibresource метод экспортом и конвертированием дампа базы НЕКОРРЕКТЕН.

Наверное нам не попадались длинные такие длииииинные записи, как у вас, но у всех кого обновляли таких проблем не было, что мы делаем не так?

Возьмем первую же таблицу:

CREATE TABLE admin_login_logs (
 admin_id int(10) NOT NULL auto_increment,
 admin_ip_address varchar(16) NOT NULL default '0.0.0.0',
 admin_username varchar(40) NOT NULL default '',
 admin_time int(10) unsigned NOT NULL default '0',
 admin_success int(1) unsigned NOT NULL default '0',
 admin_post_details text,
 PRIMARY KEY  (admin_id),
 KEY admin_ip_address (admin_ip_address),
 KEY admin_time (admin_time)
);

Как видим, admin_post_details - имеет тип text и теоретически может обрезаться. Вот только представить себе admin_post_details длиной 2^16 байт довольно трудно))) То же и для всех остальных таблиц (просмотрел сегодня). Таким образом, это не критично и 99,99% вероятности что ничто никогда не обрежется. Но вероятнаость такая есть и багу можно воспроизвести искусственно.

 

А т.к. во всех критичных полях используется longtext, то если что и потеряется - то это будет не самая важна инфа.

 

max_execution_time надо поднять

Где меняется этот параметр?

В php.ini

Ссылка на комментарий
Поделиться на других сайтах

  • 0

ZiDaNe, у меня была такая же ошибка как у вас при обновлении на RC1! Перед конвертацией нужно было очистить кэш и поставить форум в оффлайн.

 

Fatal error: Uncaught exception 'Exception' with message 'Не удалось инициализировать регистр, кеш настроек либо пуст, либо испорчен' in /var/www/vhosts/spbfootball.ru/httpdocs/admin/sources/base/ipsRegistry.php:1630 Stack trace: #0 /var/www/vhosts/spbfootball.ru/httpdocs/admin/sources/base/ipsRegistry.php(498): ipsRegistry->setUpSettings() #1 /var/www/vhosts/spbfootball.ru/httpdocs/admin/sources/base/ipsController.php(75): ipsRegistry::init() #2 /var/www/vhosts/spbfootball.ru/httpdocs/admin/sources/base/ipsController.php(62): ipsController->init() #3 /var/www/vhosts/spbfootball.ru/httpdocs/index.php(24): ipsController::run() #4 {main} thrown in /var/www/vhosts/spbfootball.ru/httpdocs/admin/sources/base/ipsRegistry.php on line 1630

 

На forums.invisionpower.com была где-то строка, которую нужно вставить в таблицу кэша, чтобы форум запустился с этой ошибкой. Сейчас поищу.

 

 

Нашел. Вот решение вашей проблемы:

 

1) Откройте через phpMyAdmin таблицу cache_store, найдите поле "settings" и вставьте туда строку:

a:2:{s:10:"mail_queue";i:0;s:13:"task_next_run";s:10:"1246017960";}

2) все запустится, сразу пройдите в Admin CP > System Tab > Cache Management. Recache Cache... settings row.

 

Мне помогло тогда. Источник вот - http://forums.invisionpower.com/topic/2863...p;#entry1815418

Ссылка на комментарий
Поделиться на других сайтах

  • 0
а как нужно пользоваться этим конвертором? чтобы переконвертировать базу IPB 2.3.6 в UTF8 или можно обновиться с IPB 2.3.6 CP1251 на 3.0 UTF и исправить базу этим конвертором? разъясните пожалуйста :D
Ссылка на комментарий
Поделиться на других сайтах

  • 0

Скрипт сохраняешь в файл, например convert.php и закачиваешь его на сервер в корневую папку форума. Потом запускаешь из адресной строки браузера, например так: www.forum.ru/convert.php. Предварительно надо сделать бэкап БД.

----------

Ritsuka, попробовал еще раз и опять у меня скрипт на сервере так и не конвертнул данные. Т.е. преобразование полей (сравнение) он сделал, но данные остались в старой кодировке. Не знаю с чем это связано, пришлось ручками через редактор делать.

Ссылка на комментарий
Поделиться на других сайтах

Присоединиться к обсуждению

Вы можете ответить сейчас, а зарегистрироваться позже. Если у вас уже есть аккаунт, войдите, чтобы ответить от своего имени.

Гость
Ответить на вопрос...

×   Вы вставили отформатированный текст.   Удалить форматирование

  Допустимо не более 75 смайлов.

×   Ваша ссылка была автоматически заменена на медиа-контент.   Отображать как ссылку

×   Ваши публикации восстановлены.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

Зарузка...

×
×
  • Создать...

Важная информация

Находясь на нашем сайте, вы соглашаетесь на использование файлов cookie, а также с нашим положением о конфиденциальности Политика конфиденциальности и пользовательским соглашением Условия использования.