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

За несколько часов поисков и экспериментов узнал много интересного на тему collation в MySQL
:-)

http://drupal.htdogs.ru/node/111
http://bugs.typo3.org/view.php?id=1262

Рецепт того как добиться регистронезависимого поиска и сортировки с русскими буквами, когда в TYPO3 forcecharset utf-8 и MySQL 4.1

базу создаем в utf-8 ( collation utf8_general_ci при этом дефолтовая кодировка сервера может быть любая - у меня latin)

Пишем в localconf.php
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8'.chr(10).'SET CHARACTER SET utf8';

Кстати, Битрикс не поддерживает utf-8 и это не планируется.

доп инф.
http://bugs.typo3.org/view.php?id=3547

последний вариант который я пробую
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;';

см. http://dev.mysql.com/doc/refman/5.0/...onnection.html

поставить
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET character_set_connection = utf8;';
недостаточно - в этом случае на update через раз слетает кодировка

итак, стоит
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;';
и пока полет нормальный

спасибо за информацию.

Если кому-то поможет...

Чтобы корректно работал ORDER BY и поиск по LIKE в UTF-8 я сделал так:

1) удалил все таблицы в БД typo и создал их заново. Важно, чтобы таблицы создавались в DEFAULT CHARSET=utf8;

PhpMyAdmin генерит скрипт на создание таблицы с latin1 вместо utf8, поэтому надо заменить. А если создавать базу через инсталлятор typo3, то умолчательный collation там стоит latin1_swedish_ci. Так что, похоже, без ручной модификации не обойтись.

2) поставил в localconf.php строку SET NAMES (см. выше)

3) со старого сайта сделал экспорт в .T3D и на новом сделал импорт из .T3D - все заработало

Возможно ли в одной БД (дереве) иметь два сайта - первый на windows-1251, второй на utf-8?

При том необходимо чтобы charset соблюдался и в BE - редактировать то сайт нужно в той же кодировке? То есть переключение BE charset-а должно происходить в зависимости от того в какой ветке?

Нет, так сделать не получится. Ведь все страницы, не зависимо от ветки где они находятся, хранятся в одной таблице бд, кодирвка которой может быть или utf8 или win1251.

да, но при этом не будет нормально работать Index Search
Как это делать описано в доке по локализации.
Frontend Localization Guide
(свежая дока кстати)
http://typo3.org/documentation/docum...guide/current/


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

Переношу БД в utf-8.
БД конвертируется хорошо. Так как default character set установлен в UTF-8, то при импорте дампа таблицы создаются с charset utf-8 и collation utf_general_ci. Сам дамп конвертирую такой программой

Проблема такая - в таблице pages поле title имеет тип tinytext, то есть 256 символов. При конвертации если текст в поле title превышает некоторое значение (так и непонял какое - 128??) - выходит ошибка:
C:\Program Files\MySQL\MySQL Server 5.0\bin>mysql -p -u root mynewdbinutf8 < olddump.sql.utf-8
Enter password: ****************************************
ERROR 1406 (22001) at line 1: Data too long for column 'title' at row 1

вызвано это тем что при конвертации из windows-1251 в utf-8 title длиной 163 превратился в 307 - а это уже больше чем tinytext

Что посоветуете? Или я что то неправильно делал?

Может в команде mysql -p -u root mynewdbinutf8 < olddump.sql.utf-8 добавить default-charset=windows-1251 и не конвертировать дамп?

я конвертировал из windows-1251 в uft8 с помощью экстеншена. Их там 2, использовал тот, который Андрей Шварцкопф делал.

Вот только если для 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

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

Заменить:
На:
А то работает только одна комманда.

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

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

У меня работает вот это (MySQL 4.1.x, кодировка по умолчанию latin):
$TYPO3_CONF_VARS["BE"]["forceCharset"] = 'utf-8';
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;';

1. mailform. скрипты с битой кодировкой. фронтненд в utf-8.
-> это javascript-сообщения?

Да, теже настройки...
Но кодировка базы по умолчанию utf
Угу, это решил установкой патча.

Но вот с темплой все как то странно.
такое чувство что она сама в win1251 кодирует... в базе все гуд.
попробовал дать название поля в темплавоила на русском и в результате в бекэнде кракозябры как при неправильной вин1251

Скажите пожалуйста, а следуюшая ошибка при работе с typo3 относится к теме настройки кодировок?

Warning: xml_parser_set_option() [function.xml-parser-set-option]: Unsupported target encoding "windows-1251" in D:\Server\Apache Group\Apache2\htdocs\quick\t3lib\class.t3lib_div.p hp on line 2139

Текст ошибки сгенерировала РНР-функция, так как поддерживает она только ISO-8859-1, US-ASCII и UTF-8. Об этом сказано в офф. документации, да и в исходнике, кстати, тоже :) А Вы по всей видимость установили windows-1251.
Выхода наверное два: установить поддерживаемую кодировку (если для русского, то это наверняка будет UTF-8) или предварить вызов ф-ции символом @

Спаисибо за помощь!
Использовал вот это
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;';
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET character_set_connection = utf8;';
и всё заработало)))

Ах да...
$TYPO3_CONF_VARS["BE"]["forceCharset"] = 'utf-8';
также установил)))

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

Простите запутал вас.
как раз вот это я и поставил
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8; SET character_set_connection = utf8;';
$TYPO3_CONF_VARS["BE"]["forceCharset"] = 'utf-8';

А установка знчения utf-8 только для переменной forceCharset не спасал положения

Вчера экспериментировал с переносом, восстанавливал то что узнал во время поисков полгода назад. И вот что понял:

Оказывается можно получить видимость нормальной работы в Typo3, а БД будет в два раза больше, то есть в БД будут храниться utf8 байты, закодированные еще раз в utf8 побайтно.

