我们在服务器2003上运行了一个旧的5.1 Mysql服务器。最近我们使用Mysql 5.6和server 2008迁移到更新的环境。现在在新服务器上,我们在插入像'Ã'这样的特殊字符时一直出错。
现在我检查了源编码,它是UTF-8。但旧的Mysql服务器配置为latin1(服务器/表格/冒号)与排序规则latin_swedish_ci,我们没有在旧环境中收到任何错误。
现在我已经做了一些测试,因为我们没有在新环境中生活。我已经尝试将所有表设置为表/冒号以及latin1。在这两种情况下,我都会遇到这些错误。
我注意到在旧服务器上,服务器默认字符集是latin1,在新服务器上是utf-8。这可能是问题吗?我发现这很奇怪,因为源是utf-8。
是否有一些选项可以处理这个可以在旧环境中打开的选项?我不确定是否存在类似的东西。我确实比较了mysql管理工具中的设置,除了默认的字符集外,它看起来都是一样的。
修改
SHOW VARIABLES LIKE'char%';
旧服务器:
+--------------------------+-----------------------------------------------+
| Variable_name | Value |
+--------------------------+-----------------------------------------------+
| character_set_client | utf8 | *
| character_set_connection | utf8 | *
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8 | *
| character_set_server | latin1 |
| character_set_system | utf8 |
新服务器:
+--------------------------+-----------------------------------------------+
| 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 | utf8 |
| character_set_system | utf8 |
据我在MySQL网站上的文章所理解,utf8mb4是utf8的超集,这应该不会产生编码问题我认为因为它们在编码上基本相同吗?
答案 0 :(得分:2)
SHOW VARIABLES;
。 5.0默认为latin1
; 5.6默认为utf8
。这在
mysql> SHOW VARIABLES LIKE 'char%';
+--------------------------+-----------------------------------------------+
| Variable_name | Value |
+--------------------------+-----------------------------------------------+
| character_set_client | utf8 | *
| character_set_connection | utf8 | *
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8 | *
| character_set_server | latin1 |
| character_set_system | utf8 |
SET NAMES utf8;
设置三个标记的行。
Ã
在latin1中为十六进制C3
,在utf8中为C383
。 More encodings here。这样做是为了查看当前表中的内容:
SELECT col, HEX(col) FROM table WHERE ...
另一种可能性是"移动"破坏了数据。如果您可以在两台计算机上执行相同的SELECT
,并且如果它们的出现方式不同,则迁移很糟糕。由于有很多方法可以移动数据,请提供迁移的详细信息,以便我们剖析可能出现的问题。
在标题中,您有C29F
。这是一个奇怪的 - 它是一个我从未听说过的控制代码APPLICATION PROGRAM COMMAND
。 (注意:它与您稍后提到的Ã
无关。)请提供更多问题示例;这些线索都没有帮助。
答案 1 :(得分:1)
old UTF-8 of MySQL不是真正的UTF-8。如果您尝试使用“特殊”字符(日语或中文),您可能会在旧服务器上找到正方形或问号。
您的新服务器现在正在使用UTF-8(mb4代表多字节4)。服务器接收UTF-8字符,但显然无法存储UTF-8字符,因为您的表没有使用UTF-8。将所有表转换为UTF-8,将数据库转换为UTF-8,您将解决您的问题。
你可以这样做:
ALTER DATABASE databasename CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE tablename CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
不要忘记以前备份。
答案 2 :(得分:1)
这一点的重要部分是您的旧服务器具有:
| character_set_database | latin1
当你的新服务器有
时| character_set_database | utf8
如果数据库使用的是latin1,则连接和客户端使用utf8并不重要,表格将默认为latin1,因此数据将存储在latin1中,您将收到错误消息。您当然可以明确地将任何表的字符集和排序规则设置为数据库默认值以外的其他表。
我想在迁移数据库模式时,您没有在运行迁移脚本之前编辑数据库的字符编码或表。
现在您可以手动更改数据库和每个表,也可以编辑迁移脚本并重新运行它。大多数迁移脚本和数据库转储将包括每个表以及数据库的特定字符集,即使它们都是相同的。
答案 3 :(得分:0)
当我将我的应用程序移动到新的环境时,我得到了一个经验。当插入与要插入到表的数据相关的数据时,我得到了一些奇怪的事情,我的情况是抱怨日期是空的,因此无法插入到表中(源代码没有变化。只有新的env(Mysql服务器从5.1到5.6) ,tomcat 6到tomcat 7,新的Suse服务器版本。)
我尝试将mysql连接器驱动程序替换为我的应用程序的更新版本,它解决了这个问题。