Mysql 如何修复“字符串值不正确”错误？

在注意到一个应用程序由于错误的字符串值而倾向于丢弃随机电子邮件后，我尝试并切换了许多文本列，以使用utf8列字符集和默认列collate utf8\u general\u ci，以便它能够接受它们。这修复了大多数错误，并使应用程序在遇到非拉丁语电子邮件时也不再出现sql错误

尽管如此，一些电子邮件仍会导致程序遇到错误的字符串值错误：错误的字符串值：“\xE4\xC5\xCC\xC9\xD3\xD8…”用于第1行的“内容”列

内容列是一个MEDIUMTEXT数据类型，它使用utf8列字符集和utf8\u general\u ci列collate。此列中没有可切换的标志

请记住，除非绝对必要，否则我不想接触或查看应用程序源代码：

是什么导致了这个错误？是的，我知道这些电子邮件充满了随机垃圾，但我认为utf8会非常宽容 我怎样才能修好它？ 这样的修正可能产生什么影响？ 我考虑过的一件事是切换到启用二进制标志的utf8 varchar[一些大数字]，但我对MySQL相当陌生，不知道这样的修复是否有意义。

\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编码，但听起来您似乎不太关心这个问题？

当遇到这个错误的字符串值时，我的解决方案是：“\xF8”对于使用scriptcase的列错误，确保我的数据库是为utf8常规ci设置的，我的字段排序规则也是如此。然后，当我对csv文件进行数据导入时，我将csv加载到UE Studio中，然后将其保存为utf8格式，瞧！它就像一个魔咒，里面有29000张唱片，没有错误。以前我尝试导入excel创建的csv

我不建议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，则您的问题已解决

通常，在向编码/排序不兼容的列插入字符串时会发生这种情况

我在使用触发器时遇到了这个错误，由于某种原因，触发器继承了服务器的排序规则。 mysql的默认值至少是Ubuntu latin-1上的瑞典排序。 尽管我的数据库和所有表都设置为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-*无拉丁语-1或其他编码：

show variables like 'char%';

---

我今天解决了这个问题，将列改为“LONGBLOB”类型，它存储原始字节，而不是UTF-8字符

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

---

有关TEXT/LONGTEXT和BLOB/LONGBLOB之间差异的更多详细信息，请参阅本页。网络上也有许多其他的论据讨论这两个问题。

我已经尝试了以上所有的解决方案，它们都带来了有效的观点，但对我来说没有任何效果

直到我发现我在C中的MySQL表字段映射使用了不正确的类型：MySqlDbType.Blob。我把它改为MySqlDbType.Text，现在我可以写所有我想要的UTF8符号了

p、 我的MySQL表字段是LongText类型。但是，当我使用MyGeneration软件自动生成字段映射时，它会在C中自动将字段类型设置为MySqlDbType.Blob

有趣的是，我使用MySqlDbType.Blob类型和UTF8字符已经有好几个月了，没有遇到任何问题，直到有一天我尝试编写一个包含一些特定字符的字符串

---

希望这能帮助那些努力寻找错误原因的人

该错误表示您的字符串编码不正确，例如，您试图将ISO-8859-1编码字符串输入UTF-8编码列 ，或该列不支持您尝试输入的数据

---

实际上，后一个问题是由MySQL UTF-8实现引起的，该实现只支持在UTF-8中表示时需要1-3字节的UNICODE字符。有关详细信息，请参阅。诀窍是使用列类型utf8mb4，而不是utf8，尽管名称不同，utf8实际上并不支持所有UTF-8。前一种类型是适用于所有UTF-8字符串的正确类型。

MySQL的UTF-8类型实际上不是正确的UTF-8–它每个字符最多只使用三个字节，并且只支持基本的多语言平面，即没有表情符号、没有星型平面等

---

如果需要存储来自更高Unicode平面的值，则需要。

我在列名之前添加了二进制，并解决了字符集错误

---

在表A中插入值字符串colname1

