Сегодня я хочу рассказать об одних граблях на которые сам недавно наступил.
Даже немного стыдно признаваться, но я столкнулся с проблемой кодировок в базе данных и какое-то время вообще не мог понять, в чём дело.
А ситуация была такая. Я написал статью «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!
