Как быстро настроить кодировку базы данных для WordPress’а
Пятница, 23 ноября 2007 г.
Просмотров: 4036
Подписаться на комментарии по RSS
Для этого существует довольно простой и эффективный способ. Делать это лучше перед установкой WordPress'а.
Итак вы создали базу данных (или это произошло автоматически). Но не спешите устанавливать WordPress - вместо этого откройте phpMyAdmin (он должен быть у каждого порядочного хостера).
Дальше вам нужно выбрать базу данных и если таблиц еще не создано, то появится сообщение «Таблиц в базе данных не обнаружено». Если же таблицы в базе уже есть, то вы увидите их список и сразу же обратите внимание на самую нижнуюю строчку «Таблиц всего:» и «Сравнение». Если вы видите, что-то отличное от «utf8_general_ci» (или если таблиц нет), то переходим на закладку «Операции».
Внизу вы увидите выпадающий список «Сравнение», где нужно выбрать «utf8_general_ci». После этого жмем «ОК».
Теперь все новые таблицы в этой базе данных по-умолчанию (без указанного db_collate) буду создаваться в «utf8_general_ci», что собственно и нужно. Теперь, если какой-то плагин будет создавать свою таблицу, она автоматически будет создаваться в нужной кодировке.
Некоторые предостережения. Теоретически никакие негативные последствия данная операция на уже существующие таблицы не оказывает. Происходит это из-за того, что начиная с MySQL 4.1 каждая таблица и каждое поле таблицы имеют свою кодировку сравнения. Поэтому изменяя кодировку базы, вы лишь меняете кодировку по-умолчанию, не затрагивая уже существующие. Но вообще данный совет подойдет прежде всего тем, кто устанавливает WordPress с нуля. Для остальных это не так актуально, но если всё-таки решите выполнить данную операцию, то нелишним будет сделать бэкап базы.
Комментариев: 30
Максим, а не трудно вам будет написать про то, как правильно бэкапить базу данных вордпресса и плагинов через Экспорт phpMyAdmin? там всегда столько разных опций, поэтому что было бы универсальным средством выбора?
заранее спасибо!
Спасибо, Макс, так и делал раньше ))
Поддерживаю iSynth. Думаю, что данный вопрос интересен многим пользователям.
и я так раньше делал и писал в одном из комментов об этом...
НО есть, имхо, еще один нюанс. Как-то компания Агава решила перенести мой хост на другой сервер, непредупредив, кстати говоря, в процессе переноса кодировка сбилась.
Да от кривык рук хостера никто не защищен. Совсем свежий пример с мастерхостом. Такое впечатление, что там одни дауны работают. Вчера меняли опять свою MySQL. Так базы, где явно указана utf-8 эти идиоты взяли и прописали как cp1251. :eek: Естественно, что все тексы оказались испорчены... :evil:
Еще пример - у меня один из блогов работает на "странной" базе. Везде указано, что кодировка каждой таблицы utf-8, а в самом низу, как бы под общей чертой уже cp1251 стоит!
Блин, откуда в мастерхосте берут админов? Объявляют конкурс даунов? Вот изменили базу - кодировку должна быть utf-8, они сделали cp1251. Ежику понятно, что нужно взять старый бэкап и из него восстановить базу в нормальной кодировке. Что делают эти идиоты? Они берут прописывают в wp-settings.php тупо в самый конец mysql_query("SET NAMES cp1251"); :eek: Нет слов, одни маты...
А чего Вы так возмущаетесь, Максим? Мне они за 2 недели письмо прислали. Предупредили о модернизации и дали ссылку на текст, где указаны расхождения и особенности, которые могут возникнуть. Я на следующий, после переноса день, просто в
wp-config.phpWordpressa переписал две строчки вот так:define('DB_CHARSET', 'cp1251'); # кодировка базы данных: utf8 или cp1251define('DB_COLLATE', 'cp1251_general_ci'); # кодировка, в которой хранятся данные: utf8_general_ci или cp1251_general_ci
И все. Никаких проблем.
Я вам объясню в чем проблема.
В базе данных тексты сохранились в utf-8. Для таблиц была указана именно эта кодировка. Все работает замечательно. Теперь эти умники ставят кодировку cp1251, но тексты, как и прежде хранятся в utf-8. То есть уже явное расхождение. В конце-концов загляните в phpMyAdmin и убедитесь, что тексты у вас нечитабельны.
Я прекрасно понимаю, что у меня, например, сейчас происходит двойная перекодировка. И, если честно, собирался им написать письмо с вопросм: не увеличивает ли это нагрузку и можно ли отключить их перекодировку, для того, что я отключил в свою в скрипте.
Но я не об этом. А о том, как Вы пишите: "дауны" и "тексты испорчены".
Понятно, что все "Ваши" Вордпрессовцы, которые на Мастерхосте (и я в том числе), оказались в ситуации: utf8 -> cp1251 -> cp1251 -> utf8. Вместо того, чтобы сразу из скрипта в базу: utf8 -> utf8
Ну хотите, напишите им сами письмо. Можно это безобразие убрать или нет? Чего раздражаться-то? У них же не только я и Вы
Успехов Вам и благоразумия.
Понимаете, Александр, все дело в том, что хостинг, который позиционирует себя как чуть ли не лучший в рунете, не может нанять квалифицированный персонал. Вот вы согласны с тем, что вам испортили базу. А не приходит ли вам в голову, что это может аукнуться в будущем. Вот вы добавите одну запись и половина текста окажется в одной кодировке, а другая в другой. Потом, когда вы будете делать бэкап, вы просто не сможете нормально восстановить свои тексты. Или как в таком случае будет работать сортировка, поиск? И обратите внимание, что речь не идет от чем-то экстраординарном: все эти проблемы возникли из-за непродуманности действий админов. Или, что скорее всего, их крайне низкой квалификации.
Внесу поправочку (хотя, может Вы именно это и имели ввиду): ставят не "кодировку", а "перекодировку".
Подробности от Мастерхост-а: "Переход на PHP5+MySQL5"
Это Вы сказали. Я так не считаю. Тексты сохранились, поиск работает. Новые публикации и комментарии функционируют как и прежде. И все это из-за двойного перекодирования. Т.е. мои тексты и комментарии так и продолжают извлекаться как utf8, так и сохраняться в базе в кодировке utf8.
Не вижу смысла далее обсуждать квалификацию персонала Мастерхост-а. И у меня нет цели переубеждать Вас.
Просто мне казалось, что Вы спосбны смотреть на проблемы объективно, а не эмоционально.
Успехов Вам.
отличная дискуссия, заставившая еще раз проверить настройки на "своем" хосте!
вот что предстало взгляду:
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
подскажите, все ли правильно?
Ну я тоже особо и не горю желанием кого-то убеждать. В конце концов, если вас устраивает такая ситуация, то вы и пользуетесь таким хостингом и платите за него своими деньгами. Я правда так и не понял, что такое «двойное перекодирования» и если у вас используется приведенная схема, то как вообще тексты могут быть корректными? Мой опыт подсказывает, что не всё благополучно в вашей базе. Ну тут уж вам решать...
В копилку некомпетентности админов мастерхоста я могу добавить еще и попытку прописать вызов SET NAMES cp1251 в wp-settings.php. Я понимаю, что они в WordPress'е ничего не соображают, но почему бы тогда не обратиться к файлу wp-config.php? То есть вместо того, чтобы по нормальному исправить базу, админ лезет в первый попавшийся файл и прописывает строчку из своего фака.
Теперь опишу ситуацию для простого клиента, который вообще в этом ничего не смыслит. Прежде всего следует отметить, что данный запрос уже используется в WordPress, но вот только в кодировке блога (utf-8). Поэтому часть запросов может отдаваться в нормальном виде (например тексты), а вот остальные, например опции, уже в покоцанной. Клиент, ничего не зная, что мастерхост самостоятельно и без его ведома исправил какие-то файлы «движка», естественно пишет в службу поддержки и получает ответ, типа того, что у нас все нормально, эта ошибка в ваших скриптах и посылает по приведенной вами ссылке (я её убил). :mrgreen:
2iSynth:
Да именно об этом я и пишу. Нужно поменять кодировку базы на utf8_general_ci
Максим... про убранную ссылку у меня просто нет слов. Не ужели Вы решили, что FAQ - это реклама? :smile:
еще раз убедился что хостинги зло. на самом деле чем думаю админы того же мастерхоста...почему я у себя на сервере могу создать любую базу с любой кодировкой и все работает нормально, хотя также использую " PHP5+MySQL5". Кстати я вроде уже писал, но повторю что когда в одной базе там пытался сменить кодировку на утф8 и обратно на 1251 реально ничего вообщене происходило с данными. они всегда на самом деле были в кодировке 1251 независимо от того что было в wp-config и показывалось в collate в phpmyadmin. заливал базу из дампа, сохраненного в обоих кодировках но при заливке утф-8 получались небольшие глюки
Я на новой инсталации WP всегда плагином UTF-8 Database Converter по базе «прохожусь». Я тут его уже один раз рекламировала
Очень мне нравится простотой и удобством. Кнопка нажал — и готово.
Александр М.
Странно, как это у Вас поиск корректно работает :/ И вообще, что Вы мастерхост так рьяно защищаете? Работаете там что ли?
Вообще?
Хоть я и не защищаю, а пытаюсь понять причину столь бурного негодования Максима, но в любом случае: надеюсь Вы не считаете возможным запретить высказать мне мою личную точку зрения и также надеюсь, Вы не против того что мне интересно понять объективную причину таких горячих эпитетов?
Не там а с ними.Александр М.,
так разве кто запрещает высказываться? Где я что такого сказала, что Вы углядели столько грозные намерения в моих словах?
Когда с чем-нибудь намаешься зазря или не по своей вине, вот тогда обычно и появляется бурное негодование.
В общем, блажен не ведающий
что то я из комментариев выше не понял, так все таки должна быть utf8_unicode_ci или utf8_general_ci?
utf8_general_ci
да, уже понял, спасибо.
вот еще может кому интересно будет:
http://codex.wordpress.org/Converting_Database_Character_Sets
Спасибо Макс!
Кодировка в ВП - больная тема и уже долго приходится с этим иметь дело. Спасибо что публикуешь актуальные новые материалы по этой теме.
Чисто теоретически - возомжно написать SQL команду, которая автоматизировала-бы этот процесс смены кодировки?
Петров Николай, этот плагин не подойдет?
Спасибо sonika за наводку!
To Максим: насчет кодировки - у меня на американском хостинге (dreamhost) по умолчанию стоит английский ВП, и выполнение инструкций, написанных в этой статье не приводит к желаемому результату. Однако скачанная оригинальная версия wordpress-russia.org + описанные выше инструкции наконец-таки дали свои плоды.
Да, и спасибо за информацию о том что нужна именно general а не unicode, долго не мог понять какую лучше использовать.
у меня установлен utf wordpress на 1251 хостинг. подскажите, как перевести его тоже в 1251, включая таблицы ?
меня мой хостер так же поставил в ситуацию (( там аж 2 блога на ВП
даже не могу теперь зайти в админ панель - дата бейс конвертер только из админки ж можно запустить видимо ? он переконвертит из cp1251_general_ci в utf полностью внутри все таблицы ?
wp-config пробовал менять по разному, ничего не помогает, когда текст становится читаемым, но названия разделов блога всё равно нечитаемые
что то не могу кодировку сменить, прописываю как сказал, но при просмотре сайта опять нужно менять кодировку
Друзья, сама промучилась с этими кодировками, перечитала кучу всяких статей, сообщений на форумах и т.п. Как я понимаю, кракозябры при переносе ооочень распространенная проблема! Можно конечно чахнуть над базами данных не один день, править их, отправлять sql запросы и т.п. Но все гениальное действительно просто) Все, что вам нужно сделать, чтобы решить все проблемы - это перенести все файлы на новый хостинг, создать абсолютно новую базу данных, установить за 5 мин вордпресс 2.7 иии... там есть замечательная функция в разделе "инструменты" импорт данных (конечно же вам надо будет сделать перед этим экспорт со старого сайта, но там уже все понятно! главное, чтобы как на старом, так и на новом сайте стояли самые последние версии вордпресс! полный автомат) и тогда у вас все аккуратненько так перетащится без кракозябр и прочих чудовищ на нове место)) ура!