![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
От жеж вуду
Решил разобраться с внутренним устройством баг-трекера на предмет его миграции с "автоматически инсталлированного под виндой" на "поставленный вручную на дебиане".
Обнаружил, что автоматический инсталлятор под виндой создал базу в mysql с кодировкой latin1, а рубирельсовое приложение при этом работает в кодировке utf8. Дамп базы вроде в utf8 получается, если поставить mysqldump кодировку latin1, но подгрузить этот дамп в utf8 базу у меня не выходит.
PS: фак мой мозг. Поставил для базы данных с default character set utf8 в конфиге рельсов encoding: latin1 - кодировка исправилась. Хер знает, что они там делают.
PPS: замена всех latin1 на utf8 в дампе, установка --default-character-set=utf8 при импорте таки помогла - новая база стала в правильной кодировке.
Обнаружил, что автоматический инсталлятор под виндой создал базу в mysql с кодировкой latin1, а рубирельсовое приложение при этом работает в кодировке utf8. Дамп базы вроде в utf8 получается, если поставить mysqldump кодировку latin1, но подгрузить этот дамп в utf8 базу у меня не выходит.
PS: фак мой мозг. Поставил для базы данных с default character set utf8 в конфиге рельсов encoding: latin1 - кодировка исправилась. Хер знает, что они там делают.
PPS: замена всех latin1 на utf8 в дампе, установка --default-character-set=utf8 при импорте таки помогла - новая база стала в правильной кодировке.
no subject
- кодировка, в которой отдаётся аппликухе (SET NAMES)
- и кодировка в которой отдаёт апликуха.
Потёряться тут конечно можно, но лучше по возможности держать всё в одной кодировке :)
Гм, как то использовал команду для конвертации таблицы из одной кодировки в другую. ИМХО более правильный способ.
no subject