mysqldump и кодировка

Andrey Ostanovsky написал(а) к Victor Sudakov в Sep 17 17:04:04 по местному времени:

Нello Victor!

09 Sep 17 09:03, you wrote to me:

VS> Я вот не знал, что можно таким образом поломать mysqldump, а
VS> оказывается можно.

Проблема (глобально) не в этом, а в том, что база, не зная в какой кодировке туда загрузили данные, может заниматься перекодировкой этого незнамо-чего основываясь на языковых опциях в разных местах. Раньше этим только оракл грешил, но после 4-какой-то версии и mysql сделал шаг вперед.

Например у нас сервер по-умолчанию в latin1 и грузим мы в него текст в кодировке windows-1251, если ничего не трогать - то в обратную сторону мы получаем вполне русский язык, а вот если, после загрузки данных, начать играться с кодировками - то на выходе будем получать кашу.

Andrey

--- GoldED+/BSD 1.1.5-b20070503

Alex Korchmar написал(а) к Andrey Ostanovsky в Sep 17 18:33:50 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Andrey Ostanovsky <Andrey.Ostanovsky@f1957.n5030.z2.fidonet.org> wrote:

AO> кодировке windows-1251, если ничего не трогать - то в обратную сторону мы
AO> получаем вполне русский язык, а вот если, после загрузки данных, начать
это пока кодировки - перестановочные. А как только попадается умник с utf8 -
чтоб ее изобретателей в аду черти кололи вилами непременно с отломанным
зубцом - так все превращается в вермишель.

ну а чего вы хотите, это ж оракл. В его собственной базе было интереснейшее
упражнение в виде перекодировки из unicode в unicode. ДА, у него в разных
версиях был несовместимый юникод.

правильный подход из современных разьве что у sqlite - ничего никогда никуда
не перекодировать, надеяться что в базе у тебя utf8, но никогда из этого
предположения выводов не делать, кроме collate, поэтому если он вдруг "invalid"
- то ничего, кроме collation , не ломается.


> Alex

--- ifmail v.2.15dev5.4