Правильная настройка базы 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-а должно происходить в зависимости от того в какой ветке? |
Цитата:
|
Цитата:
Как это делать описано в доке по локализации. Frontend Localization Guide (свежая дока кстати) http://typo3.org/documentation/docum...guide/current/ Цитата:
(в базу все будет идти в utf8, юзер у которого руссий язык - будет в BE работать в windows 1251 - с этим подробно разбирался Павел Антонов - он вроде даже патч делал на эту тему... чтобы все-таки все было в utf8) А для вывода в FE - для разных деревьев можно проставить разные кодировки - на лету идет конвертация |
Переношу БД в utf-8.
БД конвертируется хорошо. Так как default character set установлен в UTF-8, то при импорте дампа таблицы создаются с charset utf-8 и collation utf_general_ci. Сам дамп конвертирую такой программой Цитата:
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, использовал тот, который Андрей Шварцкопф делал.
|
Цитата:
|
Кое что нарыл по 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: Цитата:
я же применил другой хак, взятый здесь 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); } - сами понимаете почему. |
а если это свежая установка "с нуля", где дампа нет, то что делать?
|
Цитата:
|
<?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 или что это? |
Если я не ошибаюсь, то вас ошбка в коде:
Код:
$contents .= fread($handle, 8192); Код:
$contents = fread($handle, 8192); А в общем, даже если предположить, что в дампе все символы из кириллицы (кодируемые в utf8 по 2 байта на символ) то файл не должен быть польше 20 мег. А ввиду того, что в дампе, как правило, достаточно много символов из latin1 (кодируемых 1-м байтом) то размер должен быть мег 16-18 при начальных 10. |
применительно к indexed search: должен ли в utf-8 при условии правильной настройки работать морфологический поиск?
у меня, к примеру, только прямые совпадения ищет.. |
Цитата:
Насколько сложно его сделать - я не копал, наверное сложно. Впрочем, никто из серьезных заказчиков (я имею ввиду ITспециалистов из 2х крупных контор, которые занимаются системной интерацией и входят в top10 в России) на этом не настаивал... все понимают, что поиск на сайте - это не яндекс. Варианты типа MnogoSearch сложны в настройке и обслуживании (если только MnogoSearch уже не стоит у данного провайдера). Да и выигрыш от их использования будет не большой... люди как правило ишут простые слова, фамилии.. т.е. слоформы не так уж важны. |
При перкодировании столкнулся с проблемой - каждый первый символ новой строки не конвертируется. То есть, вначале идет два символа в latin1, а остальная строка в utf8. Пользуюсь iconv под винды от GTK+.
Кстати, в результате конвертирования пропали страницы. Видны в DB Check, видно, что у каждой первый символ неправильно, но в списке страниц их вообще не видно. |
Вложений: 2
Значит так...
Распаковал архивы, создал БД, перед тем как ставить в локалконф вставил: $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...
Заменить: Код:
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;'; Код:
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8; SET character_set_connection = utf8;'; |
сильно извиняюсь..:).. не подскажеье для чего character_set_connection?
использую теже параметры, но без character_set_connection. в результате при просмотре базы ячерез phpmyadmin, данные хранятся в читаемом виде (подключаюсь к phpmyadmin как к utf).... но есть ряд глбюков. 1. mailform. скрипты с битой кодировкой. фронтненд в utf-8. 2. В темпла воила при просмотре шаблона всегда ошибки с кодировкой. :(((... это не сильно напрягает, в конечном виде всегда все нормально (при условии, что файл шаблона сохранен в utf-8, но всеравно неприятно.) |
Цитата:
$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 |
Цитата:
Выхода наверное два: установить поддерживаемую кодировку (если для русского, то это наверняка будет 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'; также установил))) |
Цитата:
PHP код:
Цитата:
|
Простите запутал вас.
как раз вот это я и поставил $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; не эксперимнтировал. |
Цитата:
Я столкнулся с тем, что она режет символы типа многоточий (была конвертация сайта из 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.. |
Цитата:
это надо сделать... потом.. сталкивался с такими проблемами... когда переносил базу, которая до этого была в утф8... решал так: перед тем как импортировать БД создаешь чистую базу данных в утф8... т.е. не потом назнаешь созданной БД кодировку.. а сразу.. чтобы она создавалась с дефолтовой Utf8. Потом импорт БД делал непостредственно при устновке тайпы.... Всё работало... |
проблемы c Ш
при некоторых настройках MySQL помогает похоже только вот такая конфигурация:
Код:
SET character_set_client = `utf8` |
Цитата:
|
Изначально таблицы создавались dumper-ом (force->utf8), но я не мог понять где проблемы. Потом с настройками выше заработало сначала с чистой установкой, а потом и с бекапной базой . Перекодированной из cp1251. Осталось TV поправить.
... ну вот (смайлик - утирает пот) переход на utf-8 и ПХП5 занял всего сутки :) Павел, можно немного внимания? /я очень люблю знать и всегда интересуюсь как (с) Стругацкие / Подробно про базу: сначала просто восстановил инсталяцию (4.0), поставил форсеЧарсет и восстановил дампером базу. Как писал выше - везде где видно - утф_генерал_ци. С третьей или четвертой попытки добился того, что в пхпМайАдмин чистый УТФ без потерь контента. В бекенде - бред. (вопросики, то в черных ромбиках,то без). СЕТ НЕЙМС пробовал. Без эффекта. Сделал чистый инстал (все таблицы при каждой попытке убивались, а не только чистились). СЕТ НЕЙМС не ставил. Получил на таблицах коллейшн - 1251. Убил. Восстановил базу дампером. Все коллейшн правильные. Обнулил таблицы. Восстанновил чисто содержимое через инстал тул. Получил проблемы с "Ш". Поставил приведенный выше блок кода в ДБ Инит. Получил все старые данные - 1251 отображенные в юникоде. Зато при вводе новых все проблемы исчезли. Восстановил базу. Полет нормальный. Где ошибся по дороге? Какие шаги лишние? |
Если все работает - то лишнего ничего нет 8=)
Сказать в чем была проблема сложно. С дампером у меня обычно все получается в два этапа - сдампить с force->utf8 и загрузить через mysql. |
Часовой пояс GMT +4, время: 06:19. |
Работает на vBulletin® версия 3.8.1.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot