Discuz X3.4 升级到 X3.5 出现乱码主要是数据库字符集与程序配置不匹配导致，需将数据库和 config_global.php 统一调整为 utf8 或 utf8mb4。操作前必须完整备份数据库和附件目录，防止字符转换失败造成数据丢失。
先说结论：解决乱码的核心是确保数据库存储字符集、连接字符集与 Discuz 配置文件三者一致。
- 适合场景：Discuz 旧版本升级、服务器迁移、数据库导入导出后出现中文乱码。
- 先准备：完整备份数据库 SQL 文件及全站附件，确认当前数据库字符集类型。
- 验收：前台帖子内容显示正常、后台用户列表无乱码、搜索功能可命中中文关键词。
命令速用版
通过 MySQL 命令快速检查当前数据库字符集配置，确认是否需转换。
SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';若需转换数据库字符集，执行以下命令（操作前务必备份）：
ALTER DATABASE 数据库名 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
ALTER TABLE 表名 CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;为什么会这样
乱码根本原因是 Discuz X3.4 旧版本默认可能使用 GBK 编码，而 X3.5 版本推荐或强制使用 UTF-8 编码。
当数据库存储格式为 GBK，但 PHP 连接层或程序输出层按 UTF-8 解析时，中文字符会出现乱码。升级过程中若未正确转换数据表字符集，或直接覆盖了配置文件导致连接字符集声明错误，都会引发此问题。
分步处理
按照以下顺序检查并修正字符集配置，每一步完成后需刷新页面确认。
第一步：备份数据
使用 phpMyAdmin 或 mysqldump 导出完整 SQL 文件，备份 config/config_global.php 文件。
第二步：检查数据库字符集
登录数据库，确认 Discuz 相关数据表的字符集是否为 utf8 或 utf8mb4。若为 gbk，需使用转换工具或 SQL 命令转换。
第三步：修改配置文件
编辑 config/config_global.php，找到 $_config['db']['1']['dbcharset'] 配置项，确保其值为 utf8 或 utf8mb4，与数据库实际字符集保持一致。
第四步：清理缓存
删除 data/cache 和 data/template_cache 目录下的所有文件，强制程序重新生成缓存。
怎么验证是否生效
通过前台页面内容显示和后台数据库查询结果双向验证修复效果。
1. 前台访问包含中文的帖子详情页，确认标题和内容无乱码。
2. 后台“用户”列表页，确认用户名显示正常。
3. 数据库执行 SELECT 查询，确认返回的中文字符在客户端工具中显示正确。
常见坑
升级过程中容易忽略配置文件与数据库实际环境不一致的问题，导致反复乱码。
- 不要直接修改数据库底层文件，必须通过 SQL 命令或管理工具转换字符集。
- PHP 版本过低可能不支持 utf8mb4，Discuz X3.5 建议 PHP 7.4 及以上。
- 附件中的文本文件若包含旧编码，升级后可能仍需单独处理。
常见问题
升级前必须备份数据库吗？
必须备份。字符集转换操作不可逆，一旦失败可能导致数据永久损坏，备份是唯一的恢复手段。
config_global.php 中 dbcharset 填什么？
填写与数据库实际存储字符集一致的值，通常为 utf8 或 utf8mb4，不要随意填写 gbk 除非数据库确实是 gbk。
乱码后能直接覆盖安装包吗？
不能。直接覆盖安装包无法修复数据库字符集问题，需先修复数据编码再升级程序文件。