在我的例子中，首先我在我的网站上遇到了一个“？”，然后我检查了Mysql的字符集，现在是拉丁语，所以我把它改成utf-8，然后我重新启动了我的项目，然后我和你犯了同样的错误，然后我发现我忘了更改数据库的字符集，改成utf-8，砰，它成功了。

首先检查您的默认字符集名称是否为utf8

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

如果结果不是utf8，则必须转换数据库。首先，您必须保存一个转储

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

ALTER DATABASE DBNAME CHARACTER SET utf8 COLLATE utf8_general_ci;

mysql-database=DBNAME-B-N-e SHOW TABLES | awk'{print SET foreign_key_checks=0；ALTER TABLE$1，转换为字符集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文件上载到数据库时，此解决方案可以帮助我

虽然您的排序规则设置为utf8\u general\u ci，但我怀疑数据库、表甚至列的字符编码可能不同

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

我得到了一个类似的错误，字符串值不正确：'\xD0\xBE\xDO\xB2….'用于第1行的“内容”。我尝试将列的字符集更改为utf8mb4，之后错误更改为“第1行的“内容”列的数据太长”。 结果是mysql显示了错误的错误。我将列的字符集返回到utf8，并将列的类型更改为MEDIUMTEXT。之后，错误消失了。 我希望它能帮助别人。

---

顺便说一句，在相同的情况下，我测试了相同的插入，只剪切了一个文本，没有错误。

表格和字段的编码错误；但是，您可以将它们转换为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;

---

嗨，当我使用godaddy服务器上的在线数据库时，我也遇到了这个错误 我认为它有5.1或更高版本的mysql。但是，当我从localhost服务器5.7版开始做这件事时，我从本地服务器创建了表，并使用mysql-yog复制到了在线服务器，我认为问题在于字符集

---

1-您必须在连接中声明编码UTF8的属性

2-如果使用mysql commando line执行脚本，则必须使用该标志，如：

---

Cmd:C:\wamp64\bin\mysql\mysql5.7.14\bin\mysql.exe-h localhost-u root-P 3306-default character set=utf8 omega\u empresa\u parametros\u 336

为了修复此错误，我将mysql数据库升级为utf8mb4，它支持完整的Unicode字符集通过以下方式。我建议仔细阅读，因为有很多问题，例如，由于新的编码，索引键可能变得太大，之后必须修改字段类型。

这里有很好的答案。我只是添加了我的，因为我遇到了相同的错误，但结果是一个完全不同的问题。也许表面上相同，但根本原因不同

对于我来说，以下字段发生了错误：

@Column(nullable = false, columnDefinition = "VARCHAR(255)")
private URI consulUri;

这最终作为URI类的二进制序列化存储在数据库中。使用H2进行单元测试或使用CI/集成测试时，这并没有引起任何问题，它在我们的产品设置中爆炸了。不过，一旦理解了问题，就很容易在MariaDB4j实例中看到错误的值；它只是没有破坏测试。解决方案是构建自定义类型映射器：

package redacted;

import javax.persistence.AttributeConverter;
import java.net.URI;
import java.net.URISyntaxException;

import static java.lang.String.format;

public class UriConverter implements AttributeConverter<URI, String> {
    @Override
    public String convertToDatabaseColumn(URI attribute) {
        return attribute.toString();
    }

    @Override
    public URI convertToEntityAttribute(String field) {
        try {
            return new URI(field);
        }
        catch (URISyntaxException e) {
            throw new RuntimeException(format("could not convert database field to URI: %s", field));
        }
    }
}

---

就Hibernate而言，它似乎有很多功能，包括java.net.URL，但不包括我们在这里需要的java.net.URI。

我尝试了这里提到的几乎所有步骤。没有一个奏效。下载mariadb。成功了。我知道这不是一个解决方案，但这可能有助于某人快速识别问题或给出临时解决方案

Server version: 10.2.10-MariaDB - MariaDB Server
Protocol version: 10
Server charset: UTF-8 Unicode (utf8)

---

在我的例子中，通过将Mysql列编码更改为

---

