0

在打击垃圾邮件的过程中，我发现一些垃圾评论存储在没有任何内容的情况下......

在尝试隔离问题后，这是我在将类似的评论与 MySQL 数据库一起保存到文件后发现的内容......

这是（由于未知输入编码的十六进制）评论前几个“字符”的样子：

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中的错误，还是什么？

谢谢

4

1 回答 1

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，您的查询是十六进制文字，而不是错误编码的文本。

于 2013-04-03T17:40:36.760 回答