我试图用“create table…select*from”[复制]从现有表创建一个mysql表。

1-您必须在连接中声明编码utf8的属性。 http://php.net/manual/en/mysqli.set-charset.php .

2-如果使用mysql命令行执行脚本,则必须使用标志,如: Cmd: C:\wamp64\bin\mysql\mysql5.7.14\bin\mysql.exe -h localhost -u root -P 3306 --default-character-set=utf8 omega_empresa_parametros_336 < C:\wamp64\www\PontoEletronico\PE10002Corporacao\BancoDeDadosModelo\omega_empresa_parametros.sql

我几乎试过这里提到的每一步。都没用。下载了Mariadb。它奏效了。我知道这不是一个解决方案,但这可能有助于某人快速识别问题或给出一个临时解决方案。

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

我所做的,首先将列类型更改为long blob,插入数据,然后将列类型更改为varchar(255),因为数据没有那么敏感,我冒了很大的风险(大约4万条),我建议你可以试试这个,只要你没有任何你不想扭曲的数据。

这里有很好的答案。我只是添加我的,因为我遇到了同样的错误,但结果却是一个完全不同的问题。(表面上可能相同,但根本原因不同。)

对我来说,以下字段发生了错误:

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

这最终作为 URI 班级。这不会对单元测试(使用h2)或ci/集成测试(使用 MariaDB4j )在我们的生产中爆炸了。(不过,一旦理解了问题,就很容易在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));
        }
    }
}

使用如下:

@Column(nullable = false, columnDefinition = "VARCHAR(255)")
@Convert(converter = UriConverter.class)
private URI consulUri;

就hibernate而言,它似乎有很多 provided type mappers ,包括 java.net.URL ,但不是为了 java.net.URI (这正是我们需要的)。

对我来说,首先我遇到了???在我的网站上,我检查了mysql的拉丁字符集,所以我把它改成了utf-8,然后我重新启动我的项目,然后我也遇到了同样的错误,然后我发现我忘了把数据库的字符集改成utf-8,砰,它成功了。

为了修复这个错误,我将mysql数据库升级为utf8mb4,它支持完整的unicode字符集,方法如下 this detailed tutorial . 我建议仔细阅读,因为有很多问题(例如,索引键可能会因为新的编码而变得太大,之后必须修改字段类型)。

嗨,我在使用godaddy服务器上的联机数据库时也遇到了这个错误 我认为它有5.1或更高版本的mysql。但是当我从本地主机服务器(5.7版)创建表并使用mysql-yog复制到联机服务器之后,一切都很好,我认为问题在于字符集。

Screenshot Here

我在列名前添加了binary并解决了字符集错误。

插入tablea值(binary stringcolname1);

当遇到这个不正确的字符串值时,我的解决方案是:使用scriptcase为列错误设置“\xf8”,以确保我的数据库是为utf8通用ci设置的,字段排序也是如此。然后当我做一个csv文件的数据导入时,我将csv加载到ue studio中,然后将其保存为utf8和voila格式!它的工作就像一个符咒,29000个记录中没有错误。以前我试图导入一个excel创建的csv。

我已经尝试了以上所有的解决方案(都带来了有效的观点),但没有什么对我有用。

直到我发现我在c中的mysql表字段映射使用了错误的类型: mysqldbtype.blob . 我改成了 mysqldbtype.text 现在我可以写出我想要的所有utf8符号了!

另外,mysql表字段是“longtext”类型的。但是,当我使用mygeneration软件自动生成字段映射时,它会在c_中将字段类型设置为mysqldbtype.blob。

有趣的是,我使用mysqldbtype.blob类型和utf8字符已经有好几个月了,直到有一天我试着写一个字符串,其中包含一些特定的字符。

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

我也犯了同样的错误( 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)只需剪切一个文本而没有错误。

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

实际上,后一个问题是由mysql utf-8实现引起的,该实现只支持在utf-8中表示时需要1-3字节的unicode字符。见 "Incorrect string value" when trying to insert UTF-8 into MySQL via JDBC? 详情。

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

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

首先检查默认字符集名称是否为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文件上载到数据库时,此解决方案对我有帮助。

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

当我有触发器时,我得到了这个错误,触发器由于某种原因继承了服务器的排序规则。 mysql的默认值是(至少在ubuntu上)拉丁文-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) .

参考本页 http://dev.mysql.com/doc/refman/5.0/en/blob.html 有关text/longtext和blob/longblob之间差异的详细信息。网络上还有很多其他的争论在讨论这两个问题。

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

mysql的utf-8类型实际上不是正确的utf-8,它每个字符最多只使用3个字节,并且只支持基本的多语言平面(即没有emoji、没有astral平面等)。

如果需要存储来自更高Unicode平面的值,则需要 utf8mb4 encodings .

我不建议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,那么问题就解决了;)

"\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西欧”)是最允许的编码—每个字节值都是有效的代码点。

当然,它不会再理解真正的utf-8,也不会理解任何其他非cp1252编码,但听起来你不太关心这个问题吗?