我写了一个关于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，它将在新系统上运行，但不适用于旧系统插入的行。
编辑：
我真的很想使用准备好的语句，这样可以有效防止SQL注入。
最佳答案
编辑：应固定在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上阅读第14期问题，您会发现我一直怀疑自动转换是个坏主意。
但是，仅因为转换的单元测试现在增加了四分之一（并引起了一些相当有趣的问题，但令人毛骨悚然的边缘问题，我还是无法解决），所以我想以这种方式欺骗数据库这样做也是一个坏主意。如果可以的话，您应该清理掉它，而不要依赖它们之间的机制。 MySQL中有多个级别可以进行转换。如您所知，您可以将连接，数据库以及表设置为字符集。这是产生错误的好方法。你能描述为什么你不能吗？因为您无法控制并且必须对编码盲目行动？我想知道是否存在没有这种黑客就无法生存的真实案例。
无论如何，您对与latin-1的连接设置的抱怨可能表明了消除Emysql中字符转换中所有或大部分猜测的方法。非常感谢，我希望今天晚些时候能为您提供解决方案。
亨宁