“二进制”数据类型将自动更改为VARBINARY。可能我无法使用该列进行筛选或搜索，但我不需要这样做。

在我的情况下，字符串值不正确：'\xCC\x88'…，问题是o-umlaut处于分解状态。帮助我理解了o和o的区别。在PHP中，我的修复方法是使用。例如，Normalizer:：normalize'o¨，、Normalizer:：FORM_C.

如果在保存之前碰巧使用某个字符串函数处理该值，请确保该函数能够正确处理多字节字符。不能完成此功能的字符串函数（例如，试图截断）可能会分裂中间的单个多字节字符之一，并且可能导致此类字符串错误情况。

---

---

例如，在PHP中，您需要从substr切换到。

您的确切意思是什么，当然它不再理解真正的UTF-8了？@Brian:如果您告诉它您要给它cp1252，而实际上给它UTF-8，比如说，咖啡，它会将其误解为咖啡。它不会崩溃，但会误解高位字符。@Richie：数据库可以随意调用数据，但如果捕获数据的php代码将其填充到字符串中，这不会有多大区别……是吗？我看不出缺乏对UTF-8的理解到底在哪里产生影响。@Brian:不，你说得对。它将在数据库中产生影响的时间，例如，如果您在SQL中使用ORDER BY子句，则排序将不稳定，因为您使用的是非ASCII字符。请取消将此答案标记为解决方案，隐藏错误不是任何问题的解决方案。从车上取下过热的指示灯，你会看到。@Kariem：这很奇怪，因为这个设置被SET NAMES命令覆盖，这相当于调用SET character\u SET\u client，SET character\u SET\u results，SET character\u SET\u connection第二个命令应设置为character SET utf8而不是character\u SET虽然这有助于调查问题，但它不回答如何解决问题。我看到的是拉丁文1而不是utf-8。这个答案很好地解释了问题，但很难详细说明OP要求的解决方案@尼科加文达：为了完全解决这个问题，需要运行哪些SQL查询？如何修复所有预先存在的数据？如果源、传输和目标都是UTF-8，那么问题就解决了；这就是MePostMortem的诀窍：解决了问题，并且在运行时没有引入任何其他问题。这可能有点像黑客，但它奏效了，让我避免了用我不完全理解的第三方软件弄脏我的手。在这一点上，我们已经更新到了一个新版本的软件/模式，它正确地处理了所有这些编码问题，并且足够新，它实际上得到了支持，使得黑客攻击变得不必要。我认为这可能是最好的修复方法。升级至5.5并在上述答案中用utf8mb4替换utf8。我从Twitter上插入了utf8数据，其中包含需要4字节的表情符号或其他字符。假设我们不打算升级到5.5。我们如何抑制这些错误呢？自从最初的问题提出10年以来，对于这个最有用的答案，我滚动得太远了。让我们知道MySQL的utf8编码不是正确的utf8。使用utf8mb4！MariaDB也是如此。否则你就不会有喜悦的泪水，这是最好的解决办法。即使在2021年！这个解决方案似乎是最简单的方法。我尝试了一些其他的编码，但没有成功。MySQL我也厌倦了很多事情，意识到MySQL不支持这个版本的4字节utf-8解压编码，我非常想知道是什么导致了这种情况。改变类型显然是答案，一个立即的解决办法。我认为这是所有答案中的正确答案。我有两个表，每个表都有utf8 varchar格式。其中一个出错了，另一个没问题。即使我使用“更新选择”将“良好”utf8列复制到另一个表中，也会发生相同的错误。这是因为这两个表是在不同版本的MySQL中创建的。是的！这也是我数据库表中的错误配置。我认为这个答案应该是正确的。我的问题是，选择的校对是utf8\U unicode\U ci，而不是utf8\U general\U ci。谢谢：这个答案在下面做什么，应该在顶部这个答案很有帮助，它告诉你应该尝试什么，而不是什么可能是错误的。谢谢！这对我帮助很大，我改变了表的排序规则，我想应该是这样，但字段仍然是ascii排序规则。。。