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

[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

[Pavel Antonov]

Причину полностью уловить не могу... Бросилось в глаза неверно определение setDBinit...

Заменить:

 $TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;';
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET character_set_connection = utf8;';

На:

 $TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8; SET character_set_connection = utf8;';

А то работает только одна комманда.

[Andrey Grey]

сильно извиняюсь.... не подскажеье для чего character_set_connection?
использую теже параметры, но без character_set_connection.
в результате при просмотре базы ячерез phpmyadmin, данные хранятся в читаемом виде (подключаюсь к phpmyadmin как к utf).... но есть ряд глбюков.
1. mailform. скрипты с битой кодировкой. фронтненд в utf-8.

2. В темпла воила при просмотре шаблона всегда ошибки с кодировкой. ((... это не сильно напрягает, в конечном виде всегда все нормально (при условии, что файл шаблона сохранен в utf-8, но всеравно неприятно.)