И снова проблемная кодировка latin1
На этот раз попалась такая экзотика как база в кодировке latin1 c collation latin1_bin. Это уже третий пост (первый и второй) на тему latin1 и чувствую не последний, т.к. криворукость хостеров не знает границ:
Вчера я часа 3 мучался на своем сервере импортировал дамп этой базы и так и сяк, но максимум чего удавалось добиться это вернуть все на 90%, с пропажей всех кириллических букв С, Я и еще какой то, уже не помню.
Загружать базу пробовал и phpmyadmin’ом и скриптом bigdump и в консоле сервера с разными командами. Ничего не помогало.
Сегодня утром решил продолжить изыскания:
- Мне предоставили доступ к панели хостинга где была эта «кривая» база, где я нашел базу в формате файлов базы mysql (fmt myd myi) и скачал все файлы локально. При просмотре файлов в LISTER’е тоталкомандера увидел что русские буквы там читабельны при установке кодировки просмотра в utf8.
- Скачал набор чтобы настроить рабочую среду на компьютере. Можно и Денвер или другой аналог. Этот мне посоветовали недавно, сам ранее не пользовался никакими наборами. Все работает там без всяких танцев с бубнами и быстро.
- Изменил настройки мускула в My.cnf везде прописав кодировку latin1 и collation latin1_bin
- Создал пользователя и базу с нужным названием
- Закачал в папку «сайта» голый движок WP2.3.3 (можно и 2.5.* и любой другой под который у вас сделана база)
- Скопировал все файлы базы mysql в директорию новой базы (название директории в папке данных мускула соответствуют названию базы). В винде и линуксе это одинаково. Про bsd не знаю (не работал в ней). Конечно можно попробовать и просто импортировать дамп с кривой базой, но не факт что фишка прокатит. Хотя с перенастроенным мускулом может быть и заработало бы. Проверять не стал.
- Далее в конфиге WP я прописал жестко кодировку latin1 вместо utf8 как там есть изначально. Вуаля, сайт отображается корректно на русском. Мы своего добились и дальше действуем по схеме, которую я описывал более года назад, см ниже.
- Ставим плагин бэкапа базы данных
- Экспортируем базу при текущих настройках, не забыв выделить все нужные таблицы.
- Полученный дамп уже в корректной кодировке utf-8 и нормально открывается редактором utf8
- Делаем поиском и заменой: 1) COLLATE=latin1_bin меняем на пустое место (удаляем вообще). 2) CHARSET=latin1 меняем на CHARSET=utf8. 3) collate latin1_bin меняем также на пустое место (удаляем вообще)
- Сохраняем файл в кодировке utf-8
- Убеждаемся еще раз в каком нибудь LISTER’е от тоталкомандера что в режиме utf8 у нас все великолепно читается
- Заходим в phpmydmin (уже на сервере, а не на локалхосте) и удаляем все таблицы в базе. После этого на закладке ОПЕРАЦИИ меняем сравнение с latin1_bin на utf8_general_ci
- Импортируем новый правильный дамп базы через phpmyadmin в эту пустую базу
- В wp-config.php меняем слово latin1 на utf8
- Радуемся жизни дальше :-)
Если что то не получилось, то просматриваем все пункты по порядку еще раз. Также нужно учесть что файлы более 3мб редактор unicedit не очень любит и может ругаться на память, но после выдавания ошибки все работает дальше. Поэтому если это возможно то дамп БОЛЬШИХ таблиц делайте отдельным файлом.
Если вы сами не в состоянии справитсья с проблемой, то я могу это сделать за скромную сумму 10wmz(250руб) (webmoney|яндекс.деньги|на мобильник). Контакты найдете здесь на сайте.
PS а вот и , на котором была проблема с кодировкой. Загляните, интересные ролики.
Связанные записи
15 комментариев на запись “И снова проблемная кодировка latin1”
4 мая 2008 в 22:21
респект!
4 мая 2008 в 22:39
извращенцы
5 мая 2008 в 0:39
Респект!
5 мая 2008 в 2:06
пока существует куча кодировок, с ними буду проблемы. выход один — прийти к власти и запретить все нах кроме одной (:
5 мая 2008 в 14:21
как перекодировать все таблицы в базе для WP в нужную кодировку при условии что русские буквы по какимто причинам отображаются не так как надо. :)
6 мая 2008 в 1:37
Наверное уже стоит базу проблематичных хостеров создавать, которые такие подарки могут преподнести.
8 мая 2008 в 17:03
Маленький комментарий от этого конкретного хостинга,
который заключается в том, что клиент сам при создании базы выбирает кодировку. Для PHP 4 несколько лет назад это был лучший вариант.
Сейчас такую базу на нашем хостинге создать можно только долго и неправильно выбирая параметры.
8 мая 2008 в 20:18
Стоит FAQ на хостинге обновить наверное. И написать подробнее про смену кодировок, чтобы пользователи потом не страдали. И как вообще повлиять могло то что обновили РАБОТАЮЩУЮ систему wp2.3.3 до 2.5.1 и при этом умерла кодировка, хотя на всех хостингах даже с кодировкой win1251 все происходит в большинстве случаев нормально. А с latin1 одни проблемы и не только в WP. Ко мне уже обращались люди с просьбой восстановить из этой «хорошей» кодировки свои базы сайтов. Отсюда и столько разных способов появилось о которых я периодически пишу здесь, т.к. каждый отдельный случай может отличаться. Досточно погуглить на тему latin1 utf8 чтобы понять что проблема масштабна и реально описаний как все исправить почти нет
9 мая 2008 в 14:27
1GB вообще странный хостинг — годится только для сайтов-визиток с посещаемостью стремящейся к нулю.
Там много к чему претензии можно иметь, кодировка БД даже не во главе списка.
13 мая 2008 в 20:59
До сих пор с ужасом вспоминаю как делал подобное для базы инвиженовского форума… правда мне попался еще более сложный случай потому что в базу латин писался уникод который реально был текстом в koi8-r :) сидел и вручную дамп конвертил :)
13 мая 2008 в 21:40
раздули проблему, если данные реально представляют ценность то, все эти процедуры можно сделать за очень и очень скромную сумму у профи…
13 мая 2008 в 21:53
некоторых жаба давит (вспоминая как один тут давно просил помочь переделать ему базу галереи одной), но нахаляву вообще а потом еще и возмущался тут и на форуме галереи что его послали
22 июня 2008 в 15:05
На путаница с кодировкой… Вперемешку то нормальные строки русскими буквами, то знаки вопросов сплошь.
22 июня 2008 в 17:52
1 сайт не мой
2 причины проблемы не знаю — спросите у авторов сайта что они меняли. все было нормально
2 сентября 2008 в 19:08
Интересно, а если дамп занимает 100-200 Мб то задача не решаема? :)
Только что отконвертил базу слитую чарез phpmyadmin. Поля с дефолтной кодировкой — latin1, в которые данные писались в ср1251 и естественно крокозяблы а не дамп. Решилось все очень просто
cat db_duml.sql |iconf -c -f utf-8 -t latin1 > db_dump_iso.sql возвращием дамп в исходное состоянии, т.к. mysql считает что данные хранятся в латин1 а кодировка клиента(ПХП) — utf-8 и естественно не правильно их конвертит
cat db_dump_iso.sql |iconv -c -f latin1 -t cp1251 |replace «latin1» «cp1251» > dump_cp.sql конвертим в cp1251 и заменяем в дампе латин1 на cp1251
после этого в начало файла дампа добавляем запись SET NAMES cp1251;
При необходимости в скриптах после mysql_connect() mysql_select_db() добавляем mysql_query(‘SET NAMES cp1251’)
Наверно все таки не криворукость хостеров ключевой момент