Апгрейд с 4.1 до 4.5

[Андрей Аксенов]

Зачем все эти трудности?
На всякий случай делайте резервную копию БД.
Ставите расширение sfdbutf8, пи помощи его конвертируйте БД в utf8.
Далее, в самой БД ставим кодировку по умолчанию в utf8_general_ci.
На всякий случай делаем проверку БД в install tool, заодно подгружаем заново все статические таблицы.
Все. Это проверено ни на одном сайте. Работает.

[-=UncleByte=-]

@Андрей, дело в том что конвертировать можно и средствами самого mysql прямо в том же phpMyAdmin, но надо хотя бы представлять что там на самом деле лежит, а то бывали случаи когда записи хранились в utf-8 вроде бы, но были в cp1251.

[Андрей Аксенов]

Сообщение от -=UncleByte=-

@Андрей, дело в том что конвертировать можно и средствами самого mysql прямо в том же phpMyAdmin, но надо хотя бы представлять что там на самом деле лежит, а то бывали случаи когда записи хранились в utf-8 вроде бы, но были в cp1251.

Это понятно, способов много... Для этого и нужно сначала создать резервную копию базы данных. Для меня проще всего так.
Хотя можно установить и на TYPO3 phpMyAdmin и глянуть, что там...
Установить в нем же нужное сопоставление для всей базы данных - utf8_general_ci, оно понадобиться и для вновь создаваемых таблиц и т. д.
Затем переконвертить поля/таблицы в неправильной кодировке...
Кстати, сталкивался с тем, что иногда связанные поля не могут быть сконвертированы поодиночке - нужно выделить оба связанных поля и одновременно их сконвертировать... тут и упомянутое мной расширение sfdbutf8 не помогает - все ручками...
Ну и обязательно, как уже говорил, проверку БД в install tool, заодно подгружаем заново все статические таблицы.
Тут уже недостающие таблицы пересоздаются самой TYPO3 в уже нужной кодировке... Что касается статических таблиц, то они тоже пересоздаются в нужной кодировке, бывали случаи, когда при регистрации в форме, при выборе страны (на родном языке) появлялись кракозябры... Пересоздание статических таблиц (статик инфо тейбл в данном случае) помогло...
Далее все зависит от конкретного случая... Возможно придется вмешаться и ручками подкорректировать записи содержимого в базе данных. Но это уже другая история...

[-=UncleByte=-]

@Андрей, в том и дело что там половина таблиц в cp1251 и половина в utf8 - неважно чем делать дамп, в нем все будет ровно так же и для решения этого вопроса нужно либо дамп делить на куски и конвертировать кусками, либо руками в текстовом редакторе, который позволяет менять на лету кодировку в части файла.

[Андрей Аксенов]

Ну дамп - в любом случае текстовый файл... А уж чем с ним работать...
Проще отметить таблицы с кодировкой в cp1251 и еще раз отдельно их выгрузить, а уж в том же нотапде++ кодировку поменять нет проблем... Ну и загрузить их обратно...
Кстати, может в том же Sypex Dumper можно на лету это сделать? Я не пробовал, но как вариант...
Хотя у меня недавно с одним сайтом схожая проблема была... Увидел это по тому, как даже непичатный пробел не распознавался. Ну так вот, описанным мною способом все решилось без танцев с бубном...

[dmartynenko]

Кстати еще один нюанс при апгрейде с TYPO3 4.1 - в этой версии и более ранних поля config/setup TS шаблонов (и возможно еще какие-то) были BLOB. А в более позних уже TEXT. В результате при экпорте в .sql BLOB поля выводились как BASE64-encoded строки, кодировка в них соответственно не изменялась при перекодировании дампа в utf8, а при импорте в utf8 таблицу в ней если попадался русский символ или что-то отличное от латиницы - все что шло дальше после такого символа просто отрезалось. Так что важно проверить что бы BLOB поля экспортировались как простой текст.