|  | 
| 
 Периодически сама по себе меняется кодировка Ситуация в следующем. Есть база и инсталляцис typo3 в тайпо указана кодировка utf8 все хорошо, но в одни прекрасный момент кодировка самопроизвольно меняется, и периодически скачет с windows-1251 на геа8 и обратно. в основном это происходит при изменении и созранении чего-либо в BE. посоветуйте где посмотреть | 
| 
 имел дело с такой проблемой 1) проверьте что стоит $TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;'; в localconf 2) что нет других коннектов к MySQL от того же юзера, у которых кодировка другая (на счет этого не уверен, но было подозрение, что может быть в этом причина глюков) | 
| 
 так, испытываю первый совет, пока нормально вроде. | 
| 
 у меня было так, что кодировка слетала в закешированом контенте: к перечисленому Валерием добавлю 3) нужно убедится что Вы коннектитесь к базе данных не не под рутом если все пункты (1-3) проверены измените тип всех blob полей на соответстующие text типы (mediumblod -> textblob и т.д.) | 
| 
 коннекчусь под рутом, но пока вроде нормально, если не поможет совет Валерия то попробую поменять пользователя БД | 
| 
 Так в чем же была проблема? У меня возникала такая же проблема, что делать? На сервере несколько тестовых площадок для разработки, названия баз данных разные, а вот пользователь один и тоже, для всех, может проблема в этом? | 
| 
 $TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8; решило проблему | 
| 
 Ну да у меня в "Configuration" прописано: Код: $TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8 SET CHARACTER SET utf8 SET SESSION character_set_server = utf8 SET character_set_connection = utf8';Может это надо укоротить к минимуму? Вот так: Код: $TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8'; | 
| 
 так синтаксис не верный, напишите это в InstallTool - > All configuration в поле setDBinit в поле должно быть написано так: SET NAMES utf8; если несколько команд то заполняйте через это поле, иначе придется добавлять спец символ переноса строки и еще посмотрите стоит ли [forceCharset] = utf-8 | 
| 
 В "All Configuration" [setDBinit] прописано несколько команд, вот так  Код: SET NAMES utf8 SET CHARACTER SET utf8 SET SESSION character_set_server = utf8 SET character_set_connection = utf8Писать команды чере ";"? Но дело в том, что раньше такого не наблюдалось, а началось после того, когда поставили еще одну площадку для разработки с одним и тем же пользователем базы данных. | 
| 
 Цитата: 
 Цитата: 
 | 
| 
 И еще, почитайте внимательно комментарии к этому полю!!! И я вам говорил, и там написано, что каждая новая команда на НОВОЙ СТРОКЕ. Если раньше все работало с этими командами это может быть далеко не заслуга этих команд. | 
| 
 Код: SET NAMES utf8;Код: doctype = xhtml_transРебята, что делать? Выручайте, кодировка уже периодически не меняется, а стала непонятной и все, вот такой: Мертвого юнака | 
| 
 пробуем убрать forceCharset из tool | 
| 
 Цитата: 
 | 
| 
 Результат в BE или FE? | 
| 
 Цитата: 
 в FE Ð�овини в BE еще хуже кодирует Ã�£Ã�ºÑ€Ã�°Ñ—Ã�½ÑÂ�ÑŒÃ�ºÃ�° Убрал Код: #forceCharset = utf-8Заметил, что вся кириллица, которая в базе хранится выводиться плохо, а та кириллица, которая в шаблонах прописана, выводится хорошо. | 
| 
 в базе сопостовление какое стоит? всмысле кодировка самой базы? | 
| 
 Цитата: 
 | 
| 
 хм, щас убегаю, приду и подумаю что еще можно сделать | 
| 
 phpmyadmin-ом в базу загляните - там кракозябры или читаемо? Возможно, что из-за отсутствия SET NAMES utf8; с самого начало всё было неправильно и базу недо перекодировать | 
| 
 Похоже на то, что у вас данные в базе н в utf-8. Перепроверьте, и, если это так - переконвертируйте или перезалейте базу. Цитата: 
 | 
