Как быстро настроить кодировку базы данных для WordPress’а

Для этого существует довольно простой и эффективный способ. Делать это лучше перед установкой WordPress'а.

Итак вы создали базу данных (или это произошло автоматически). Но не спешите устанавливать WordPress - вместо этого откройте phpMyAdmin (он должен быть у каждого порядочного хостера).

Дальше вам нужно выбрать базу данных и если таблиц еще не создано, то появится сообщение «Таблиц в базе данных не обнаружено». Если же таблицы в базе уже есть, то вы увидите их список и сразу же обратите внимание на самую нижнуюю строчку «Таблиц всего:» и «Сравнение». Если вы видите, что-то отличное от «utf8_general_ci» (или если таблиц нет), то переходим на закладку «Операции».

Внизу вы увидите выпадающий список «Сравнение», где нужно выбрать «utf8_general_ci». После этого жмем «ОК».

Теперь все новые таблицы в этой базе данных по-умолчанию (без указанного db_collate) буду создаваться в «utf8_general_ci», что собственно и нужно. Теперь, если какой-то плагин будет создавать свою таблицу, она автоматически будет создаваться в нужной кодировке.

Некоторые предостережения. Теоретически никакие негативные последствия данная операция на уже существующие таблицы не оказывает. Происходит это из-за того, что начиная с MySQL 4.1 каждая таблица и каждое поле таблицы имеют свою кодировку сравнения. Поэтому изменяя кодировку базы, вы лишь меняете кодировку по-умолчанию, не затрагивая уже существующие. Но вообще данный совет подойдет прежде всего тем, кто устанавливает WordPress с нуля. Для остальных это не так актуально, но если всё-таки решите выполнить данную операцию, то нелишним будет сделать бэкап базы.

Постоянная ссылка: http://maxsite.org/?p=315
Версия для печати

28 комментариев к “Как быстро настроить кодировку базы данных для WordPress’а”

1. iSynth: 23 ноября 2007 в 08:29 Максим, а не трудно вам будет написать про то, как правильно бэкапить базу данных вордпресса и плагинов через Экспорт phpMyAdmin? там всегда столько разных опций, поэтому что было бы универсальным средством выбора? заранее спасибо!

2. Maksus: 23 ноября 2007 в 10:20 Спасибо, Макс, так и делал раньше ))

3. Dimox: 23 ноября 2007 в 10:52 Поддерживаю iSynth. Думаю, что данный вопрос интересен многим пользователям.

4. DunKan: 23 ноября 2007 в 12:07 и я так раньше делал и писал в одном из комментов об этом... НО есть, имхо, еще один нюанс. Как-то компания Агава решила перенести мой хост на другой сервер, непредупредив, кстати говоря, в процессе переноса кодировка сбилась.

5. Максим: 23 ноября 2007 в 12:43 Да от кривык рук хостера никто не защищен. Совсем свежий пример с мастерхостом. Такое впечатление, что там одни дауны работают. Вчера меняли опять свою MySQL. Так базы, где явно указана utf-8 эти идиоты взяли и прописали как cp1251. Естественно, что все тексы оказались испорчены...

6. Crash: 23 ноября 2007 в 14:42 Еще пример - у меня один из блогов работает на "странной" базе. Везде указано, что кодировка каждой таблицы utf-8, а в самом низу, как бы под общей чертой уже cp1251 стоит!

7. Максим: 23 ноября 2007 в 17:39 Блин, откуда в мастерхосте берут админов? Объявляют конкурс даунов? Вот изменили базу - кодировку должна быть utf-8, они сделали cp1251. Ежику понятно, что нужно взять старый бэкап и из него восстановить базу в нормальной кодировке. Что делают эти идиоты? Они берут прописывают в wp-settings.php тупо в самый конец mysql_query("SET NAMES cp1251"); Нет слов, одни маты...

8. Александр М.: 23 ноября 2007 в 20:33 Нет слов, одни маты... А чего Вы так возмущаетесь, Максим? Мне они за 2 недели письмо прислали. Предупредили о модернизации и дали ссылку на текст, где указаны расхождения и особенности, которые могут возникнуть. Я на следующий, после переноса день, просто в wp-config.php Wordpressa переписал две строчки вот так: define('DB_CHARSET', 'cp1251'); # кодировка базы данных: utf8 или cp1251 define('DB_COLLATE', 'cp1251_general_ci'); # кодировка, в которой хранятся данные: utf8_general_ci или cp1251_general_ci И все. Никаких проблем.

