我的问题与这里发现的几乎一模一样
MySQL - 1300 - 更新时无效的 utf8 字符串
没有提出解决方案,并且该人的帮助(创建临时表)似乎没有帮助。这是我正在使用的选择语句:
SELECT
CONVERT(line_1 USING utf8mb4),
CONVERT(line_1 USING latin1),
HEX(line_1)
FROM address
WHERE ((CAST(CONVERT(line_1 USING latin1) AS CHAR)) <> (CAST(line_1 AS CHAR)))
AND CONVERT(line_1 USING utf8mb4) IS NULL;
+-------------------------------+------------------------------+----------------------------------------------------+
| CONVERT(line_1 USING utf8mb4) | CONVERT(line_1 USING latin1) | hex(line_1) |
+-------------------------------+------------------------------+----------------------------------------------------+
| NULL | Högbergsgatan 97 | 48F6676265726773676174616E203937 |
| NULL | Zücherstrasse 161 | 5AFC636865727374726173736520313631 |
| NULL | 2275, Rue de l'Université | 323237352C20527565206465206C27556E69766572736974E9 |
| NULL | Högbergsgatan 97 | 48F6676265726773676174616E203937 |
+-------------------------------+------------------------------+----------------------------------------------------+
当我尝试运行以下更新命令时,我得到:
UPDATE address
SET line_1 = CONVERT(CAST(CONVERT(line_1 USING latin1) AS CHAR) USING utf8mb4)
WHERE (CAST(CONVERT(line_1 USING latin1) AS CHAR) <> CAST(line_1 AS CHAR))
AND CONVERT(line_1 USING utf8mb4) IS NULL;
ERROR 1300 (HY000): Invalid utf8mb4 character string: 'F66762'
我尝试通过以下方式设置线路,都产生相同的错误:
SET line_1 = CAST(CONVERT(line_1 USING latin1) AS CHAR)
SET line_1 = CONVERT(line_1 USING latin1)
我还查看了http://jonisalonen.com/2012/fixing-doubly-utf-8-encoded-text-in-mysql/看看是否可能是双重编码问题,但这些都不起作用,我一直得到相同的字符串错误。
此外,我查看了https://mathiasbynens.be/notes/mysql-utf8mb4以帮助完成转换步骤,但 utf8mb4 和 utf8 导致完全相同的问题。(起初我认为这是一个 utf8 的东西,所以我切换到了 utf8mb4,当我仍然遇到同样的问题时,我知道有一个更深层次的问题)
如您所见,正在发生一些奇怪的事情。查看我的 show create address 表,我可以验证字符集是否设置正确:
SHOW CREATE TABLE address;
| address | CREATE TABLE `address` (
`addressid` bigint(20) NOT NULL AUTO_INCREMENT,
`addressuuid` char(32) COLLATE utf8mb4_unicode_ci NOT NULL,
`line_1` blob,
PRIMARY KEY (`addressid`)
) ENGINE=InnoDB AUTO_INCREMENT=48970 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='All potential addresses' |
此外,您可以在我的实例中看到我的字符变量是正确的:
mysql> show variables like 'char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8mb4 |
| character_set_server | utf8mb4 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
8 rows in set (0.00 sec)
我怎么到这里了
因此,提供有关该问题的一些背景信息可能会有所帮助,以防万一它是导致问题的背景。
我有一个最初设置为 latin1 编码所有内容的数据库。然后我运行以下代码:
SET NAMES 'latin1';
/* We must change things to blob and then back again */
ALTER TABLE `address` CHANGE line_1 line_1 BLOB;
ALTER TABLE `address` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `address` CHANGE line_1 line_1 VARCHAR(64);
切换到 blob 然后返回到 varchar 的原因是正常的推荐过程。(www.percona.com/blog/2013/10/16/utf8-data-on-latin1-tables-converting-to-utf8-without-downtime-or-double-encoding/)
让我知道这是否有帮助,以及是否可以提供更多信息。我使用的是 MySQL 5.6,所以理论上它应该可以更好地处理事情,但谁知道呢。由于只有 4 行,我可以手动更新每一行,但理论上存在更大的潜在问题,而且由于我实际上还有很多列要查看,所以最好确保我有一个实用的方法来处理这些情况,以防我得到很多行的东西。