Правильная настройка базы MySQL 4.1 и TYPO3 4.0

[Valery Romanchev]

В BE - будет один и тот же charset
(в базу все будет идти в utf8, юзер у которого руссий язык - будет в BE работать в windows 1251 - с этим подробно разбирался Павел Антонов - он вроде даже патч делал на эту тему... чтобы все-таки все было в utf8)
А для вывода в FE - для разных деревьев можно проставить разные кодировки - на лету идет конвертация

Вот только если для FE стоит windows-1251, то index search записывает кракозябры (т.е. в index search ошибка). И возможно это не единственная проблема... Так что используйте utf8

[Дылгеров Ц.В.]

Пишу тут то что может пригодится для новичков - так что не обессудьте.

mysql должен 4.1 и выше - старые версии mysql utf хранят иначе, точно не могу объяснить как, но в новых версиях мускла поиск будет работать правильно.

Дамп из latin1 (те есть со старого сайта на cp-1251) должен быть читабельным в виндовой кодировке.
Затем применяем команду iconv или можно применить php-скрипт указанный выше. Проверяем в hex-виде - в русских символах первый байт чаще всего D0. Значит это UTF-8. Для окончательного успокоения открываем файл в Ultra-Edit. Или меняя кодировку в клиенте ssh смотрим дамп командой cat VASH_DAMP | more.

Сервер уже должен быть в кодировке UTF8 - в my.cnf
[mysqld]
default_character_set = utf8

Импорт надо делать, предварительно меняя character set client = utf8. Как это делается?
Можно внедрить в начало полученного конвертированием дампа строку: "SET NAMES utf8;", а проще войти в каталог где лежит дамп и:
mysql -p -u rooot
set names utf8;
use VASHA_BASA;
source VASH_DUMP;
Зачем нужна команда set names utf8. Наверное тут говорилось, но я повторюсь - чтобы клиент mysql говорил серверу mysql что данные в кодировке utf8. По умолчанию у клиента стоит latin1. То есть если не поменять кодировку, то сервер будет думать что все данные в latin1 и русские слова будут заново конвертироваться и будут вдвое большего размера и выглядеть крако-кракозябрами.

(кстати вот тут я подумал - может тогда не конвертировать дамп - а предоставить эту возможность mysql? то есть не конвертировать дамп и обновременно не делать команду set names utf8?)

В Typo3 3.8 в /t3lib/class.t3lib_db.php в функции sql_pconnect нет куска кода ответственного за выполнение команд в переменной $GLOBALS['TYPO3_CONF_VARS']['SYS']['setDBinit']). Вот этот код из Typo3 4.0:

if (!$this->link) {
t3lib_div::sysLog('Could not connect to Mysql server '.$TYPO3_db_host.' with user '.$TYPO3_db_username.'.','Core',4);
} else {
$setDBinit = t3lib_div::trimExplode(chr(10), $GLOBALS['TYPO3_CONF_VARS']['SYS']['setDBinit']);
foreach ($setDBinit as $v) {
if (mysql_query($v, $this->link) === FALSE) {
t3lib_div::sysLog('Could not initialize DB connection with query "'.$v.'".','Core',3);
}
}
}

Если у вас Typo3 3.8 - ставьте этот код иначе все что сказано в этом треде не будет работать.

я же применил другой хак, взятый здесь http://bugs.typo3.org/view.php?id=1262 (спасибо за ссылку Валерию):

if ($TYPO3_CONF_VARS["BE"]["forceCharset"]=='utf-8') {
mysql_query("SET NAMES utf8",$this->link);
mysql_query("SET CHARACTER_SET utf8",$this->link);
}

, но условие не срабатывало, а сработало

if ($GLOBALS['TYPO3_CONF_VARS']["BE"]["forceCharset"]=='utf-8') {
mysql_query("SET NAMES utf8",$this->link);
mysql_query("SET CHARACTER SET utf8",$this->link);
} - сами понимаете почему.

[Guinness]

а если это свежая установка "с нуля", где дампа нет, то что делать?