9. Максим: 23 ноября 2007 в 20:41 Я вам объясню в чем проблема. В базе данных тексты сохранились в utf-8. Для таблиц была указана именно эта кодировка. Все работает замечательно. Теперь эти умники ставят кодировку cp1251, но тексты, как и прежде хранятся в utf-8. То есть уже явное расхождение. В конце-концов загляните в phpMyAdmin и убедитесь, что тексты у вас нечитабельны.

10. Александр М.: 23 ноября 2007 в 21:02 Я прекрасно понимаю, что у меня, например, сейчас происходит двойная перекодировка. И, если честно, собирался им написать письмо с вопросм: не увеличивает ли это нагрузку и можно ли отключить их перекодировку, для того, что я отключил в свою в скрипте. Но я не об этом. А о том, как Вы пишите: "дауны" и "тексты испорчены". Понятно, что все "Ваши" Вордпрессовцы, которые на Мастерхосте (и я в том числе), оказались в ситуации: utf8 -> cp1251 -> cp1251 -> utf8. Вместо того, чтобы сразу из скрипта в базу: utf8 -> utf8 Ну хотите, напишите им сами письмо. Можно это безобразие убрать или нет? Чего раздражаться-то? У них же не только я и Вы Успехов Вам и благоразумия.

11. Максим: 23 ноября 2007 в 21:36 Понимаете, Александр, все дело в том, что хостинг, который позиционирует себя как чуть ли не лучший в рунете, не может нанять квалифицированный персонал. Вот вы согласны с тем, что вам испортили базу. А не приходит ли вам в голову, что это может аукнуться в будущем. Вот вы добавите одну запись и половина текста окажется в одной кодировке, а другая в другой. Потом, когда вы будете делать бэкап, вы просто не сможете нормально восстановить свои тексты. Или как в таком случае будет работать сортировка, поиск? И обратите внимание, что речь не идет от чем-то экстраординарном: все эти проблемы возникли из-за непродуманности действий админов. Или, что скорее всего, их крайне низкой квалификации.

12. Александр М.: 23 ноября 2007 в 21:38 ставят кодировку cp1251 Внесу поправочку (хотя, может Вы именно это и имели ввиду): ставят не "кодировку", а "перекодировку". Подробности от Мастерхост-а: "Переход на PHP5+MySQL5"

13. Александр М.: 23 ноября 2007 в 21:50 Вот вы согласны с тем, что вам испортили базу. Это Вы сказали. Я так не считаю. Тексты сохранились, поиск работает. Новые публикации и комментарии функционируют как и прежде. И все это из-за двойного перекодирования. Т.е. мои тексты и комментарии так и продолжают извлекаться как utf8, так и сохраняться в базе в кодировке utf8. Не вижу смысла далее обсуждать квалификацию персонала Мастерхост-а. И у меня нет цели переубеждать Вас. Просто мне казалось, что Вы спосбны смотреть на проблемы объективно, а не эмоционально. Успехов Вам.

14. iSynth: 23 ноября 2007 в 21:54 отличная дискуссия, заставившая еще раз проверить настройки на "своем" хосте! вот что предстало взгляду: localhost Версия сервера: 5.0.27-standard Версия протокола: 10 Сервер: Localhost via UNIX socket Пользователь: isynth@localhost MySQL-кодировка: UTF-8 Unicode (utf8) Сопоставление соединения с MySQL: utf8_unicode_ci в базах данных: База данных Сравнение my_database cp1251_general_ci подскажите, все ли правильно?

15. Максим: 23 ноября 2007 в 22:26 Ну я тоже особо и не горю желанием кого-то убеждать. В конце концов, если вас устраивает такая ситуация, то вы и пользуетесь таким хостингом и платите за него своими деньгами. Я правда так и не понял, что такое «двойное перекодирования» и если у вас используется приведенная схема, то как вообще тексты могут быть корректными? Мой опыт подсказывает, что не всё благополучно в вашей базе. Ну тут уж вам решать... В копилку некомпетентности админов мастерхоста я могу добавить еще и попытку прописать вызов SET NAMES cp1251 в wp-settings.php. Я понимаю, что они в WordPress'е ничего не соображают, но почему бы тогда не обратиться к файлу wp-config.php? То есть вместо того, чтобы по нормальному исправить базу, админ лезет в первый попавшийся файл и прописывает строчку из своего фака. Теперь опишу ситуацию для простого клиента, который вообще в этом ничего не смыслит. Прежде всего следует отметить, что данный запрос уже используется в WordPress, но вот только в кодировке блога (utf-8). Поэтому часть запросов может отдаваться в нормальном виде (например тексты), а вот остальные, например опции, уже в покоцанной. Клиент, ничего не зная, что мастерхост самостоятельно и без его ведома исправил какие-то файлы «движка», естественно пишет в службу поддержки и получает ответ, типа того, что у нас все нормально, эта ошибка в ваших скриптах и посылает по приведенной вами ссылке (я её убил). 2iSynth: Да именно об этом я и пишу. Нужно поменять кодировку базы на utf8_general_ci

