我写了一个关于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中字符转换中所有或大部分猜测的方法。非常感谢,我希望今天晚些时候能为您提供解决方案。
亨宁