[3.8.x]

Если у кого-то еще остались форумы в 1251, то для их конвертации в utf-8 можно использовать эту методику.
Инструкции составлены на основе практического опыта конвертации нескольких форумов из cp1251 в UTF8: смена кодировки проходила полностью прозрачно для пользователей и занимала минимальное время (сохранение/восстановление дампа + несколько вспомогательных операций).
Кроме того, описанная методика полностью исключает необходимость использования tools.php, а также любых операций перестроения чего-либо после смены кодировки. Танцы с бубнами также не предусмотрены.
Это было достаточно давно, поэтому какие-то нюансы мог не вспомнить, но все основное было запротоколировано.

Примечание 1: Весь процесс сначала нужно отладить на копии сайта.
Примечание 2: Здесь не рассматриваются общие вопросы типа "нужно или не нужно конвертировать в UTF8".

Этап 1. Предварительный

Описанные на этом этапе действия рекомендуется выполнить до начала каких-либо действий по конвертации.

1) Если в исходные php-файлы форума и/или зависимых от форума продуктов вручную вносились модификации, то исследуем их на предмет наличия русских фраз прямо в программном коде. Если такие фразы обнаружены, то нужно занести их в переменные фраз vbulletin (Админка -> Языки и фразы -> Управление фразами -> Добавить новую фразу), а в программном коде заменить их использование на $vbphrase['my_var'], где my_var - название переменной.

2) Если у вас используются метки тем, то нужно провести анализ меток, содержащих букву "ё". Если есть схожие метки, различающиеся только в "е" и "ё", то их нужно объединить (Админка -> Темы и сообщения -> Метки).
Если этого не сделать, то при конвертации возникнут проблемы (см. ниже): в UTF8 буквы "е" и "ё" считаются одинаковыми, поэтому при импорте конвертированного дампа базы данных возникнет ошибка с уникальными ключами в таблице tags.

3) Аналогично меткам необходимо провести анализ пользователей с буквой "ё". Например, если у вас есть пользователи "Алёша" и "Алеша", то первый после конвертации в UTF8 не сможет зайти на сайт. Лечение - переименовать ник.

Этап 2. Подготовительный

1) Подготовить измененный файл .htaccess для корня сайта, в котором находятся строчки

AddDefaultCharset utf-8
DefaultLanguage ru

2) Подготовить измененный файл /forum/includes/config.php, в котором:
- прописано: $config['Mysqli']['charset'] = 'utf8';
- отключено кэширование, если оно используется (см. секцию // ****** DATASTORE CACHE CONFIGURATION *****)

3) Подготовить файл /forum/includes/class_bbcode.php, в котором
- Заменить строчку:

PHP Code:

$text = htmlspecialchars_uni(vbchop($tmp, 36) . '...' . substr($tmp, -14)); 


на

PHP Code:

$text = htmlspecialchars_uni(vbchop($tmp, 36) . '...' . mb_substr($tmp, mb_strlen($tmp, 'UTF-8')-14), 14, 'UTF-8'); 


Это необходимо для корректного отображения ссылок в текстах сообщений после конвертации.

4) Отключить на время конвертации любые сторонние системы кэширования контента (например, в виде дополнительно установленных продуктов).

Этап 3. Основной

1) Закрыть форум для пользователей (Админка -> Основные настройки -> Включение и отключение форума).

2) В командной строке сервера или из панели хостинг-провайдера (если есть) сделать дамп базы данных vbulletin.
Пример команды:

mysqldump my_database --user=username --password=my_password > my_dump.sql

С помощью mysqldump дамп по умолчанию создается в кодировке UTF8. Если дамп создает хостинг-провайдер, то необходимо этот вопрос предварительно уточнить.

3) Сделать в дампе замены строк:
"DEFAULT CHARSET=cp1251" => "DEFAULT CHARSET=utf8"
"CHARACTER SET cp1251 COLLATE cp1251_bin" => "CHARACTER SET utf8 COLLATE utf8_bin"

Проще всего это сделать с помощью perl-скрипта (где, my_dump.sql - имя файла дампа)
Windows:

perl.exe -p -i.bak -e "s/DEFAULT CHARSET=cp1251/DEFAULT CHARSET=utf8/g" my_dump.sql
perl.exe -p -i.bak -e "s/CHARACTER SET cp1251 COLLATE cp1251_bin/CHARACTER SET utf8 COLLATE utf8_bin/g" my_dump.sql

*nix:

perl -p -i.bak -e 's/DEFAULT CHARSET=cp1251/DEFAULT CHARSET=utf8/g' my_dump.sql
perl -p -i.bak -e 's/CHARACTER SET cp1251 COLLATE cp1251_bin/CHARACTER SET utf8 COLLATE utf8_bin/g' my_dump.sql

4) Импортировать скорректированный дамп обратно в базу данных.
Примечание: перед импортом дампа, убедитесь что у вас настроен UTF8 на SQL-сервер. Инструкции - здесь.
Пример команды:

mysql -u username -p database < my_dump.sql

Примечание: если при импорте возникает ошибка с таблицей tags, то в ней есть одинаковые метки с "е" и с "ё", например "елка" и "ёлка", смотрите выше этап 1.

После восстановления из дампа можно открыть базу данных в phpmyadmin и убедиться, что у таблиц изменена кодировка на UTF8.