Чтобы проверить правильность и избежать этого, надо посмотреть в phpmyadmin русские буквы - в utf8 должны отображаться правильно. Естественно надо настроить phpmyadmin на просмотр utf8.

Неправильная настройка Typo3 может получиться следующим образом (объясняю как у меня получилось):
- беру дамп со старого сайта в win1251 c DROP-ами
- конвертирую в utf8 командой iconv
- настраиваю сервер в my.cnf на utf8
[mysqld]
default_character_set=utf8
- импортирую дамп
mysql -p -u root
>set names utf8;
>source mydump
в результате я получаю BD двойного размера
В http://forum.typo3.biz/showpost.php?p=6276&postcount=12 я это описал, при просмотре в phpmyadmin неправильные символы счел за верное так как mysql был 3.23, и поэтому ошибочно решил что все правильно

- после того как я получил БД двойного размера со спокойной душой ставлю:
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8; SET CHARACTER SET utf8; SET SESSION character_set_server=utf8;';
$TYPO3_CONF_VARS["BE"]["forceCharset"] = 'utf-8';
и все работает отлично! Однако это неверно! Нужно только SET NAMES utf8

---------------------------------------------------------------

поэтому считаю верным следующее

- беру дамп со старого сайта в win1251 c DROP-ами
- конвертирую в utf8 командой iconv
- настраиваю сервер в my.cnf на utf8
[mysqld]
default_character_set=utf8
- импортирую дамп
mysql -p -u root
не использую -----> это неверно: >set names utf8;
>source mydump
в результате я получаю BD нормальную при просмотре в phpmyadmin

в localconf.php:
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;'
$TYPO3_CONF_VARS["BE"]["forceCharset"] = 'utf-8';
здесь не нужно SET CHARACTER SET utf8; SET SESSION character_set_server=utf8;

To Podlec - на всяк случай проверь в phpmyadmin русские буквы нормально выглядят? Хотя с вариантом SET NAMES utf8; SET character_set_connection = utf8; не эксперимнтировал.

не в коем случае не советую пользоваться iconv
Я столкнулся с тем, что она режет символы типа многоточий (была конвертация сайта из ISO в utf-8)

для конвертации нужно пользоваться скриптом dumper http://sypex.net/
и выствалять его настройки в коде скрипта

Спасибо за ссылку
 

работает хорошо - пригодилось

Единственное - неправильно переносил спецсимволы, а именно кавычки-скобочками, из koi8r в win1251

Подозреваю что дело не в транскодоре, а в отсутствии символов в целевых кодировках.

Помогите с проблемой с utf-8, уже отчаялся...
сайт переезжал на другой хост, где стоит пшп5, apache2.0 myscl 4.1, версия typo3 - 4,04. исходная кодировка сp-1251

Перечитав ветки где упоминаетса даная проблема сделал следующее.
Перед переносом базы поставил в mysql кодировку по умолчанию UTF-8.
в типо 3 прописал
SET NAMES utf8;
SET character_set_connection = utf8;
базу перекодировал, 3 упоминающимися способами (и пшп скриптом и экстеншеном...)
вобщем результат все равно один, одни знаки вопроса!!!
phpmyadmin показывает что вся база даных действительно в utf..

[forceCharset] = utf-8
это надо сделать... потом.. сталкивался с такими проблемами... когда переносил базу, которая до этого была в утф8... решал так: перед тем как импортировать БД создаешь чистую базу данных в утф8... т.е. не потом назнаешь созданной БД кодировку.. а сразу.. чтобы она создавалась с дефолтовой Utf8.
Потом импорт БД делал непостредственно при устновке тайпы....
Всё работало...

проблемы c Ш
 

при некоторых настройках MySQL помогает похоже только вот такая конфигурация:
спасибо JavaPro

Важно помнить что при создании нового проекта, "SET NAMES utf8" должна быть установлена до создания таблиц! Если пользуетесь 1-2-3 режимом инсталлятора, таблицы придется пересоздавать. Остальные установки "SET" обычно не требуются.

Изначально таблицы создавались dumper-ом (force->utf8), но я не мог понять где проблемы. Потом с настройками выше заработало сначала с чистой установкой, а потом и с бекапной базой . Перекодированной из cp1251. Осталось TV поправить.
...
ну вот (смайлик - утирает пот) переход на utf-8 и ПХП5 занял всего сутки :)

Павел, можно немного внимания?
/я очень люблю знать и всегда интересуюсь как (с) Стругацкие /
Подробно про базу:
сначала просто восстановил инсталяцию (4.0), поставил форсеЧарсет и восстановил дампером базу. Как писал выше - везде где видно - утф_генерал_ци. С третьей или четвертой попытки добился того, что в пхпМайАдмин чистый УТФ без потерь контента. В бекенде - бред. (вопросики, то в черных ромбиках,то без). СЕТ НЕЙМС пробовал. Без эффекта.
Сделал чистый инстал (все таблицы при каждой попытке убивались, а не только чистились).
СЕТ НЕЙМС не ставил. Получил на таблицах коллейшн - 1251. Убил. Восстановил базу дампером. Все коллейшн правильные. Обнулил таблицы. Восстанновил чисто содержимое через инстал тул. Получил проблемы с "Ш". Поставил приведенный выше блок кода в ДБ Инит. Получил все старые данные - 1251 отображенные в юникоде. Зато при вводе новых все проблемы исчезли. Восстановил базу. Полет нормальный.
Где ошибся по дороге? Какие шаги лишние?

Если все работает - то лишнего ничего нет 8=)

Сказать в чем была проблема сложно.

С дампером у меня обычно все получается в два этапа - сдампить с force->utf8 и загрузить через mysql.