我正在尝试调试一个讨厌的 utf-8 问题，但不知道从哪里开始。
页面包含单词“categorieën”，应该是 categorieën。显然 UTF-8 有问题。所有这些多字节字符都会发生这种情况。我已经浏览了这里关于 UTF8 的无数主题，但它们大多涵盖了基础知识，而不是这种情况，即一切似乎都已配置和设置正确，但显然不是。
这些页面由来自 MySQL 数据库的 Drupal 服务。
数据库是通过 sql 转储和导入槽 phpmyadmin 迁移的(不是我)。很有可能那里出了问题，因为以前没有问题。而且因为问题只发生在较旧的进口商品上。编辑这些项目或插入新项目，并手动修复错误编码的字符，即可解决问题。虽然我看不到数据库中的差异。
- 通过 Drupal 重新编辑的内容没有这个问题。
- 当在 CLI 上使用 MySQL 时，我可以读出该文本并获得正确的 ë 字符。在呈现“正确”和“不正确”字符的两篇文章中。
- 表格有排序规则
utf8_general_ci - header 似乎以正确的编码发送:
Vary Accept-Encoding和Content-Type text/html; charset=utf-8 - HTML head 包含一个
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> - HTTP header 告诉我中间有一个 Varnish 代理。这会导致 UTF8 转换/损坏吗
- 内容以 Gzip 压缩提供，这在 Drupal 中是正常的，我从未见过这个 UTF8 issie wrt gzipping，但你永远不知道。
似乎导入是罪魁祸首，我想知道 a) 出了什么问题。 b) 为什么我在 mysql cli 客户端中看不到“错误”和“正确”字符之间的区别 c) 如何修复数据库，或者从哪里开始寻找和学习如何修复它。
最佳答案
转储文件可能输出为 UTF-8，但在导入期间被解释为 latin1。
ë 是 UTF-8 的 ë 的 latin1 两字节表示，在您的表中作为 UTF-8 数据物理存在。
鉴于您混合了完整的和损坏的数据，这将很难以一般方式修复，但通常，这种肮脏的解决方法*会很有效:
UPDATE table SET column = REPLACE("ë", "ë", column);
除非您使用的是荷兰语以外的语言，否则损坏字符的范围应该非常有限，您可以使用少量此类语句来修复它。
相同问题的相关问题:
* (当然，不要忘记在运行此类操作之前进行备份!)
关于php - UTF8 字符未在 Drupals HTML 中打印，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3358005/