[Bug] 消息过长导致数据库存不进去

[Komeiji0Koishi]

Plugin Version

2.0.6

AstrBot Version

4.14.5

Database Type

MySQL

Operating System

Windows

Bug Description

�[32m[10:18:23.137]�[0m [Core] �[31m�[1m[ERRO]�[0m [v4.19.4] [facades.jargon_facade:120]: �[31m�[1m[JargonFacade] 插入黑话失败: (pymysql.err.DataError) (1406, "Data too long for column 'raw_content' at row 1")

向mysql保存消息的时候，由于消息太长（多层的转发消息，解析之后特别长）超过了mysql中message字段的TEXT的最大长度（TEXT: 最大长度为 65,535 字节，大约是 64KB），然后导致存不进去报错。

Steps to Reproduce

qq中转发一个多层的转发消息，并且开启了转发消息解析。

Expected Behavior

正常保存

Error Logs

�[32m[10:18:23.137]�[0m [Core] �[31m�[1m[ERRO]�[0m [v4.19.4] [facades.jargon_facade:120]: �[31m�[1m[JargonFacade] 插入黑话失败: (pymysql.err.DataError) (1406, "Data too long for column 'raw_content' at row 1")

Relevant Configuration

Additional Context

解决办法：
两种办法二选一，
1，把mysql中"raw_messages"表的"message"的字段从text改成 LONGTEXT: 最大长度为 4,294,967,295 字节，大约是 4GB。
2，添加一个截断功能，消息太长就截了，只保存前面部分的，后面不要了。
我改了一下：
jargon_facade.py

[github-actions]

🤖 Issue 审查报告

优先级: 🟠 high

📋 用户处理意见

问题摘要: 在使用 MySQL 时，转发解析后的消息内容超过了 MySQL 表字段（TEXT）容量上限，导致插入 raw_content/raw_messages.message 失败并抛出 1406 Data too long。

问题分类: 配置错误

建议操作：

1. 备份数据库（尤其是 raw_messages / jargon 相关表）。
2. 将存储原始消息内容的字段改为 LONGTEXT（推荐，不丢数据）。在 MySQL 执行：
   ALTER TABLE raw_messages MODIFY COLUMN message LONGTEXT;
   -- 若报错里是 raw_content 列，则对对应表执行：
   ALTER TABLE <your_table_name> MODIFY COLUMN raw_content LONGTEXT;
3. 如果使用了严格 SQL 模式且仍因索引/行格式报错，确保表引擎为 InnoDB，且 ROW_FORMAT 为 DYNAMIC/COMPRESSED（一般无需）：
   ALTER TABLE raw_messages ROW_FORMAT=DYNAMIC;
4. 重启 AstrBot / 插件后再复现确认不再报 1406。

---

🔧 开发者修复建议（点击展开）

技术摘要: MySQL 下消息字段使用 TEXT，遇到转发解析导致的超长消息会触发 1406，当前代码未做字段类型迁移或插入前截断/降级处理。

相关模块: database, message capture, jargon mining

相关文件: services/database/facades/jargon_facade.py, models/orm/message.py, models/orm/jargon.py, core/database/engine.py, services/database/sqlalchemy_database_manager.py, repositories/raw_message_repository.py

根因分析: ORM/建表逻辑将原始消息内容字段定义为 TEXT（或等价类型），在 MySQL 中最大约 64KB；在 services/database/facades/jargon_facade.py 插入 raw_content 时未做长度保护，导致 pymysql.err.DataError 1406。相关模型很可能在 models/orm/message.py（raw_messages.message）和/或 models/orm/jargon.py（raw_content）里使用了 Text 类型。

修复建议: 1) 将相关 ORM 字段在 MySQL 方言下明确升级为 LONGTEXT：在 models/orm/message.py 和 models/orm/jargon.py（含 raw_content/message 字段）使用 sqlalchemy.dialects.mysql.LONGTEXT；同时保持 SQLite 用 Text。
2) 增加数据库迁移/自动修复：在 core/database/engine.py 或 services/database/sqlalchemy_database_manager.py 的初始化/ensure_schema 流程中检测列类型，若为 TEXT 则执行 ALTER TABLE 自动升级（仅 MySQL）。
3) 增加防御性截断（可配置）：在 services/database/facades/jargon_facade.py（以及写 raw_messages 的 facade/repository）插入前判断长度，超过阈值则截断并在末尾追加标记（如 "...[truncated]"），避免仍有用户不愿改表结构时持续报错。

---

_{🤖 此报告由 AI 自动生成，已分析仓库源码，仅供参考。开发者会尽快审阅您的 issue。}

[NickCharlie]

感谢反馈，正在修复

[gkchp]

里面存的汉字都变成了\u****转义，占了更多长度