好的，这是一个提示：如果你不知道你在做什么，就不要这样做！我有一个现场网店，我只是在某种程度上打破了，我认为这与我的变化有关，在这个网站上阅读后，utf8mb4_unicode_ci有多好。
出现的问题是，当我的客户使用ÅÄÖ或éá等信件进行购物和付款时，付款会通过，但WooCommerce在某种程度上无法处理它并向我发送“已取消的订单”，尽管已付款。现在我认为我做出这样做的改变的原因是因为那些打破了那些带有那些奇怪信件的人。我的客户"Andersén"示例显示在我的结算帐单上："Andersén"
我该怎么办？
答案 0 :(得分：0)
如果你不知道你在做什么，就不要这样做！ - 你的头上钉了一针！而MySQL中的CHARACTER SETs就是这样一个可能出错的东西。
<强>原因
é的{{1}} 可能是 Mojibake。
有4个（有时是5个）阶段你可能搞砸了。当您尝试修复问题时，有两种（可能更多）方法可以解决问题。
你有几个字节？ latin1中的é是一个字节，十六进制é。在utf8（和utf8mb4）中，它是2个字节，十六进制E9。 （对于Mojibake，你可能有C3A9。）
在您的客户端中向我们显示C3A9（或SET NAMES或...）。最终它应该是'utf8mb4';它是从什么开始的？ Mojibake可以出现'latin1'或'utf8'。最终应该是utf8 / utf8mb4。
列/表定义set_charset()是什么？最终应该是utf8 / utf8mb4，但转换现有数据可能会非常棘手。
CHARACTER SET可能遗失或是......;最终应为<meta ...charset=...>（UTF-8，不-）。
如果你很幸运，＃4只是 非utf8项目，那么添加/更改元标记应该已经足够了。
<强>诊断
请这样做我们可以弄清楚情况有多糟糕：
mb4用于“Andersén”（或其他）。
SELECT col, HEX(col) FROM tbl WHERE ...
- 纯拉丁语1;我不指望这会发生;
416E64657273E96E - 正确存储为utf8 / utf8mb4（但错误地检索和/或渲染）;
416E64657273C3A96E - “双重编码” - 一个混乱的情况。
由于最后两种情况可能可以变为416E64657273C383C2A96E，我需要知道在启动如何解决之前它是什么。
Here是我未完成的关于如何处理所有字符集问题的简编。它包括Andersén表格的两种方式;它们用于不同的原因。做错了只会加剧问题。
治愈 待定