utf8_decode整条SQL语句可以避免utf-8 / utf8mb4问题吗？

Question

我有一个站点，它接受来自用户的基于表单的输入，并存储到mysql(i)数据库中。99%的用户来自美国。

如果用户在移动设备上，并决定在表单字段中使用表情符号很有趣，则结果SQL将在尝试更新或插入时导致失败。这是因为表情符号在utf-8之外，因此UX和DB之间的编码不匹配。我相信我理解根本的问题。

我在MySQL5.5上，所以我实际上可以支持utf8mb4 char集--但我还需要一段时间才能了解到这一点。

同时，只执行此操作(在PHP中)是否可以/安全：

$sql = "INSERT INTO my_table ... *long insert statement across two dozen rows*";
$sql = utf8_decode($sql);
$db->sql_query($sql);

所以-只需强制整个SQL语句到utf-8？我意识到表情符号和其他一些字符可能被转换成"?“--但只要语句本身没有中断，或者我不会丢失用户的正常文本输入，我就不会介意。

在我将表的模式转换为使用utf8mb4之前，这个想法作为临时修复有什么问题吗？

编辑:从数据库返回的错误如下所示：

"Incorrect string value: '\xF0\x9F\x99\x8A...' for column..."

Answer 1

一些事实：

• 在Unicode中，许多表情都在BMP (基本多语种平面)之上，即在代码点U+FFFF之上。
• MySQL的utf8字符集只能表示BMP，它实际上不是完整的UTF-8 (yay MySQL)
• 对于完整的Unicode支持，MySQL有utf8mb4
• 当尝试将BMP以上的字符存储在utf8字符集列中时，不应该出现实际错误，MySQL只会丢弃不受支持的字符(yay静默数据损坏)。
• utf8_decode 并不“将所有内容都强制到UTF-8"，而是将字符串从UTF-8编码转换为ISO-8859-1 (”拉丁文-1“)编码；这将丢弃更多的字符，而不仅仅是符号符号。

所以在我看来，如果你在某个时候遇到了一个实际的错误，你就会遇到其他一些潜在的问题。也许你认为你在和你的UTF-8数据库说话，而实际上你不是。您需要通过mysqli_set_charset设置连接字符集。

“筛选出”您的数据库不支持的字符应该已经发生了，MySQL将简单地丢弃这些字符。如果要在PHP中手动执行此操作，可以这样做以筛选出U+FFFF上面的所有字符：

$string = preg_replace_callback('/./u', function (array $m) {
    return strlen($m[0]) > 4 ? null : $m[0];
}, $string);

总体上:支持utf8mb4大约需要两分钟。您只需要将表/列字符集设置为utf8mb4，并对mysqli连接执行相同的操作。如果您随后将实际的UTF-8数据从您的PHP应用程序发送到您的数据库，那么您将很好地存储表情符号。