准备好的查询和常规查询之间的Erlang Emysql编码差异

Question

我写了一个关于 emysql 编码的问题，得到了正确的答案here。 答案指出了另一个问题...

我正在尝试将 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]).

我正在检索 Mojibake。 编辑使用正确的术语

我正在联系：

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

不幸的是，我不能使用 utf8，因为以前的软件使用数据库并以这种方式存储表情符号，如果我使用 utf8，它将适用于新系统，但不适用于旧系统插入的行。

编辑：

我真的很想使用prepared statement，这样可以有效地防止SQL注入。

Answer 1

---

编辑：应该在 253b7f94f9b04526e6868d7b693e6e9ee41de374 中修复。感谢您的反馈。 https://github.com/Eonblast/Emysql/commit/253b7f94f9b04526e6868d7b693e6e9ee41de374

---

我相信这是 Emysql 中的一个错误，我想我已经修复了它。仍在进行单元测试，所以一切都说得通。我会在它发布到 github 时通知你。

我为此开了一个问题：https://github.com/Eonblast/Emysql/issues/24

本质上，您是在欺骗驱动程序和数据库，因为您打开了与 latin-1 的连接，但数据库是 utf-8。然后你就被自动转换绊倒了。

不过，我认为你是对的，驱动程序应该尊重你将连接设置为 latin-1 而不是自动转换为 utf-8 的魔法。如果你在 github 上阅读 Eonblast/Emysql 的 issue #14，你会发现我一直怀疑自动转换是个坏主意。

但是，仅仅因为转换的单元测试现在被炸毁了四倍（并提出了一些相当无趣但令人难以置信的边缘问题，我无法理解），我认为欺骗数据库你这样做的方式同样是个坏主意。如果可以的话，你应该清理它而不是依靠中间的机制来保持。 MySQL 中有多个级别发生转换。如您所知，您可以将连接、数据库以及表设置为字符集。这是产生错误的好方法。你能描述为什么你不能吗？因为您无法控制并且必须对编码视而不见？我想知道是否有一个真实的案例，没有这个黑客你就活不下去。

不管怎样，您对 latin-1 连接设置的抱怨可能表明了消除 Emysql 中字符转换中所有或大部分猜测的方法。非常感谢，我希望今天晚些时候能为您提供解决方案。

亨宁

Answer 2

只需将您的表格转换为 UTF-8：

ALTER TABLE Users CONVERT TO CHARACTER SET utf8;

然后您可以将 utf-8 用于新数据，旧数据也将转换为 UTF-8。