16. Александр М.: 23 ноября 2007 в 22:39 Максим... про убранную ссылку у меня просто нет слов. Не ужели Вы решили, что FAQ - это реклама?

17. Lecactus: 23 ноября 2007 в 22:42 еще раз убедился что хостинги зло. на самом деле чем думаю админы того же мастерхоста...почему я у себя на сервере могу создать любую базу с любой кодировкой и все работает нормально, хотя также использую " PHP5+MySQL5". Кстати я вроде уже писал, но повторю что когда в одной базе там пытался сменить кодировку на утф8 и обратно на 1251 реально ничего вообщене происходило с данными. они всегда на самом деле были в кодировке 1251 независимо от того что было в wp-config и показывалось в collate в phpmyadmin. заливал базу из дампа, сохраненного в обоих кодировках но при заливке утф-8 получались небольшие глюки

18. sonika: 24 ноября 2007 в 14:51 Я на новой инсталации WP всегда плагином UTF-8 Database Converter по базе «прохожусь». Я тут его уже один раз рекламировала Очень мне нравится простотой и удобством. Кнопка нажал — и готово. Александр М. Странно, как это у Вас поиск корректно работает :/ И вообще, что Вы мастерхост так рьяно защищаете? Работаете там что ли?

19. Александр М.: 24 ноября 2007 в 22:05 И вообще, что Вы мастерхост так рьяно защищаете? Вообще? Хоть я и не защищаю, а пытаюсь понять причину столь бурного негодования Максима, но в любом случае: надеюсь Вы не считаете возможным запретить высказать мне мою личную точку зрения и также надеюсь, Вы не против того что мне интересно понять объективную причину таких горячих эпитетов? Работаете там что ли? Не там а с ними.

20. sonika: 25 ноября 2007 в 00:53 Александр М., так разве кто запрещает высказываться? Где я что такого сказала, что Вы углядели столько грозные намерения в моих словах? Когда с чем-нибудь намаешься зазря или не по своей вине, вот тогда обычно и появляется бурное негодование. В общем, блажен не ведающий

21. Алекс: 3 декабря 2007 в 14:02 что то я из комментариев выше не понял, так все таки должна быть utf8_unicode_ci или utf8_general_ci?

22. Максим: 3 декабря 2007 в 14:39 utf8_general_ci

23. Алекс: 3 декабря 2007 в 14:42 да, уже понял, спасибо. вот еще может кому интересно будет: http://codex.wordpress.org/Converting_Database_Character_Sets

24. Петров Николай: 23 февраля 2008 в 19:26 Спасибо Макс! Кодировка в ВП - больная тема и уже долго приходится с этим иметь дело. Спасибо что публикуешь актуальные новые материалы по этой теме. Чисто теоретически - возомжно написать SQL команду, которая автоматизировала-бы этот процесс смены кодировки?

25. sonika: 24 февраля 2008 в 16:09 Петров Николай, этот плагин не подойдет?

26. Петров Николай: 24 февраля 2008 в 18:53 Спасибо sonika за наводку! To Максим: насчет кодировки - у меня на американском хостинге (dreamhost) по умолчанию стоит английский ВП, и выполнение инструкций, написанных в этой статье не приводит к желаемому результату. Однако скачанная оригинальная версия wordpress-russia.org + описанные выше инструкции наконец-таки дали свои плоды. Да, и спасибо за информацию о том что нужна именно general а не unicode, долго не мог понять какую лучше использовать.

27. elsik: 9 марта 2008 в 14:49 у меня установлен utf wordpress на 1251 хостинг. подскажите, как перевести его тоже в 1251, включая таблицы ?

28. 35metod: 9 мая 2008 в 21:35 меня мой хостер так же поставил в ситуацию (( там аж 2 блога на ВП даже не могу теперь зайти в админ панель - дата бейс конвертер только из админки ж можно запустить видимо ? он переконвертит из cp1251_general_ci в utf полностью внутри все таблицы ? wp-config пробовал менять по разному, ничего не помогает, когда текст становится читаемым, но названия разделов блога всё равно нечитаемые

Оставьте комментарий! (Вы согласны с правилами)

Имя (обязательно)

E-mail (не для публикации) (обязательно)

Сайт

 

При добавлении кода (html, php) заменяйте < на &lt; и > на &gt;.
Внимание: антиспам - зверь! Копируйте своё сообщение перед отправкой. На всякий случай.

Введите только нижние символы

Уведомить меня о новых комментариях через эл.почту