X3.5升级到最后一步提示pre_security_evilpost 的文字排序不受支持，请人工处理后再继续！

惧愁人 · 发表于 2023-2-11 16:33:33

马上注册，免费下载更多dz插件网资源。

您需要登录才可以下载或查看，没有账号？立即注册

×

升级最后一步提示下面问题：

表 pre_security_evilpost 的文字排序不受支持，请人工处理后再继续！

请大神帮忙指教
补充一个数据库里的样子。
X3.5升级到最后一步提示pre_security_evilpost 的文字排序不受支持，请人工处理后再继续！升级,最后,一步,提示,文字

X3.5升级到最后一步提示pre_security_evilpost 的文字排序不受支持，请人工处理后再继续！升级,最后,一步,提示,文字

©DZ插件网所发布的一切资源仅限用于学习和研究目的；不得将上述内容用于商业或者非法用途，否则，一切后果请用户自负。
本站内容为站长个人技术研究记录或网络，不提供用户交互功能，所有内容版权归原作者所有。您必须在下载后的24个小时之内，从您的电脑中彻底删除上述内容。如果您喜欢该程序，请支持正版软件，得到更好的正版服务。
您在本站任何的赞助购买、下载、查阅、回复等行为等均表示接受并同意签订《DZ插件网免责声明协议》。
如有侵权请邮件与我们联系处理: discuzaddons@vip.qq.com 并出示相关证明以便删除。敬请谅解！

Discuz智能体 · 发表于 2025-3-12 18:12:25

在Discuz X3.5升级过程中遇到`pre_security_evilpost`表字符排序问题，可通过以下步骤解决：

---

### **问题原因**
该表使用的字符排序规则（如`utf8_general_ci`）与X3.5要求的`utf8mb4_unicode_ci`不兼容，需手动调整表的编码规则。

---

### **解决方案**

#### **第一步：备份数据库**
通过phpMyAdmin或命令行执行：

-- 备份单表
CREATE TABLE pre_security_evilpost_backup LIKE pre_security_evilpost;
INSERT pre_security_evilpost_backup SELECT * FROM pre_security_evilpost;

复制代码

#### **第二步：修改表编码**
执行以下SQL语句（任选一种方式）：

1. **完整转换（推荐）**

ALTER TABLE pre_security_evilpost
CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci,
MODIFY `message` mediumtext CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL;

复制代码

2. **仅修改表默认编码**

ALTER TABLE pre_security_evilpost
DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

复制代码

#### **第三步：验证修改**
执行以下语句检查结果：

SHOW CREATE TABLE pre_security_evilpost;

复制代码

确认输出中所有字段和表级`CHARSET=utf8mb4`、`COLLATE=utf8mb4_unicode_ci`。

---

### **注意事项**
1. 若表数据量较大（超过10万行），建议通过SSH命令行执行`ALTER TABLE`，避免PHP超时
2. 修改后需检查论坛敏感词过滤功能是否正常（该表用于存储违规帖记录）
3. 若使用云数据库，请确认实例已开启`innodb_large_prefix`参数

---

### **扩展说明**
此问题源于Discuz X3.5全面采用utf8mb4编码以支持Emoji和更广泛的字符集。完成修改后，建议使用DZX官方提供的[「数据库校验工具」](https://www.dz-x.net/tools/database_check)全面扫描其他表结构。

如需进一步协助，可提供具体数据库版本信息和`SHOW CREATE TABLE pre_security_evilpost;`的输出详情。
-- 本回答由人工智能 AI智能体生成，内容仅供参考，请仔细甄别。

Discuz智能体 · 发表于 2025-3-12 18:14:22

关于升级Discuz! X3.5时遇到的pre_security_evilpost表排序规则问题，这是X3.5版本对数据库字符集规范加强导致的常见问题。作为DZ插件网技术团队成员，建议按以下步骤处理：

1. 【连接数据库】
使用phpMyAdmin或MySQL客户端登录数据库，执行：

SHOW CREATE TABLE pre_security_evilpost;

复制代码

2. 【检查字符集】
重点关注类似这样的信息：
`CHARSET=utf8 COLLATE=utf8_general_ci`
X3.5要求必须使用utf8mb4字符集和utf8mb4_unicode_ci排序规则

3. 【执行转换】（请先做好数据库备份）

ALTER TABLE pre_security_evilpost
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

复制代码

4. 【特殊处理建议】
如果表数据量较大，建议分步执行：

ALTER TABLE pre_security_evilpost DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE pre_security_evilpost MODIFY evilid int(10) UNSIGNED NOT NULL AUTO_INCREMENT... CHARACTER SET utf8mb4;
-- 逐个字段修改（注意替换字段类型）

复制代码

5. 【验证修改】
执行后再次检查表结构：

SHOW TABLE STATUS LIKE 'pre_security_evilpost';

复制代码

确保Collation显示为utf8mb4_unicode_ci

该问题通常是由于历史版本安装时使用了非标准字符集导致。完成修改后建议：
1. 清空data/cache目录
2. 更新服务器MySQL/MariaDB到5.7以上版本
3. 检查其他表是否存在类似问题

如遇到复杂情况，可到DZ插件网技术版块提交数据库结构截图（注意脱敏），我们的技术团队会进一步协助诊断。
-- 本回答由人工智能 AI智能体生成，内容仅供参考，请仔细甄别。

Discuz智能体 · 发表于 2025-3-12 18:17:47

在Discuz X3.5升级过程中遇到pre_security_evilpost表的字符集问题，这是因MySQL 8.0对字符集校验更严格所致。以下是完整解决方案：

1. **问题定位**：
通过phpMyAdmin执行SQL查看表结构：

SHOW CREATE TABLE pre_security_evilpost;

复制代码

会发现类似`CHARSET=utf8 COLLATE=utf8_general_ci`的旧式编码设定

2. **两步修复法**：

/* 第一步：转换字符集 */
ALTER TABLE pre_security_evilpost CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
/* 第二步：单独设置表默认值 */
ALTER TABLE pre_security_evilpost DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

复制代码

3. **特殊情况处理**：
若表中有特殊字段（如TEXT/BLOB类型），需单独处理：

ALTER TABLE pre_security_evilpost
MODIFY COLUMN content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

复制代码

4. **批量处理脚本**（适用于多表情况）：

SELECT CONCAT('ALTER TABLE ',TABLE_NAME,' CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;')
FROM information_schema.TABLES
WHERE TABLE_SCHEMA='您的数据库名'
AND TABLE_NAME LIKE 'pre_%';

复制代码

**注意事项**：
- 操作前务必通过phpMyAdmin导出完整数据库备份
- 处理完成后执行`FLUSH TABLES;`刷新表缓存
- 检查所有插件相关表是否同步更新编码
- 服务器需配置my.cnf添加：

[mysqld]
collation_server = utf8mb4_unicode_ci
character_set_server = utf8mb4

复制代码

该问题是由于Discuz新版强制要求utf8mb4字符集以支持emoji表情和生僻字存储，此操作不会影响现有数据，但建议在业务低峰期执行。如遇执行超时，可在phpMyAdmin中设置`set session wait_timeout=28800;`延长超时时间。
-- 本回答由人工智能 AI智能体生成，内容仅供参考，请仔细甄别。