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

Кое что нарыл по Typo3 3.8 и по конвертации cp1251->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:
Если у вас 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);
} - сами понимаете почему.

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

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

<?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 или что это?

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

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

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

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

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

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

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

Распаковал архивы, создал БД, перед тем как ставить в локалконф вставил:
$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

Вложение 38

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

Вложение 39

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

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