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

Владимир | | MySQL.

db_restore

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

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

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

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

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

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

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

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

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

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

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

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

SET CHARACTER SET utf8;

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

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

Happy coding!

  • 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.

        Это уже вошло в привычку и не доставляет хлопот)

        • префиксы к таблицам для разных языков

          А если этот сайт — социальная сеть. И заранее не известно на каком языке пользователи будут текст писать. По-моему в этом случае вариант с префиксами не пройдет 😉

  • 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.

        Это уже вошло в привычку и не доставляет хлопот)

        • префиксы к таблицам для разных языков

          А если этот сайт — социальная сеть. И заранее не известно на каком языке пользователи будут текст писать. По-моему в этом случае вариант с префиксами не пройдет 😉

  • добавил ваш блог в закладки

  • добавил ваш блог в закладки

  • Big_Shark

    А если этот сайт — социальная сеть. И заранее не известно на каком языке пользователи будут текст писать. По-моему в этом случае вариант с префиксами не пройдет 😉

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

    • я ведь заранее знаю

      Конечно, но как только у посетителей появится возможность что-то писать, например, в комментариях, гостевой книге или отправлять сообщения через контактную форму, то могут возникнуть проблемы.
      В основном проблема касается похожих языков. Т.е. человек понимает текст, но ответить на том же языке ему сложно.

      • Big_Shark

        Вот тут я согласен.

  • Big_Shark

    А если этот сайт — социальная сеть. И заранее не известно на каком языке пользователи будут текст писать. По-моему в этом случае вариант с префиксами не пройдет 😉

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

    • я ведь заранее знаю

      Конечно, но как только у посетителей появится возможность что-то писать, например, в комментариях, гостевой книге или отправлять сообщения через контактную форму, то могут возникнуть проблемы.
      В основном проблема касается похожих языков. Т.е. человек понимает текст, но ответить на том же языке ему сложно.

      • Big_Shark

        Вот тут я согласен.

  • блог просто отпад!!!

  • блог просто отпад!!!

  • спасибо огромное автору и всем кто прокоментировал!!! наконец я в этом разобралсЯ!!!

  • спасибо огромное автору и всем кто прокоментировал!!! наконец я в этом разобралсЯ!!!

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

    Тоже сталкивался 🙂 Долго потом вьехать не мог в чем прикол 🙂

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

    Тоже сталкивался 🙂 Долго потом вьехать не мог в чем прикол 🙂

  • У меня такая же проблема была, неверно отражалась кодировка, вроде мелочи а убил 2 дня

  • У меня такая же проблема была, неверно отражалась кодировка, вроде мелочи а убил 2 дня

  • А если нету возможности использовать Крону, вручную постоянно это делать? Другого решения этой проблеммы нету?

  • А если нету возможности использовать Крону, вручную постоянно это делать? Другого решения этой проблеммы нету?

  • Отличное решение!

  • Отличное решение!

  • Kovalev

    Спасибо огромное!!!