Периодически сама по себе меняется кодировка

roman · 25.04.2008, 19:02

Цитата:

Сообщение от thebat

Хорошо, а как перекодировать базу в utf-8?

Наиболее простой вариант - слить дамп и переконвертировать его в каком-нибудь редакторе и снова залить. Но так как у вас большая база, то часть уже может быть в utf-8, а часть в какой-нибудь друной... Тут нужно аккуратно все проверять.

Цитата:

Сообщение от thebat

Кое-что прочитал здесь, но здесь говориться только об одной таблице, а нельзя ли такое же сделать для всей базы?

Нет, нельзя. Там же и написано.

Цитата:

Сообщение от thebat

И как узнать в какой кодировке закодированные данные?

Посмотрите какая кодировка стоит по умолчанию в вашем клиете (phpMyAdmin, MySQL Query Browser, mysql etc.) В этой кодировке вы увидите корректно отображаемые данные. Смените кодировку клиента на utf-8 и увидите какие записи отображаютс как кракозябры - вот это и есть неверная кодировка... Одним словом нужно экспериментировать. Желаю удачи!

Цитата:

Сообщение от thebat

Для теста в одной записи контента в заголовке радом с Ð�Ð° Ð²Ñ–Ñ�Ñ‚Ñ€Ñ написал слово «Перевiрка» и сохранил. Иду в базу и смотрю в базе сохранено «Перевiрка - Ð�Ð° Ð²Ñ–Ñ�Ñ‚Ñ€Ñ»… слово «Перевірка» читаемое , а Ð�Ð° Ð²Ñ–Ñ�Ñ‚Ñ€Ñ – не читаемое. Захожу в базу, пишу запрос

Код:

ALTER TABLE tt_content CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;

В результате ничего, все как было, так и осталось без изменений.

roman · 25.04.2008, 19:09

http://forum.typo3.biz/showpost.php?...2&postcount=32

thebat · 25.04.2008, 19:14

Цитата:

Сообщение от roman

Посмотрите какая кодировка стоит по умолчанию в вашем клиете (phpMyAdmin, MySQL Query Browser, mysql etc.) В этой кодировке вы увидите корректно отображаемые данные. Смените кодировку клиента на utf-8 и увидите какие записи отображаютс как кракозябры - вот это и есть неверная кодировка... Одним словом нужно экспериментировать. Желаю удачи!

MySQL-кодировка: UTF-8 Unicode (utf8)
Сопоставление соединения с MySQL: utf8_general_ci

Насколько я понимаю данные в базе данных закодированные в UTF-8

И что-то натолкнуло меня на мысль, что, что-то эти данные берет из базы и еще раз конвертирует их…, такое может быть?

void · 25.04.2008, 19:29

Очень, очень советую слить базу на локальный mysql и экспериментировать с перекодировкой именно там. Да, к сожалению, если с самого начала не указать SET NAMES utf8; в setDBinit, то в базе будут кракозябры.

thebat · 25.04.2008, 22:06

Ребята теперь я понял, что поздно махать руками, надо думать, как это все дело перевести в нормальный читабельный вид.

У меня подозрение, что utf перекодировалось еще раз в utf, то есть произошло двойное кодирование в utf. Может такое быть?

Стоят две задачи:

1. Узнать в какой кодировке, все это дело закодировано или перекодировалось?
2. Чем декодировать всю базу в utf?

Возможно, нужно сделать двоичное декодирование…

Может, кто подскажет, php скрипт, программку или метод как это сделать…?

thebat · 26.04.2008, 17:02

Цитата:

Сообщение от thebat

Стоят две задачи:
1. Узнать в какой кодировке, все это дело закодировано или перекодировалось?

И так одна проблема решена. Теперь я точно знаю, что все данные закодированы в UTF-8 только, насколько я понял это сделано два раза, как я это проверил? Это я проверял вот здесь...

Теперь осталось решить самую главную задачу, как всю базу перевести в читаемый вид?

void · 26.04.2008, 19:23

Готового решения лично у меня нет...
Можно попробовать написать самостоятельно скрипт, используя SQL-запросы типа SHOW TABLES и iconv.

boulder · 19.05.2008, 12:35

Есть программа "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-файл.

25.04.2008, 19:29	#4
void Senior Member Регистрация: 14.03.2006 Адрес: Russia, Penza Сообщений: 1,504	Очень, очень советую слить базу на локальный mysql и экспериментировать с перекодировкой именно там. Да, к сожалению, если с самого начала не указать SET NAMES utf8; в setDBinit, то в базе будут кракозябры. __________________ TYPO3 FAQ

25.04.2008, 22:06	#5
thebat Senior Member Регистрация: 05.09.2006 Адрес: TYPO3.if.ua Сообщений: 224	Ребята теперь я понял, что поздно махать руками, надо думать, как это все дело перевести в нормальный читабельный вид. У меня подозрение, что utf перекодировалось еще раз в utf, то есть произошло двойное кодирование в utf. Может такое быть? Стоят две задачи: 1. Узнать в какой кодировке, все это дело закодировано или перекодировалось? 2. Чем декодировать всю базу в utf? Возможно, нужно сделать двоичное декодирование… Может, кто подскажет, php скрипт, программку или метод как это сделать…? __________________ Василий Мосийчук The BAT! TYPO3.NET.UA BLOG.TYPO3.NET.UA

26.04.2008, 19:23	#7
void Senior Member Регистрация: 14.03.2006 Адрес: Russia, Penza Сообщений: 1,504	Готового решения лично у меня нет... Можно попробовать написать самостоятельно скрипт, используя SQL-запросы типа SHOW TABLES и iconv. __________________ TYPO3 FAQ

Опции темы
Версия для печати Отправить по электронной почте
Опции просмотра
Линейный вид Комбинированный вид Древовидный вид

25.04.2008, 19:09	#2
roman Новенький Регистрация: 18.08.2006 Адрес: L'viv, Ukraine Сообщений: 17	http://forum.typo3.biz/showpost.php?...2&postcount=32

19.05.2008, 12:35	#8
boulder Новенький Регистрация: 28.06.2006 Сообщений: 17	Есть программа "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-файл.