今晚见吗❓这是个坏主意对吗 今晚见吗⁉️**的 这很好❗️如果这条消息是用户在你开发的社区系统里提交的接下来会发生什么运气好它原样入库运气不好数据库直接报Incorrect string value弹幕接口超时内容审核服务把整段会话标记为异常甚至因为某个不可见字符导致下游 NLP 模型输出一个完全离谱的结果。很多后端开发看到这类输入的第一反应是“用户乱发、前端没拦住”但真正的问题往往在服务端文本没有被当作一种需要专门处理的数据类型。这篇文章会从一段“很乱”的文本出发把“异常文本从提交到落库”的完整链路拆开讲清楚。你会弄明白四件事服务端校验为什么不能省NFKC 归一化到底解决了什么问题emoji 为什么必须用 utf8mb4 存储以及敏感词过滤产生的**为什么不应该写回数据库。适合后端开发、IM/社区/评论系统开发以及正在做文本数据清洗和 NLP 特征工程的读者阅读。1. 这串“乱码消息”背后是后端文本处理的四个坑把上面这段消息拆开看它至少包含四个典型特征恰好对应后端文本处理的四个常见问题。第一消息里有大量重复语气词和符号。“今晚见吗”出现两次感叹号、问号、倒问号混在一起。这种文本如果直接存库后续做关键词搜索、重复消息识别、NLP 意图识别时都会被噪声干扰。你以为是用户表达方式的问题其实是数据标准化没有做。第二文本包含明确情绪和态度表达。“这是个坏主意对吗”“这很好”放在一起说明用户情绪是复杂的。对于评论系统或者智能客服系统这类文本是典型的需要做情感分析、内容预判的输入。但情感分析模型对噪声极其敏感一个全角标点、一个表情符号都有可能改变特征分布。第三**的里的星号非常关键。它通常意味着这段文本在到达你的服务之前已经经过了一次敏感词替换。也就是说你拿到的不是原始输入而是被“污染”过的数据。这种污染会导致一个很隐蔽的问题如果系统把**结果直接入库原始信息就永久丢失了后续想追溯、申诉、复核都无从下手。第四一堆 emoji 让文本的存储长度计算变得复杂。Java 的String.length()对 emoji 返回的是 2 而不是 1MySQL 的utf8又存不下 4 字节字符。如果设计阶段没有意识到这一点上线后就会遇到“表情变问号”“字符串长度超限”“索引失效”这一连串问题。所以这类文本问题不是加一个maxlength140就能解决的。服务端如果缺少一条完整的处理链路轻则数据不干净重则埋下 SQL 注入、存储型 XSS、下游模型失效的雷。2. 核心概念校验、归一化、编码与脱敏2.1 输入校验为什么必须在服务端再做一次校验的本质是“系统不接受它无法处理的数据”。很多团队只依赖前端校验输入框设置了maxlength按钮有disabled状态看起来天衣无缝。但前端校验只是用户体验的一部分任何请求都可以通过 curl、Postman、脚本绕过浏览器。服务端校验才是真正的安全边界。服务端校验通常做三件事非空校验content为 null、空串、全空格都不能入库。长度校验用 Unicode 码点数量而不是 Java 的char数量来判断因为一个 emoji 在 Java 里占两个char。字符范围校验根据业务决定是否允许控制字符、特殊符号、emoji。这里真正容易踩坑的地方是长度校验。很多后端同学用String.length()做限制用户发一条带 10 个 emoji 的消息实际码点可能只有 140但length()返回 150直接被误杀。更隐蔽的是数据库字段长度VARCHAR(140)在很多数据库里指 140 个字符而不是 140 个字节但索引长度又跟字节数挂钩。所以“长度”这个概念必须区分清楚。2.2 文本归一化让“长得不一样”的字符变成同一种文本归一化是指把语义相同但编码形式不同的字符统一成同一种表示。最典型的场景是全角字符。用户在中文输入法状态下输入英文、逗号、感叹号全是全角。视觉上没大问题但如果你用半角关键字hello去搜索根本匹配不上。再比如全角空格\u3000在正则表达式\s里并不会被匹配这会导致字符串分割、trim 全部失效。Unicode 定义了多种归一化形式开发中最常用的是 NFC 和 NFKC形式作用典型效果NFC分解后再重组把组合字符合成单字符e 重音符 →éNFD拆分成基础字符和组合标记é→e 重音符NFKC兼容性分解后再重组全角字母 → 半角字母①→1NFKD兼容性分解再拆开组合标记全角、角标数字全部标准化搜索、匹配、去重场景建议使用 NFKC。但要记住一个原则不要覆盖原始内容。更稳妥的做法是保留raw_content同时生成一份normalized_content用于检索和分析。这样既保证用户原文可追溯又让下游处理拿到干净的数据。2.3 emoji 与 UTF-8 的存储问题emoji 看起来是一个“字符”但在 Unicode 里对应的码点往往超过 UFFFF需要用代理对表示。在 UTF-8 编码下一个 emoji 通常占用 4 个字节。MySQL 里有个历史遗留坑utf8这个字符集实际上最多只支持 3 字节真正支持完整 Unicode 的是utf8mb4。如果你的表字符集是utf8mb3插入 emoji 时会报错或者被替换成?。从 MySQL 5.5.3 开始才引入utf8mb4所以你如果还在用 5.7 以下版本就需要额外注意。实际项目里更推荐直接使用 MySQL 8.0默认字符集已经是utf8mb4。不过即使数据库默认字符集是utf8mb4连接层也可能用了旧字符集导致最终落库还是乱码。判断是否支持 emoji 的简单方法是查看字符集的maxlen。utf8mb4的maxlen是 4utf8mb3是 3。确认连接层、库、表、列四个层级的字符集一致这是一个值得写进发布检查清单的步骤。2.4 脱敏与过滤星号不该污染原始数据很多系统的敏感词过滤流程是用户提交内容 → 正则或敏感词库匹配 → 将命中词替换成**→ 入库。这个流程从功能上没问题但从数据治理角度是糟糕的设计。原因很简单替换之后再入库原始内容就丢了。如果有一天你想做内容分析、用户投诉仲裁、误判申诉拿到的全是星号什么都查不出来。更现实的问题是敏感词库会持续更新今天不是敏感词的词明年可能变成需要审核的词。原始内容没了后续审核根本无法补做。正确做法是分层处理存储层保存用户原始输入raw_content最多增加一个flag字段标记是否命中敏感词。展示层把命中敏感词的词汇替换成**只影响用户的可见展示。审核层结合自动过滤和人工抽检形成完整的审核链路。这个思路不仅适用于文本也适用于图片、语音等信息。原始数据是最重要的资产任何处理都应该是可追溯、可恢复的。3. 环境准备与前置条件本文的示例代码以 Java 为主涉及 MySQL 建表不会依赖重量级框架方便你直接复制运行。推荐环境如下JDK 8 及以上代码风格是 Java 8 兼容的。Maven 3如果你想用javac直接编译也可以。MySQL 5.7 及以上建议 8.0。一个支持 UTF-8 的命令行终端或 IDE。版本不必和我这里完全一致重点是演示通用思路。可以先验证一下环境java -version mvn -version mysql --version如果本机没有安装 MySQL也可以用 Docker 临时启动一个docker run --name test-mysql \ -e MYSQL_ROOT_PASSWORDyour_password \ -e MYSQL_DATABASEmessage_db \ -p 3306:3306 \ -d mysql:8.0这里需要注意Docker 启动 MySQL 时MYSQL_DATABASE会自动创建数据库但字符集不一定是你想要的最好在建库时显式指定。4. 工程落地一条消息文本处理的最小链路这一节我们实现一条完整链路。整个过程分为四步接收消息 DTO做基础校验。对文本做 NFKC 归一化和控制字符清理。判断是否命中敏感词是否包含 emoji。长度预检后落库展示时再脱敏。4.1 第 1 步DTO 入参校验先定义一个简单的消息 DTO。// 文件路径src/main/java/com/example/textcheck/dto/MessageDTO.java package com.example.textcheck.dto; public class MessageDTO { private String content; public String getContent() { return content; } public void setContent(String content) { this.content content; } }然后是校验器。这里重点演示两个容易被忽略的点空值校验和码点数量校验。// 文件路径src/main/java/com/example/textcheck/validator/MessageValidator.java package com.example.textcheck.validator; import com.example.textcheck.dto.MessageDTO; public class MessageValidator { private static final int MAX_CODE_POINTS 1000; public static void validate(MessageDTO dto) { if (dto null || dto.getContent() null || dto.getContent().trim().isEmpty()) { throw new IllegalArgumentException(消息内容不能为空); } int codePointCount dto.getContent().codePointCount(0, dto.getContent().length()); if (codePointCount MAX_CODE_POINTS) { throw new IllegalArgumentException(消息长度不能超过 MAX_CODE_POINTS 个字符); } } }为什么用codePointCount而不是length()因为String.length()返回的是 UTF-16 的char数量。emoji 在 Java 内部用代理对表示一个 emoji 占两个char。如果产品说“最多 140 个字符”用户发一条带 20 个 emoji 的文本按length()算可能直接爆掉但实际用户只输入了 120 个可见字符。按码点统计更接近用户的真实感知。4.2 第 2 步文本清洗与归一化清洗工具类如下。// 文件路径src/main/java/com/example/textcheck/util/TextNormalizer.java package com.example.textcheck.util; import java.text.Normalizer; public class TextNormalizer { public static String normalize(String raw) { if (raw null) { return ; } // NFKC兼容性分解再重组全角转半角、兼容字符统一 String normalized Normalizer.normalize(raw, Normalizer.Form.NFKC); StringBuilder sb new StringBuilder(normalized.length()); for (int i 0; i normalized.length(); i) { char c normalized.charAt(i); // 移除控制字符但保留换行、回车、制表符 if (Character.isISOControl(c) c ! \n c ! \r c ! \t) { continue; } sb.append(c); } // 多个连续空白折叠成一个空格 return sb.toString().trim().replaceAll(\\s{2,}, ); } }这里的关键点是 NFKC。以全角英文为例经过 NFKC 后会变成hello全角空格\u3000也会被转换成普通空格。这样后续做搜索、匹配、关键词判定时就不会因为“看起来一样但编码不同”而失败。需要提醒的是这个工具类默认清理不可见控制字符但保留了换行和制表符。如果业务对换行敏感比如单行文本输入可以在调用时把换行也过滤掉。不同场景对空白符的策略不同建议把策略参数化不要写死。4.3 第 3 步敏感词判断与内容安全敏感词过滤是内容安全的一个重要环节但绝不是全部。一个合格的方案至少要包含匹配、标记、展示脱敏和人工审核。// 文件路径src/main/java/com/example/textcheck/filter/SensitiveWordFilter.java package com.example.textcheck.filter; import java.util.Collection; import java.util.Collections; import java.util.HashSet; import java.util.Set; public class SensitiveWordFilter { private final SetString sensitiveWords new HashSet(); public void loadWords(CollectionString words) { sensitiveWords.addAll(words); } public boolean containsSensitive(String text) { if (text null || text.isEmpty()) { return false; } for (String word : sensitiveWords) { if (text.contains(word)) { return true; } } return false; } public String mask(String text) { if (text null || text.isEmpty()) { return text; } String result text; for (String word : sensitiveWords) { result result.replace(word, repeatStar(word.length())); } return result; } private String repeatStar(int count) { StringBuilder sb new StringBuilder(); for (int i 0; i count; i) { sb.append(*); } return sb.toString(); } }上面的实现是演示版本的简单遍历真实场景下不建议用contains逐个命中性能不够。生产环境可以基于前缀树或 Aho-Corasick 自动机来构建敏感词匹配器把词库预加载到内存匹配时间复杂度接近线性。这是一个示例所以词库集合初始为空代表“词库由外部配置中心或合规规则维护”。强调一点真实系统的敏感词库不应该硬编码在代码里而是由独立的规则引擎管理周期性更新。4.4 第 4 步长度预检与落库最后一步是落库。这里用一个 JDBC 的简单版本演示目的是展示 SQL 参数占位符的用法绝不要用字符串拼接 SQL。// 文件路径src/main/java/com/example/textcheck/dao/MessageDao.java package com.example.textcheck.dao; import java.sql.Connection; import java.sql.DriverManager; import java.sql.PreparedStatement; public class MessageDao { public void save(String rawContent, String normalizedContent, boolean hasEmoji) throws Exception { String url jdbc:mysql://localhost:3306/message_db ?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/Shanghai; String user root; String password your_password; String sql INSERT INTO message_log (raw_content, normalized_content, raw_length, normalized_length, has_emoji) VALUES (?, ?, ?, ?, ?); try (Connection conn DriverManager.getConnection(url, user, password); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, rawContent); ps.setString(2, normalizedContent); ps.setInt(3, rawContent.length()); ps.setInt(4, normalizedContent.length()); ps.setBoolean(5, hasEmoji); ps.executeUpdate(); } } }存储原始内容raw_content和标准化内容normalized_content是刻意这样设计的。前者保证可追溯后者给搜索和分析用。你可能会问为什么不在查询时实时归一化因为文本量大了之后 后端文本处理四要素：校验、归一化、utf8mb4与脱敏
今晚见吗❓这是个坏主意对吗 今晚见吗⁉️**的 这很好❗️如果这条消息是用户在你开发的社区系统里提交的接下来会发生什么运气好它原样入库运气不好数据库直接报Incorrect string value弹幕接口超时内容审核服务把整段会话标记为异常甚至因为某个不可见字符导致下游 NLP 模型输出一个完全离谱的结果。很多后端开发看到这类输入的第一反应是“用户乱发、前端没拦住”但真正的问题往往在服务端文本没有被当作一种需要专门处理的数据类型。这篇文章会从一段“很乱”的文本出发把“异常文本从提交到落库”的完整链路拆开讲清楚。你会弄明白四件事服务端校验为什么不能省NFKC 归一化到底解决了什么问题emoji 为什么必须用 utf8mb4 存储以及敏感词过滤产生的**为什么不应该写回数据库。适合后端开发、IM/社区/评论系统开发以及正在做文本数据清洗和 NLP 特征工程的读者阅读。1. 这串“乱码消息”背后是后端文本处理的四个坑把上面这段消息拆开看它至少包含四个典型特征恰好对应后端文本处理的四个常见问题。第一消息里有大量重复语气词和符号。“今晚见吗”出现两次感叹号、问号、倒问号混在一起。这种文本如果直接存库后续做关键词搜索、重复消息识别、NLP 意图识别时都会被噪声干扰。你以为是用户表达方式的问题其实是数据标准化没有做。第二文本包含明确情绪和态度表达。“这是个坏主意对吗”“这很好”放在一起说明用户情绪是复杂的。对于评论系统或者智能客服系统这类文本是典型的需要做情感分析、内容预判的输入。但情感分析模型对噪声极其敏感一个全角标点、一个表情符号都有可能改变特征分布。第三**的里的星号非常关键。它通常意味着这段文本在到达你的服务之前已经经过了一次敏感词替换。也就是说你拿到的不是原始输入而是被“污染”过的数据。这种污染会导致一个很隐蔽的问题如果系统把**结果直接入库原始信息就永久丢失了后续想追溯、申诉、复核都无从下手。第四一堆 emoji 让文本的存储长度计算变得复杂。Java 的String.length()对 emoji 返回的是 2 而不是 1MySQL 的utf8又存不下 4 字节字符。如果设计阶段没有意识到这一点上线后就会遇到“表情变问号”“字符串长度超限”“索引失效”这一连串问题。所以这类文本问题不是加一个maxlength140就能解决的。服务端如果缺少一条完整的处理链路轻则数据不干净重则埋下 SQL 注入、存储型 XSS、下游模型失效的雷。2. 核心概念校验、归一化、编码与脱敏2.1 输入校验为什么必须在服务端再做一次校验的本质是“系统不接受它无法处理的数据”。很多团队只依赖前端校验输入框设置了maxlength按钮有disabled状态看起来天衣无缝。但前端校验只是用户体验的一部分任何请求都可以通过 curl、Postman、脚本绕过浏览器。服务端校验才是真正的安全边界。服务端校验通常做三件事非空校验content为 null、空串、全空格都不能入库。长度校验用 Unicode 码点数量而不是 Java 的char数量来判断因为一个 emoji 在 Java 里占两个char。字符范围校验根据业务决定是否允许控制字符、特殊符号、emoji。这里真正容易踩坑的地方是长度校验。很多后端同学用String.length()做限制用户发一条带 10 个 emoji 的消息实际码点可能只有 140但length()返回 150直接被误杀。更隐蔽的是数据库字段长度VARCHAR(140)在很多数据库里指 140 个字符而不是 140 个字节但索引长度又跟字节数挂钩。所以“长度”这个概念必须区分清楚。2.2 文本归一化让“长得不一样”的字符变成同一种文本归一化是指把语义相同但编码形式不同的字符统一成同一种表示。最典型的场景是全角字符。用户在中文输入法状态下输入英文、逗号、感叹号全是全角。视觉上没大问题但如果你用半角关键字hello去搜索根本匹配不上。再比如全角空格\u3000在正则表达式\s里并不会被匹配这会导致字符串分割、trim 全部失效。Unicode 定义了多种归一化形式开发中最常用的是 NFC 和 NFKC形式作用典型效果NFC分解后再重组把组合字符合成单字符e 重音符 →éNFD拆分成基础字符和组合标记é→e 重音符NFKC兼容性分解后再重组全角字母 → 半角字母①→1NFKD兼容性分解再拆开组合标记全角、角标数字全部标准化搜索、匹配、去重场景建议使用 NFKC。但要记住一个原则不要覆盖原始内容。更稳妥的做法是保留raw_content同时生成一份normalized_content用于检索和分析。这样既保证用户原文可追溯又让下游处理拿到干净的数据。2.3 emoji 与 UTF-8 的存储问题emoji 看起来是一个“字符”但在 Unicode 里对应的码点往往超过 UFFFF需要用代理对表示。在 UTF-8 编码下一个 emoji 通常占用 4 个字节。MySQL 里有个历史遗留坑utf8这个字符集实际上最多只支持 3 字节真正支持完整 Unicode 的是utf8mb4。如果你的表字符集是utf8mb3插入 emoji 时会报错或者被替换成?。从 MySQL 5.5.3 开始才引入utf8mb4所以你如果还在用 5.7 以下版本就需要额外注意。实际项目里更推荐直接使用 MySQL 8.0默认字符集已经是utf8mb4。不过即使数据库默认字符集是utf8mb4连接层也可能用了旧字符集导致最终落库还是乱码。判断是否支持 emoji 的简单方法是查看字符集的maxlen。utf8mb4的maxlen是 4utf8mb3是 3。确认连接层、库、表、列四个层级的字符集一致这是一个值得写进发布检查清单的步骤。2.4 脱敏与过滤星号不该污染原始数据很多系统的敏感词过滤流程是用户提交内容 → 正则或敏感词库匹配 → 将命中词替换成**→ 入库。这个流程从功能上没问题但从数据治理角度是糟糕的设计。原因很简单替换之后再入库原始内容就丢了。如果有一天你想做内容分析、用户投诉仲裁、误判申诉拿到的全是星号什么都查不出来。更现实的问题是敏感词库会持续更新今天不是敏感词的词明年可能变成需要审核的词。原始内容没了后续审核根本无法补做。正确做法是分层处理存储层保存用户原始输入raw_content最多增加一个flag字段标记是否命中敏感词。展示层把命中敏感词的词汇替换成**只影响用户的可见展示。审核层结合自动过滤和人工抽检形成完整的审核链路。这个思路不仅适用于文本也适用于图片、语音等信息。原始数据是最重要的资产任何处理都应该是可追溯、可恢复的。3. 环境准备与前置条件本文的示例代码以 Java 为主涉及 MySQL 建表不会依赖重量级框架方便你直接复制运行。推荐环境如下JDK 8 及以上代码风格是 Java 8 兼容的。Maven 3如果你想用javac直接编译也可以。MySQL 5.7 及以上建议 8.0。一个支持 UTF-8 的命令行终端或 IDE。版本不必和我这里完全一致重点是演示通用思路。可以先验证一下环境java -version mvn -version mysql --version如果本机没有安装 MySQL也可以用 Docker 临时启动一个docker run --name test-mysql \ -e MYSQL_ROOT_PASSWORDyour_password \ -e MYSQL_DATABASEmessage_db \ -p 3306:3306 \ -d mysql:8.0这里需要注意Docker 启动 MySQL 时MYSQL_DATABASE会自动创建数据库但字符集不一定是你想要的最好在建库时显式指定。4. 工程落地一条消息文本处理的最小链路这一节我们实现一条完整链路。整个过程分为四步接收消息 DTO做基础校验。对文本做 NFKC 归一化和控制字符清理。判断是否命中敏感词是否包含 emoji。长度预检后落库展示时再脱敏。4.1 第 1 步DTO 入参校验先定义一个简单的消息 DTO。// 文件路径src/main/java/com/example/textcheck/dto/MessageDTO.java package com.example.textcheck.dto; public class MessageDTO { private String content; public String getContent() { return content; } public void setContent(String content) { this.content content; } }然后是校验器。这里重点演示两个容易被忽略的点空值校验和码点数量校验。// 文件路径src/main/java/com/example/textcheck/validator/MessageValidator.java package com.example.textcheck.validator; import com.example.textcheck.dto.MessageDTO; public class MessageValidator { private static final int MAX_CODE_POINTS 1000; public static void validate(MessageDTO dto) { if (dto null || dto.getContent() null || dto.getContent().trim().isEmpty()) { throw new IllegalArgumentException(消息内容不能为空); } int codePointCount dto.getContent().codePointCount(0, dto.getContent().length()); if (codePointCount MAX_CODE_POINTS) { throw new IllegalArgumentException(消息长度不能超过 MAX_CODE_POINTS 个字符); } } }为什么用codePointCount而不是length()因为String.length()返回的是 UTF-16 的char数量。emoji 在 Java 内部用代理对表示一个 emoji 占两个char。如果产品说“最多 140 个字符”用户发一条带 20 个 emoji 的文本按length()算可能直接爆掉但实际用户只输入了 120 个可见字符。按码点统计更接近用户的真实感知。4.2 第 2 步文本清洗与归一化清洗工具类如下。// 文件路径src/main/java/com/example/textcheck/util/TextNormalizer.java package com.example.textcheck.util; import java.text.Normalizer; public class TextNormalizer { public static String normalize(String raw) { if (raw null) { return ; } // NFKC兼容性分解再重组全角转半角、兼容字符统一 String normalized Normalizer.normalize(raw, Normalizer.Form.NFKC); StringBuilder sb new StringBuilder(normalized.length()); for (int i 0; i normalized.length(); i) { char c normalized.charAt(i); // 移除控制字符但保留换行、回车、制表符 if (Character.isISOControl(c) c ! \n c ! \r c ! \t) { continue; } sb.append(c); } // 多个连续空白折叠成一个空格 return sb.toString().trim().replaceAll(\\s{2,}, ); } }这里的关键点是 NFKC。以全角英文为例经过 NFKC 后会变成hello全角空格\u3000也会被转换成普通空格。这样后续做搜索、匹配、关键词判定时就不会因为“看起来一样但编码不同”而失败。需要提醒的是这个工具类默认清理不可见控制字符但保留了换行和制表符。如果业务对换行敏感比如单行文本输入可以在调用时把换行也过滤掉。不同场景对空白符的策略不同建议把策略参数化不要写死。4.3 第 3 步敏感词判断与内容安全敏感词过滤是内容安全的一个重要环节但绝不是全部。一个合格的方案至少要包含匹配、标记、展示脱敏和人工审核。// 文件路径src/main/java/com/example/textcheck/filter/SensitiveWordFilter.java package com.example.textcheck.filter; import java.util.Collection; import java.util.Collections; import java.util.HashSet; import java.util.Set; public class SensitiveWordFilter { private final SetString sensitiveWords new HashSet(); public void loadWords(CollectionString words) { sensitiveWords.addAll(words); } public boolean containsSensitive(String text) { if (text null || text.isEmpty()) { return false; } for (String word : sensitiveWords) { if (text.contains(word)) { return true; } } return false; } public String mask(String text) { if (text null || text.isEmpty()) { return text; } String result text; for (String word : sensitiveWords) { result result.replace(word, repeatStar(word.length())); } return result; } private String repeatStar(int count) { StringBuilder sb new StringBuilder(); for (int i 0; i count; i) { sb.append(*); } return sb.toString(); } }上面的实现是演示版本的简单遍历真实场景下不建议用contains逐个命中性能不够。生产环境可以基于前缀树或 Aho-Corasick 自动机来构建敏感词匹配器把词库预加载到内存匹配时间复杂度接近线性。这是一个示例所以词库集合初始为空代表“词库由外部配置中心或合规规则维护”。强调一点真实系统的敏感词库不应该硬编码在代码里而是由独立的规则引擎管理周期性更新。4.4 第 4 步长度预检与落库最后一步是落库。这里用一个 JDBC 的简单版本演示目的是展示 SQL 参数占位符的用法绝不要用字符串拼接 SQL。// 文件路径src/main/java/com/example/textcheck/dao/MessageDao.java package com.example.textcheck.dao; import java.sql.Connection; import java.sql.DriverManager; import java.sql.PreparedStatement; public class MessageDao { public void save(String rawContent, String normalizedContent, boolean hasEmoji) throws Exception { String url jdbc:mysql://localhost:3306/message_db ?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/Shanghai; String user root; String password your_password; String sql INSERT INTO message_log (raw_content, normalized_content, raw_length, normalized_length, has_emoji) VALUES (?, ?, ?, ?, ?); try (Connection conn DriverManager.getConnection(url, user, password); PreparedStatement ps conn.prepareStatement(sql)) { ps.setString(1, rawContent); ps.setString(2, normalizedContent); ps.setInt(3, rawContent.length()); ps.setInt(4, normalizedContent.length()); ps.setBoolean(5, hasEmoji); ps.executeUpdate(); } } }存储原始内容raw_content和标准化内容normalized_content是刻意这样设计的。前者保证可追溯后者给搜索和分析用。你可能会问为什么不在查询时实时归一化因为文本量大了之后