我有一台托管MySQL的服务器,PHPMyAdmin报告:
Server version: 5.1.56-community
MySQL charset: UTF-8 Unicode (utf8)
我通过使用mysqldump -uroot -p database > file.dump
或mysqldump -uroot -p database -r file.dump
导出sql(无论如何生成的文件都是相同的)。
在本地,我安装了MySQL 5.5和HeidiSQL 9.5。
my.ini作为服务器的SQL文件:
default-character-set=utf8
我将本地my.ini文件更改为具有
default-character-set=utf8
而且:
character-set-server=utf8
它们都设置为latin1
。不知道为什么我在这里设置character-set-server
而服务器没有设置。无论如何。
现在,我启动HeidiSQL,它显示utf8mb4
引用代替了会话参数的utf8
。我不知道为什么:
现在,我导入了转储的文件,并且看到即使所有内容显然都在utf8
中进行了配置,看起来我还是有一些编码问题。
诸如à
之类的特殊字符未在本地数据库上正确显示。
我做错什么了吗?
请注意,如果我在服务器上安装HeidiSQL,则变量选项卡将为 Session 和 Global 参数显示相同的值,并显示à
正确地。
因此,这可能是问题的根本原因,但我不知道如何解决。如果我在导入sql文件之前更改 Session 值,则不能解决问题,并且当我再次启动HeidiSQL时,值也恢复为utf8mb4
。
答案 0 :(得分:2)
一些想法:
看起来您已正确设置了字符集。 HeidiSQL显示不同的字符集的事实,可能是因为客户端自己设置了字符集。
例如,默认情况下,您的mysql服务器可能使用“字符集A”。如果客户端连接并说他们想要“字符集B”,则服务器将立即对其进行转换。
utf8mb4
是utf8
的超集(且优于utf8mb4
)。最好将您的服务器默认设置为utf8mb4
。 $data
的流行用例是表情符号。
无论如何,获得mojibake的原因可能与正确设置这些字符集无关。
我认为可能发生了以下情况(这是一个猜测)。
如果我是对的,则意味着您可以将所有列,连接和表都设置为UTF-8,但是您的数据很糟糕。
如果正确,则此过程是可逆的
您实际上只需要相反的操作。例如,如果您有一个PHP字符串$output = utf8_decode($input)
,它被“双重编码”为UTF-8,则该过程将简单地称为:
open class MyApp : Application() {
override fun onCreate() {
super.onCreate()
mInstance = this
}
companion object {
lateinit var mInstance: MyApp
fun getContext(): Context? {
return mInstance.applicationContext
}
}
}
还可以在MySQL中修复此问题。看到这个stack overflow question.
需要注意的几件事:
旁注:此问题非常普遍。您很幸运,因为您是法国人,因为这突出了问题所在。我见过的许多英语系统都存在此问题,但是很长一段时间以来它并没有引起人们的注意,因为许多文本不会超出通用ASCII范围。
答案 1 :(得分:2)
感谢您发表评论,我可以解决此问题。
在HeidiSQL中,当我选择要执行的sql文件时,实际上有一个我最初没有注意到的“ ncoding”选项;-)
如果我保持“自动检测”,则导入会生成不良内容(带有mojibake字符)
如果我强制使用“ UTF-8”,则导入是完美的
不知道为什么HeidiSQL无法自动检测编码...
答案 2 :(得分:0)
您有“ Mojibake”。 à
变成Ã
(有两个字符,第二个是空格)。
这是由于过程中某处涉及latin1
而引起的。 SESSION
和GLOBAL
设置没有问题。让我们看看SHOW CREATE TABLE
。
有关可能的原因,请参见Trouble with UTF-8 characters; what I see is not what I stored中的Mojibake。它可能涉及“双重编码”;让我们看看SELECT col, HEX(col) ...
。
关于固定数据-取决于您是简单的Mojibake还是Double Encoding。两者均参见http://mysql.rjweb.org/doc.php/charcoll#fixes_for_various_cases。