5) Прописать в приложенный файл ut8.php параметры доступа к своей базе данных форума (не перепутать !) и префикс таблиц VB (если используется), затем скопировать файл, например, в корень сайта и запустить, вот так: http://мой-сайт/utf8.php.
Скрипт проверяет и правильным образом конвертирует все сериализованные данные в базе данных, что полностью исключает необходимость каких-либо манипуляций с tools.php а также любых других танцев с бубнами.
Пример конвертации сериализованных данных при переходе на UTF-8:
a:2:{i:0;s:4:"ДЕНЬ";i:1;s:4:"НОЧЬ";} => a:2:{i:0;s:8:"ДЕНЬ";i:1;s:8:"НОЧЬ";}

В скрипте уже заложена обработка сериализованных данных для следующих продуктов:
- vbulletin 3
- vBulletin Blog
- vBadvanced CMPS
- PhotoPost vBGallery
- PhotoPlog Pro
Любые другие продукты можно добавить в этот скрипт, просто визуально определив в phpmyadmin, где они хранят сериализованные данные (в каких таблицах и в каких столбцах).
Примечание: как выглядят сериализованные данные и что это вообще такое, можно прочитать, например, по ссылке http://webgyry.info/chto-takoe-seria...-dannyih-v-php

Кроме того, скрипт ut8.php финально правит таблицу language (в этой таблице находятся фразы) и общие свойства самой базы.
После окончания работы скрипта рядом будет создан файл log.txt, который нужно пройтись поиском строчки "!!! error" и изучить ошибки, если они были.

6) Скопировать на сайт подготовленные на первом этапе файлы .htaccess, config.php и class_bbcode.php

7) Открыть форум для пользователей (Админка -> Основные настройки -> Включение и отключение форума).
В этот момент уже все уже в UTF-8 и все должно работать.

Этап 4. Финальные штрихи

1) Если на предварительном этапе вы отключили кэширование в файле config.php или в других продуктах, то можно его включить снова.

2) Сделать исправление от @Luvilla для безумно длинных слов (http://vbsupport.ru/forum/showthread.php?t=35275)

3) В vbadvanced:
- в настройках модуля "Последние сообщения в форуме" убрать ограничение на длину темы и на размер слова.
- в настройках модуля "Новости" увеличить в 2-3 раза количество отображаемых символов.

Оффтоп

Originally Posted by eska

Если у кого-то еще остались форумы в 1251

А что, ср1251 уже не комильфо?)

Originally Posted by Dyuhaha

ср1251 уже не комильфо?

и уже давно =)
причин перехода с вин на утф много, но самая основная, на мой взгляд, то, что в новых версиях пхп все строчные данные обрабатываются как утф по умолчанию
а вот для вин1251, нужны костыли =)

Originally Posted by kerk

и уже давно =)

Ок, спасибо, не задумывался никогда над этим) Т.е., имеет смысл перекодировка? Или, не так уж принципиально?

одно из первых правил кодера: работает - не трогай!

Такой вопрос:
vb3.8.4
кодировка форума cp1251
кодировка базы latin_swedish

Хочу всё в utf8 перевести, с чего начать?

с дампа
потом приведение таблиц и строковых полей в таблицах к нормальной кодировке
дамп на локалке сконвертировать проще текстовыми редакторами
и в этих же редакторах заменить вин на утф при (это понадобится при импортировании дампа)

Скопировал БД вес 15мб.
Открыл редактором и массово заменил кодировку latin1 на utf8

Вопросы:
1. Правильное написание кодировки в дампе - utf8 или utf-8 или utf8_general_ci ???
2. Это все манипуляции с дампом?
3. Следующий шаг?

в моем дампе изначально утф

CREATE TABLE IF NOT EXISTS `access` (
  `userid` int(10) unsigned NOT NULL default '0',
  `forumid` smallint(5) unsigned NOT NULL default '0',
  `accessmask` smallint(5) unsigned NOT NULL default '0',
  PRIMARY KEY  (`userid`,`forumid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

==
след. шаг: убедиться, что сам файл дампа в утф кодировке (без сигнатуры BOM) и все русские символы читаемы (см. таблицу post)
импорт в чистую базу с выставленной кодировкой для нее utf_general_ci

Originally Posted by eska

Подготовить измененный файл .htaccess для корня сайта

Хм, такое ощущение, что для многих понятие веб-сервер это исключительно Apache. Мне кажется следует учитывать, что на сегодня уже многие не используют Apache.

Может кому пригодится:

Совет о том, как избавиться от крякозябров в дампе, ибо сама конвертация нормального дампа из cp-1251 в UTF-8 не является сложной задачей. Актуально для небольших форумов.

У меня однажды так же был форум в cp-1251. MySQL был с дефолтными настройками то есть latin1_swedish. На форуме все отображалось норм, но если глянуть в PMA - крякозябры. Такая проблема бывает у юзверей частенько. Я себе поставил две задачи
1. Избавится от крякозябров в дампе
2. Перегнать в UTF-8

Для решения первой задачи я решил использовать встроенный дампер воблы (Обслуживание->Резервное копирование базы данных). После чего нормальный дамп без крякозябров конвертнул в UTF-8.
В итоге потребовалось 5 минут времени и использование только самой воблы и Notepad++