Изначально пост хотел озаглавить «о кроказябрах в сотый раз», но решил обойтись более официозной формулировкой, хотя, быть может, первый вариант более отражает суть, т.к. все эти вещи описаны уже много раз, но всё равно с ними периодически возникают проблемы.
Почему-то, в очередной раз создавая БД в mysql, в результате на веб-морде получаю «кракозябры». Казалось бы, 2013й год, ан нет, высокомерные вавилоняне, не могли башенку поскромней построить — был бы один язык на всех и никаких проблем с кодировками. Ну, что было, то было, а БД рекомендую создавать вот так (если конечно вам нужна кодировка utf8):
| 1 | CREATE DATABASE <dbname> CHARACTER SET utf8 COLLATE utf8_unicode_ci; |
Хотя, раз на раз не приходится, другие БД и без этого обходились. Вероятно, ORM django в этом плане более хитёр, умён и прозорлив — создаёт таблички сразу с юникодом, в отличие от sqlalchemy. По крайней мере, мои наблюдения таковы, что для django-проектов не было проблем с кодировкой, а вот с sqlalchemy — опять наткнулся (или это на самом деле проблемы с моей памятью).
Если это не решает вашей проблемы, то смотрите какую кодировку использует клиент при подключении, в какую перекодирует, какую отдаёт web-сервер или в какой кодировке попадают сами данные в БД.
А зачем нужен COLLATE?
Если не указать COLLATE, то будет использоваться дефолтное значение. Само значение указывает, грубо говоря, на порядок букв для сравнения при сортировке. utf8_general_ci работает немного скорее, но менее точно, чем utf8_unicode_ci. utf8_bin сравнивает символы в бинарном формате. Есть ещё language-specific значения с доп. правилами, можете попробовать использовать utf8_russian_ci.
Вообще, некоторые люди рекомендуют использовать utf8_unicode_ci, если вы точно не знаете зачем вам другой вариант (поправил пост).
P.S. Где-то могу быть неточным, т.к. в теме пришлось самому только что разбираться более подробно, но примерно так оно работает.