Erlang Emysql разница кодировки между подготовленным и обычным Query - PullRequest
Новая
       61

Erlang Emysql разница кодировки между подготовленным и обычным Query

0 голосов
/ 13 марта 2012

Я написал вопрос, который получил правильный ответ здесь о кодировке emysql. Ответ точно определить другой вопрос ...

Я пытаюсь сохранить iPhone смайликов в базе данных ...

Когда я делаю: 

Query = io_lib:format("UPDATE Users SET c=\"~s\" WHERE id=~B", [C, Id]),
emysql:execute(mydb, Query).

Все отлично работает ...

Но с: 

emysql:prepare(update_c, <<"UPDATE Users SET c=? WHERE id=?">>),
emysql:execute(mydb, update_c, [C, Id]).

Я возвращаю Моджибаке. ИЗМЕНЕНО ДЛЯ ИСПОЛЬЗОВАНИЯ ПРАВИЛЬНОГО СРОКА

Я соединяюсь с: 

 emysql:add_pool(my_db, 3, "login", "password", "db.mydomain.com", 3306, "MyTable", latin1)

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

EDIT:

Мне бы очень хотелось использовать подготовленный оператор, который бы эффективно предотвращал внедрение SQL.

Ответы [ 2 ]

2 голосов
/ 22 марта 2012

Редактировать: должно быть исправлено в 253b7f94f9b04526e6868d7b693e6e9ee41de374.Спасибо за отзыв.https://github.com/Eonblast/Emysql/commit/253b7f94f9b04526e6868d7b693e6e9ee41de374

Я считаю, что это ошибка в Emysql, и я думаю, что я ее исправил.Все еще работаю над юнит-тестами, так что все это имеет смысл.Я дам вам знать, когда он будет опубликован на github.

Я открыл для этого проблему: https://github.com/Eonblast/Emysql/issues/24

По сути, вы обманываете драйвер и базу данных, потому что открываете соединение слатиница-1, но база данных - это utf-8.Затем вы запутываетесь в автоматическом преобразовании.

Тем не менее, я думаю, что вы правы, что водитель должен уважать то, что вы установили соединение с latin-1, а не использовать магию автоматического преобразования в utf-8.Если вы прочитаете номер 14 в Eonblast / Emysql на github, вы обнаружите, что я всегда подозревал, что автоматическое преобразование было плохой идеей.

Однако, просто из-за того, что модульные тесты для преобразований теперь взрываютсяфактор четыре (и ставит некоторые довольно неинтересные, но ошеломляющие краевые проблемы, которые я не могу понять) Я думаю, обмануть базу данных, как вы делаете, - тоже плохая идея.Если вы можете, вы должны очистить это, а не полагаться на промежуточную механику, чтобы держать.В MySQL есть несколько уровней, где происходят преобразования.Как вы знаете, вы можете установить соединение, базу данных, а также таблицу для набора символов.Это отличный способ создавать ошибки.Можете ли вы описать, почему вы не могли?Потому что у вас нет контроля и вы должны действовать слепо для кодирования?Я хотел бы знать, есть ли реальный случай, когда вы не можете жить без этого взлома.

Несмотря на это, ваша жалоба на установку соединения с latin-1, вероятно, показала способ устранить все илибольшая часть догадок в преобразовании символов в Emysql.Это очень ценится, и я надеюсь, что сегодня у меня будет для вас решение.

Хеннинг

0 голосов
/ 19 марта 2012

Просто конвертируйте таблицу в UTF-8:

ALTER TABLE Users CONVERT TO CHARACTER SET utf8;

Тогда вы можете использовать utf-8 с новыми данными, и старые будут преобразованы в UTF-8, а также.

...