我有一个托管mysql的服务器，phpmyadmin报告：
Server version: 5.1.56-community
MySQL charset: UTF-8 Unicode (utf8)我使用以下两种方法导出sql mysqldump -uroot -p database > file.dump 或者 mysqldump -uroot -p database -r file.dump （无论如何，生成的两个文件都是相同的）。
在本地，我安装了mysql 5.5和heidisql9.5。
由于服务器的sql文件my.ini具有：
default-character-set=utf8我将本地my.ini文件更改为
default-character-set=utf8而且：
character-set-server=utf8他们都准备好了 latin1 . 不知道我为什么 character-set-server 在这里设置，而服务器不设置。不管怎样。
现在我开始heidisql，它显示了 utf8mb4 引用而不是 utf8 对于会话参数。我不知道为什么：
现在，我导入转储的文件，我看到即使所有东西都在 utf8 ，似乎我有一些编码问题。
在服务器上，我看到：
在heidisql中，我看到：
特殊字符，如 à 未在本地数据库上正确显示。
我做错什么了吗？
请注意，如果在服务器上安装heidisql，variable选项卡将显示会话和全局参数的相同值，并且 à 正确显示。
所以这可能是问题的根本原因，但我不知道如何解决它。如果在导入sql文件之前更改会话值，则不会解决此问题，而且值也会返回到 utf8mb4 当我重新开始heidisql的时候。
3条答案
按热度按时间zour9fqk1#
你有“mojibake”。
à变成Ã（有两个字符，第二个是空格）。这是由于
latin1在这个过程中的某个地方。这个SESSION以及GLOBAL设置没有问题。让我们看看SHOW CREATE TABLE.用utf-8字符查看mojibake的问题；我看到的并不是我为可能的原因储存的东西。可能涉及“双重编码”；让我们看看
SELECT col, HEX(col) ....至于修复数据——这取决于您使用的是简单的mojibake还是双重编码。看到了吗http://mysql.rjweb.org/doc.php/charcoll#fixes_for_various_cases 两个都是。
eqoofvh92#
感谢deceze的评论，我可以解决这个问题。
在heidisql中，当我选择要执行的sql文件时，实际上有一个“ncode”选项，我最初没有注意到；-）
如果我保持“auto-detect”，导入会生成不好的内容（带有mojibake字符）
如果我强制使用“utf-8”，导入是完美的
不知道为什么heidisql无法自动检测编码。。。
23c0lvtd3#
一些想法：
看起来您的角色集是正确的。heidisql显示一个不同的字符集，这可能是因为客户机自己设置了一个字符集。
例如，mysql服务器在默认情况下可能使用“character set a”。如果客户机连接并说他们需要“字符集b”，服务器将动态地转换它。
utf8mb4是超集（且优于）utf8. 最好让您的服务器默认为utf8mb4. 流行的用例utf8mb4是表情符号。不管怎样，你得到mojibake的原因可能与正确设置这些角色集无关。
我认为可能发生的事情如下（这只是猜测）。
您的表/列被设置为utf-8。
客户端连接并告诉服务器“我想改用iso-8559-1/拉丁语”。
服务器很高兴地遵守并将客户机iso-8559-1字符串动态转换为utf-8。
尽管客户机想要使用iso-8559-1，但它实际上发送utf-8。
服务器认为数据是iso-8559-1并将其视为iso-8559-1，然后使用iso-8559-1将utf-8转换为utf。实际上是双重编码。
如果我是对的，这意味着您可以将所有的列、连接和表设置为utf-8，但是您的数据很糟糕。
如果这是正确的，这个过程是可逆的
你真的需要相反的操作。例如，如果您有一个php字符串
$data，它被“双重编码”为utf-8，过程简单地称为：在mysql中也可以解决这个问题。请参阅此堆栈溢出问题。
需要注意的几点：
确保情况确实如此。这次手术后你的输出正确吗？
显然，要做备份。
另外，绝对要确保将双编码utf-8写入数据库的内容现在已修复。你最不想要的就是一个混合了不同编码的表。
旁注：这个问题非常常见。你有点幸运，你是法国人，因为这突出了问题所在。我见过的许多英语系统都有这个问题，但很长一段时间以来它基本上没有被注意到，因为很多文本都没有超出常见的ascii范围。