И снова проблемная кодировка 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 а вот и , на котором была проблема с кодировкой. Загляните, интересные ролики.
Рубрики: Wordpress Метки: Wordpress, глюки, инструкция
(голосов: 3, средний: 3.67 из 5)
Loading ...Связанные записи
15 комментариев
Комментарии не по теме удаляются! Читайте реадми дистрибутива, комментарии выше и FAQ! Прежде чем задавать вопрос, прочитайте это. Научитесь ценить чужое время!
4 мая 2008 в 22:21 (GMT+6)
респект!
4 мая 2008 в 22:39 (GMT+6)
извращенцы
5 мая 2008 в 0:39 (GMT+6)
Респект!
5 мая 2008 в 2:06 (GMT+6)
пока существует куча кодировок, с ними буду проблемы. выход один — прийти к власти и запретить все нах кроме одной (:
5 мая 2008 в 14:21 (GMT+6)
как перекодировать все таблицы в базе для WP в нужную кодировку при условии что русские буквы по какимто причинам отображаются не так как надо. :)
6 мая 2008 в 1:37 (GMT+6)
Наверное уже стоит базу проблематичных хостеров создавать, которые такие подарки могут преподнести.
8 мая 2008 в 17:03 (GMT+6)
![]()
Маленький комментарий от этого конкретного хостинга,
который заключается в том, что клиент сам при создании базы выбирает кодировку. Для PHP 4 несколько лет назад это был лучший вариант.
Сейчас такую базу на нашем хостинге создать можно только долго и неправильно выбирая параметры.
8 мая 2008 в 20:18 (GMT+6)
Стоит FAQ на хостинге обновить наверное. И написать подробнее про смену кодировок, чтобы пользователи потом не страдали. И как вообще повлиять могло то что обновили РАБОТАЮЩУЮ систему wp2.3.3 до 2.5.1 и при этом умерла кодировка, хотя на всех хостингах даже с кодировкой win1251 все происходит в большинстве случаев нормально. А с latin1 одни проблемы и не только в WP. Ко мне уже обращались люди с просьбой восстановить из этой “хорошей” кодировки свои базы сайтов. Отсюда и столько разных способов появилось о которых я периодически пишу здесь, т.к. каждый отдельный случай может отличаться. Досточно погуглить на тему latin1 utf8 чтобы понять что проблема масштабна и реально описаний как все исправить почти нет
9 мая 2008 в 14:27 (GMT+6)
1GB вообще странный хостинг – годится только для сайтов-визиток с посещаемостью стремящейся к нулю.
Там много к чему претензии можно иметь, кодировка БД даже не во главе списка.
13 мая 2008 в 20:59 (GMT+6)
До сих пор с ужасом вспоминаю как делал подобное для базы инвиженовского форума… правда мне попался еще более сложный случай потому что в базу латин писался уникод который реально был текстом в koi8-r :) сидел и вручную дамп конвертил :)
13 мая 2008 в 21:40 (GMT+6)
раздули проблему, если данные реально представляют ценность то, все эти процедуры можно сделать за очень и очень скромную сумму у профи…
13 мая 2008 в 21:53 (GMT+6)
некоторых жаба давит (вспоминая как один тут давно просил помочь переделать ему базу галереи одной), но нахаляву вообще а потом еще и возмущался тут и на форуме галереи что его послали
22 июня 2008 в 15:05 (GMT+6)
На путаница с кодировкой… Вперемешку то нормальные строки русскими буквами, то знаки вопросов сплошь.
22 июня 2008 в 17:52 (GMT+6)
1 сайт не мой
2 причины проблемы не знаю – спросите у авторов сайта что они меняли. все было нормально
2 сентября 2008 в 19:08 (GMT+6)
Интересно, а если дамп занимает 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′)
Наверно все таки не криворукость хостеров ключевой момент