Откат базы данных и проблема с кодировками

23 июня, 2009
db_restore

Сегодня я хочу рассказать об одних граблях на которые сам недавно наступил.

Даже немного стыдно признаваться, но я столкнулся с проблемой кодировок в базе данных и какое-то время вообще не мог понять, в чём дело.

А ситуация была такая. Я написал статью «jqGrid: редактирование табличных данных с помощью inline редакторов» и сделал демонстрационную страничку.

Для того, чтобы таблица не была пустой, я сделал дамп моей локальной базы и через phpMyAdmin залил его в базу на сервере.

При этом никаких проблем с кодировками не возникало вообще. Т.е. у меня везде была указана utf-8, она и использовалась.

Тут возникает обычная проблема.

Работать с таблицей может кто угодно, а вручную следить за тем, кто и что написал, у меня нет ни времени, ни желания.

Поэтому я создал задачу для Cron, которая периодически выполняет команду

  1. mysql –user=db_user –password=db_pass db_name < /path_to_dump_file/dump.sql

Т.е. просто восстанавливает базу из файла с дампом.

И через некоторое время я замечаю (точнее мне пишут в комментариях, спасибо Big_Shark), что часть записей в таблице отображается кракозябрами.

Поначалу я подумал, что дело в каком-то бразузере, но оказалось, что и в FireFox, и в Opera, и в Safari, и в IE никаких проблем с кодировками нет.

Да и в любом случае данные на сервер отправляются AJAX запросом, а в них всегда используется UTF-8.

Понял в чем дело я только после того как попытался на локальном компьютере восстановить базу из дампа (через командную строку). В общем, mysql нужно явно указывать кодировку.

Для этого в командную строку добавляем параметр --default_character_set=utf8

  1. mysql –user=db_user –password=db_pass –default_character_set=utf8 db_name < /path_to_dump_file/dump.sql

На локальном сервере этот параметр решил проблему, но на сервере хостера – нет.

Поэтому в начало дампа базы я добавил запрос

  1. SET CHARACTER SET utf8;

И он полностью решил проблему.

В общем, мораль у этой истории простая. Как только становишься слишком самоуверенным и перестаешь следить за мелочами, появляются проблемы ;)

Happy coding!

Понравилась статья? Подписывайтесь на продолжение rss link !

Или на мой твиттер twitter link

]]>

Добавьте эту страницу в google.com bobrdobr.ru del.icio.us technorati.com linkstore.ru news2.ru rumarkz.ru memori.ru moemesto.ru

]]>

Опубликовано в MySQL View Comments

]]>
  • Отличное решение!
  • А если нету возможности использовать Крону, вручную постоянно это делать? Другого решения этой проблеммы нету?
  • Почему нет? Можно использовать сервис вроде этого.
  • У меня такая же проблема была, неверно отражалась кодировка, вроде мелочи а убил 2 дня
  • Даже немного стыдно признаваться, но я столкнулся с проблемой кодировок в базе данных и какое-то время вообще не мог понять, в чём дело.


    Тоже сталкивался :) Долго потом вьехать не мог в чем прикол :)
  • спасибо огромное автору и всем кто прокоментировал!!! наконец я в этом разобралсЯ!!!
  • блог просто отпад!!!
  • Big_Shark
    А если этот сайт - социальная сеть. И заранее не известно на каком языке пользователи будут текст писать. По-моему в этом случае вариант с префиксами не пройдет ;)

    Вот тут уже да согласен) но я ведь заранее знаю буду ли я делать соц сеть или просто обычный сайт.
  • я ведь заранее знаю


    Конечно, но как только у посетителей появится возможность что-то писать, например, в комментариях, гостевой книге или отправлять сообщения через контактную форму, то могут возникнуть проблемы.
    В основном проблема касается похожих языков. Т.е. человек понимает текст, но ответить на том же языке ему сложно.
  • Big_Shark
    Вот тут я согласен.
  • добавил ваш блог в закладки
  • Big_Shark
    Хм
    У меня складывается такое впечатления что я один базу в CP_1251 храню)
    Может кто скажет к чему это может привести? И чем UTF лучше?
  • Если приложение не меняется, то проблем не будет.
    UTF позволяет хранить больше символов, т.е. латиницу, кириллицу, иероглифы и т.п. Но при этом все символы, кроме латинских занимают 2 байта (кириллица) или больше. Т.е. если есть большая русскоязычная база в cp_1251, то перекодировка в UTF-8 увеличит её размер, со всеми вытекающими последствиями.

    С другой стороны для многоязычных сайтов UTF-8 намного удобнее.
    И если будет использоваться AJAX, то на сервере придется перекодировать данные в запросах из UTF-8 в CP_1251.
  • Big_Shark
    Лучше всего при работе с многоязычными сайтами это делать разные префиксы к таблицам для разных языков.
    Типа:
    cms_ru_page
    cms_en_page
    И тд
    Таким образом мы избавляемся от избыточности данных.
    И можем устанавливать такие настройки которые нам нужны для данного языка.

    И если будет использоваться AJAX, то на сервере придется перекодировать данные в запросах из UTF-8 в CP_1251.

    Это уже вошло в привычку и не доставляет хлопот)
  • префиксы к таблицам для разных языков


    А если этот сайт - социальная сеть. И заранее не известно на каком языке пользователи будут текст писать. По-моему в этом случае вариант с префиксами не пройдет ;)
blog comments powered by Disqus ]]>