我的问题与此处的问题几乎完全相同
MySQL - 1300 - Invalid utf8 character string on update
没有提供任何解决方案,并且该人的帮助(创建临时表)似乎没有帮助。这是我正在使用的select语句:
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导致了完全相同的问题。 (起初我觉得这是一件好事,所以我切换到utf8mb4,当我仍然遇到同样的问题时,我知道有更深层次的问题)
正如你所看到的,正在发生一些奇怪的事情。查看我的show create address表,我可以验证是否正确设置了charset:
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行我可以手动更新每一行,但理论上存在更大的潜在问题,因为我确实有更多的列需要通过,所以确保我有一个功能方法是很好的处理这些案件以防万一我得到了很多行。
答案 0 :(得分:0)
由于line_1
是blob而不是文本字段,因此MySQL无法控制其中的“字符”,并且不关心它是否是非文本信息(例如JPG)。在您给出的示例中,您在该字段中有latin1文本(例如,ö的十六进制F6)。因此,CONVERT(line_1 USING latin1)
工作得很好。
我不明白你的目标。您是否尝试将BLOB读作TEXT?如果是这样,和如果所有非ascii字符都被编码为latin1,那么CONVERT就是答案。
如果你的目标是别的,那就让我们从那里接近它。
它不是“双重编码”,因此它们都不起作用。
ALTER TABLE
address
CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
执行SHOW CREATE TABLE address
并检查line_1
的字符集。