[Дылгеров Ц.В.]

Сообщение от Guinness

а если это свежая установка "с нуля", где дампа нет, то что делать?

да забыл - хорошая сцылка http://wiki.typo3.org/index.php/UFT-8_support

[Batonoff]

<?php

$handle = fopen("olddump.sql","r");
$newhandle = fopen("olddump.sql.utf-8","w");
$contents = '';
while (!feof($handle)) {
$contents .= fread($handle, 8192);
$contents = iconv("WINDOWS-1251","UTF-8",$contents);
// $contents = convert_cyr_string(); - здесь кажется нет utf-8
// $contents = mb_convert_encoding($contents,"UTF-8","WINDOWS-1251");
fwrite($newhandle,$contents);
}
fclose($handle);
fclose($newhandle);

?>

Есть дамп базы в кодировке cp1251. После конвертации скриптом указанным выше, получается файл неприлично большого размера. Из 10 мегабайт получается более 300, дальше мой апач вешается...

Вопрос: размер должен стать таким, это особенность ютф8 или что это?

[jax]

Если я не ошибаюсь, то вас ошбка в коде:

$contents .= fread($handle, 8192);

а логичнее:

$contents = fread($handle, 8192);

Т.е. на очередном шаге цикла вы взятые из файла 8 кБайт добавляете к значение хранящемуся в $contents, а затем пишиете все это в выходной файл.

А в общем, даже если предположить, что в дампе все символы из кириллицы (кодируемые в utf8 по 2 байта на символ) то файл не должен быть польше 20 мег. А ввиду того, что в дампе, как правило, достаточно много символов из latin1 (кодируемых 1-м байтом) то размер должен быть мег 16-18 при начальных 10.

[filippoff]

применительно к indexed search: должен ли в utf-8 при условии правильной настройки работать морфологический поиск?
у меня, к примеру, только прямые совпадения ищет..

[Valery Romanchev]

Сообщение от filippoff

применительно к indexed search: должен ли в utf-8 при условии правильной настройки работать морфологический поиск?
у меня, к примеру, только прямые совпадения ищет..

поиска по словоформам для русского языка в TYPO3 нет.
Насколько сложно его сделать - я не копал, наверное сложно.
Впрочем, никто из серьезных заказчиков (я имею ввиду ITспециалистов из 2х крупных контор, которые занимаются системной интерацией и входят в top10 в России) на этом не настаивал... все понимают, что поиск на сайте - это не яндекс.

Варианты типа MnogoSearch сложны в настройке и обслуживании (если только MnogoSearch уже не стоит у данного провайдера).
Да и выигрыш от их использования будет не большой... люди как правило ишут простые слова, фамилии.. т.е. слоформы не так уж важны.

[Quester]

При перкодировании столкнулся с проблемой - каждый первый символ новой строки не конвертируется. То есть, вначале идет два символа в latin1, а остальная строка в utf8. Пользуюсь iconv под винды от GTK+.
Кстати, в результате конвертирования пропали страницы. Видны в DB Check, видно, что у каждой первый символ неправильно, но в списке страниц их вообще не видно.

[Sly]

Значит так...

Распаковал архивы, создал БД, перед тем как ставить в локалконф вставил:
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;';
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET character_set_connection = utf8;';

Далее установка. Установил форс чарсет то утф8...

В BE все работает на utf8. Замечательно. Создаю страницу называю ее например "главная". Иду в phpmyadmin. Смотрим:
MySQL charset: UTF-8 Unicode (utf8)
MySQL connection collation: utf8_general_ci

Collation в BD действительно получился utf8_general_ci

utf8.jpg

Но когда я просматриваю ту же таблицу pages вижу что title надпись "главная" превратилась черт знает во что.

utf8_2.jpg

Как же так. Что же сделать. Полезно иметь дамп на случай переезда или восстановления...

P.S. TYPO3 уже даже 4.1 поставил. Данные сервера:
Apache Version 1.3.37 (Unix)
PHP Version 4.4.4
MySQL Version 4.1.21-standard