| 
 Спасибо ребята за отклик. Давайте по порядку. Я с начало создал базу, поставил все в utf-8. Потом поставил систему (4.1.5), все настройки поставил в utf-8, сделал сайте. Поставил еще одну площадку для разработки, по той же схеме, что и выше, работало все нормально. Потом вышла новая версия системы, после чего я обновил две системы до версии 4.1.6. Работало все нормально. Поставил еще одну площадку для разработки (версия 4.1.6) по той же схеме что и предыдущие, работало все нормально. Потом не из того не из чего началось непонятная, неконтролируемая смена кодировки. То нормально работает, то ненормально, потом вообще все стало выводить в ненормально кодировке. На сервере стоить пять сайтов, и все они используют одну и туже базу все базы в utf-8 и сайты тоже. Создано пять баз данных все в utf-8 у двух первых пользователи разные, а вот у трех пользователь один и тот же. Три сайта работают нормально, а вот два не нормально. Перепроверил все настройщики пяти сайтов, ничего не изменилось все utf-8, но два сайта по-прежнему выводят данные в неправильно кодировке. Смотрел во внутрь базы все данные, закодированные в utf-8, то есть в базе они нечитаемые (кракозябры). Что делать, ума не приложу? | 
| 
 Последуйте совету void'а. Я думаю, он прав. | 
| 
 Хорошо, а как перекодировать базу в utf-8? Кое-что прочитал здесь, но здесь говориться только об одной таблице, а нельзя ли такое же сделать для всей базы? И как узнать в какой кодировке закодированные данные? Для теста в одной записи контента в заголовке радом с Ð�а віÑ�Ñ‚Ñ€Ñ написал слово «Перевiрка» и сохранил. Иду в базу и смотрю в базе сохранено «Перевiрка - Ð�а віÑ�трѻ… слово «Перевірка» читаемое , а Ð�а віÑ�Ñ‚Ñ€Ñ – не читаемое. Захожу в базу, пишу запрос Код: ALTER TABLE tt_content CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;Но все же вопрос, почему это случилось, ведь база и система настроена в utf-8 за исключением того, что в [setDBinit] не был правильно написан запрос вместо этого Код: SET NAMES utf8;Код: SET NAMES utf8 SET CHARACTER SET utf8 SET SESSION character_set_server = utf8 SET character_set_connection = utf8;Теперь непонятно, что делается база в utf-8 настройки системы в utf-8, а вот данные в базе неизвестно в какой кодировке? Прошу у общества помощи в решении проблемы. | 
| 
 Цитата: 
 Цитата: 
 Цитата: 
 Цитата: 
 | 
| 
 | 
| 
 Цитата: 
 Сопоставление соединения с MySQL: utf8_general_ci Насколько я понимаю данные в базе данных закодированные в UTF-8 И что-то натолкнуло меня на мысль, что, что-то эти данные берет из базы и еще раз конвертирует их…, такое может быть? | 
| 
 Очень, очень советую слить базу на локальный mysql и экспериментировать с перекодировкой именно там. Да, к сожалению, если с самого начала не указать SET NAMES utf8; в setDBinit, то в базе будут кракозябры. | 
| 
 Ребята теперь я понял, что поздно махать руками, надо думать, как это все дело перевести в нормальный читабельный вид. У меня подозрение, что utf перекодировалось еще раз в utf, то есть произошло двойное кодирование в utf. Может такое быть? Стоят две задачи: 1. Узнать в какой кодировке, все это дело закодировано или перекодировалось? 2. Чем декодировать всю базу в utf? Возможно, нужно сделать двоичное декодирование… Может, кто подскажет, php скрипт, программку или метод как это сделать…? | 
| 
 Цитата: 
 Теперь осталось решить самую главную задачу, как всю базу перевести в читаемый вид? | 
| 
 Готового решения лично у меня нет... Можно попробовать написать самостоятельно скрипт, используя SQL-запросы типа SHOW TABLES и iconv. | 
| 
 Есть программа "Navicat for MySQL". Так вот, она позволяет базе, которая уже имеет кодировку utf, установить ещё раз принудительно utf-8. После этого все данные (перекодированные дважды) видны замечательно. Косяк тут будет с экспортом. Например, в дамп SQL. Потому что экспортировать SQL-данные, которые бы принял phpMyAdmin, лучше всего может, естественно, phpMyAdmin. А Navicat выдаёт файл, в котором, например, не "1, NULL, NULL, 2", а просто "1, , , 2". У меня в phpMyAdmin "проскочила" только таблица tt_produсts (при ручном исправлении вышеописанных запятых на NULL). Поэтому приходится вначале экспортировать всё Navicat'ом из испорченной базы, потом поменять кодировку подключения и подключиться к правильной базе. И импортировать эти же файлы именно Navicat'ом в правильную utf-8 базу. Ни один промежуточный формат экспорта-импорта не дал 100%. Но лучше всего оказался экспорт-импорт через MsAccess'овский mdb-файл. | 
| Часовой пояс GMT +4, время: 00:17. | 
	Работает на vBulletin® версия 3.8.1.
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Перевод: zCarot