如何修复"不正确的字符串值"错误？

Question

在注意到由于错误的字符串值错误导致应用程序倾向于丢弃随机电子邮件之后,我通过并切换了许多文本列以使用utf8列字符集和默认列collat​​e(utf8_general_ci)以便它接受它们.这解决了大多数错误,并使应用程序在遇到非拉丁语电子邮件时也停止获取sql错误.

尽管如此,一些电子邮件仍然导致程序命中错误的字符串值错误: (Incorrect string value: '\xE4\xC5\xCC\xC9\xD3\xD8...' for column 'contents' at row 1)

contents列是一个MEDIUMTEXTdatatybe,它使用utf8列charset和utf8_general_ci列collat​​e.我没有可以在此列中切换的标记.

请记住,除非绝对必要,否则我不想触摸甚至查看应用程序源代码:

• 是什么导致了这个错误？(是的,我知道电子邮件中充满了随机垃圾,但我认为utf8会非常宽松)
• 我该如何解决？
• 这种修复的可能影响是什么？

我考虑过的一件事是在打开二进制标志的情况下切换到utf8 varchar([某些大数字]),但我对MySQL很不熟悉,并且不知道这样的修复是否有意义.

Answer 1

我不建议Richies回答,因为你搞砸了数据库里面的数据.你不会解决你的问题,但试图"隐藏"它,而不能用垃圾数据执行必要的数据库操作.

如果您遇到此错误,您发送的数据不是UTF-8编码,或者您的连接不是UTF-8.首先,验证数据源(文件,...)确实是UTF-8.

然后,检查数据库连接,连接后应该这样做:

SET NAMES 'utf8';
SET CHARACTER SET utf8;

接下来,验证存储数据的表是否具有utf8字符集:

SELECT
  `tables`.`TABLE_NAME`,
  `collations`.`character_set_name`
FROM
  `information_schema`.`TABLES` AS `tables`,
  `information_schema`.`COLLATION_CHARACTER_SET_APPLICABILITY` AS `collations`
WHERE
  `tables`.`table_schema` = DATABASE()
  AND `collations`.`collation_name` = `tables`.`table_collation`
;

最后,检查您的数据库设置:

mysql> show variables like '%colla%';
mysql> show variables like '%charac%';

如果源,传输和目的地是UTF-8,你的问题就消失了;)

Answer 2

MySQL的utf-8类型实际上并不适合utf-8 - 它每个字符最多只使用三个字节,并且仅支持基本多语言平面(即没有表情符号,没有星体平面等).

如果需要存储更高Unicode平面的值,则需要utf8mb4编码.

Answer 3

表和字段的编码错误; 但是,您可以将它们转换为UTF-8.

ALTER TABLE logtest CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

ALTER TABLE logtest DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

ALTER TABLE logtest CHANGE title title VARCHAR(100) CHARACTER SET utf8 COLLATE utf8_general_ci;

Answer 4

"\xE4\xC5\xCC\xC9\xD3\xD8"是无效的UTF-8.使用Python测试:

>>> "\xE4\xC5\xCC\xC9\xD3\xD8".decode("utf-8")
...
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-2: invalid data

如果您正在寻找一种避免解码数据库中错误的方法,那么cp1252编码(又名"Windows-1252"又名"Windows Western European")是最宽松的编码 - 每个字节值都是有效的代码点.

当然,它不会再理解真正的UTF-8,也不会理解任何其他非cp1252编码,但听起来你并不太关心它？

Answer 5

我今天通过将列更改为'LONGBLOB'类型来解决此问题,该类型存储原始字节而不是UTF-8字符.

这样做的唯一缺点是你必须自己处理编码.如果您的应用程序的一个客户端使用UTF-8编码而另一个客户端使用CP1252,则可能会使用不正确的字符发送您的电子邮件.为避免这种情况,请始终在所有应用程序中使用相同的编码(例如UTF-8).

有关TEXT/LONGTEXT和BLOB/LONGBLOB之间差异的更多详细信息,请参阅此页面http://dev.mysql.com/doc/refman/5.0/en/blob.html.网上还有许多其他论点在讨论这两个问题.

Answer 6

通常,当您将字符串插入具有不兼容的编码/排序规则的列时会发生这种情况.

当我有TRIGGER时出现这个错误,TRIGGER由于某种原因继承了服务器的排序规则.并且mysql的默认值是(至少在Ubuntu上)latin-1和swedish collat​​ion.即使我有数据库和所有表设置为UTF-8,我还没有设置my.cnf:

/etc/mysql/my.cnf:

[mysqld]
character-set-server=utf8
default-character-set=utf8

这必须用utf8-*列出所有触发器:

select TRIGGER_SCHEMA, TRIGGER_NAME, CHARACTER_SET_CLIENT, COLLATION_CONNECTION, DATABASE_COLLATION from information_schema.TRIGGERS

并且由此列出的一些变量也应该具有utf-8-*(没有latin-1或其他编码):

show variables like 'char%';

Answer 7

首先检查default_character_set_name是否为utf8.

SELECT default_character_set_name FROM information_schema.SCHEMATA S WHERE schema_name = "DBNAME";

如果结果不是utf8,则必须转换数据库.首先,您必须保存转储.

要将指定数据库中的所有表的字符集编码更改为UTF-8,请在命令行中键入以下命令.将DBNAME替换为数据库名称:

mysql --database=DBNAME -B -N -e "SHOW TABLES" | awk '{print "SET foreign_key_checks = 0; ALTER TABLE", $1, "CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci; SET foreign_key_checks = 1; "}' | mysql --database=DBNAME

要将数据库本身的字符集编码更改为UTF-8,请在mysql >提示符下键入以下命令.将DBNAME替换为数据库名称:

ALTER DATABASE DBNAME CHARACTER SET utf8 COLLATE utf8_general_ci;

您现在可以重试将utf8字符写入数据库.当我尝试将200000行csv文件上传到我的数据库时,此解决方案可以帮助我.

Answer 8

虽然您的排序规则设置为utf8_general_ci,但我怀疑数据库,表格甚至列的字符编码可能不同.

ALTER TABLE tabale_name MODIFY COLUMN column_name VARCHAR(255)  
CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;

Answer 9

该错误意味着您的字符串编码不正确（例如，您尝试将 ISO-8859-1 编码字符串输入到 UTF-8 编码列中），或者该列不支持您尝试输入的数据。

实际上，后一个问题是由 MySQL UTF-8 实现引起的，该实现仅支持以 UTF-8 表示时需要 1-3 个字节的 UNICODE 字符。尝试通过 JDBC 将 UTF-8 插入 MySQL 时，请参阅“不正确的字符串值”？详情。诀窍是使用列类型utf8mb4而不是类型utf8，尽管名称实际上并不支持所有 UTF-8。前一种类型是用于所有 UTF-8 字符串的正确类型。

Answer 10

我遇到了类似的错误 ( Incorrect string value: '\xD0\xBE\xDO\xB2. ...' for 'content' at row 1)。我试图将列的字符集更改为utf8mb4，之后错误已更改为'Data too long for column 'content' at row 1'.
原来，mysql 向我显示了错误的错误。我将列的字符集转回，并将列的utf8类型更改为MEDIUMTEXT. 之后，错误消失了。
我希望它可以帮助某人。
顺便说一句，MariaDB 在相同的情况下（我在那里测试了相同的 INSERT）只是剪切了一个文本而没有错误。