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

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-файл.

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

19.05.2008, 12:35	#33
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-файл.