utf8_decode 整个 SQL 语句是否可以避免 utf-8 / utf8mb4 问题？

Question

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

如果用户使用移动设备并认为在其中一个表单字段中使用表情符号会很有趣，则结果 SQL 会在尝试 UPDATE 或 INSERT 时导致失败。这是由于表情符号在 utf-8 之外，因此用户体验和数据库之间的编码不匹配。我相信我了解潜在的问题。

我正在使用 mysql 5.5，所以我实际上可以支持 utf8mb4 字符集——但我还需要一段时间才能解决这个问题。

与此同时，是否 ok/safe 只是这样做（在 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
尝试在 utf8 字符集列中存储 BMP 上方的字符时应该没有实际错误，MySQL 将简单地丢弃不受支持的字符（yay 静默数据损坏)
utf8_decode 不会 "force everything to UTF-8"，而是将字符串从 UTF-8 编码转换为 ISO-8859-1 ("Latin-1" ）编码；这将丢弃比表情符号更多的字符

所以在我看来，如果您在某个时候抛出实际错误，那么您似乎还有其他潜在问题。也许您认为您正在使用 UTF-8 与您的数据库对话，而实际上并非如此。您需要通过 mysqli_set_charset.

设置您的 连接字符集

"Filtering out" 字符您的数据库不支持应该已经发生，MySQL 将简单地丢弃这些字符。如果你想在 PHP 中手动执行此操作，你可以这样做以过滤掉 U+FFFF 以上的所有字符：

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

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

Is it ok to utf8_decode entire SQL statement to avoid utf-8 / utf8mb4 issues?