在某些情况下，Mysql无法保存UTF字符串

Question

在垃圾邮件战斗期间，我发现存储了一些没有任何内容的垃圾评论...

在尝试隔离问题之后，这是我在将相似的注释与MySQL数据库一起保存到文件后发现的......

这是（HEX，因为未知的输入编码）前几个“字符”看起来像什么评论：

D1EA E0F7 E0F2 FC20 EFEE EFF3 EBFF F0ED FBE5 20EF F0EE E3F0 E0EC ECFB

执行INSERT INTO test VALUES (0xD1EAE0F7E0F2FC20EFEEEFF3EBFFF0EDFBE520EFF0EEE3F0E0ECECFB21),(0x21D1EAE0F7E0F2FC20EFEEEFF3EBFFF0EDFBE520EFF0EEE3F0E0ECECFB), (0x21)测试后，mysql表（utf-8）包含3行，第一行没有任何文本，第二行和第三行包含单个字符“！”作为文本...（注意，“！”的21个十六进制代码也在第一个条目的末尾，但它没有被保存）。 （latin1编码为每个字节保存了一些无用的文本替换，但这篇文章不是关于它的）

当然，D1EA（D = 1101 0001后面应该跟一个10xxxxxx字节，而不是1110xxxx）是无效的UTF-8字符，但像数据库服务器这样强大的系统应该能够处理它......

我的猜测是，Mysql（版本5.1.66-0 + squeeze1）不应选择何时保存数据，何时不选择，即使它不是有效的UTF-8编码字符...或者至少，它应该当声明不决定不存储数据时，声明查询是否成功！

是mysql中的bug，还是什么？

由于

Answer 1

编码是Windows-1251，并解码为

Скачать популярные программы
//"Download popular software" google translated

在对代码执行任何操作之前，您应该拒绝代码中的非UTF8输入。

if( !mb_check_encoding($input, "UTF-8") ) {
    header("HTTP/1.1 400 Bad Request");
    die("Invalid encoding");
}

FTR，您的查询是十六进制文字，而不是错误编码的文本。