字符编码错误本身不直接构成安全漏洞，但会成为绕过校验、污染日志、干扰反序列化甚至触发rce的跳板；防御关键在于统一编码声明、强制utf-8、前置unicode标准化、隔离解码与业务逻辑，并构建编码感知的异常处理层。
字符编码错误本身不直接构成安全漏洞，但它会成为攻击链的“跳板”——比如绕过输入校验、污染日志、干扰反序列化边界，甚至在特定条件下配合其他缺陷触发远程代码执行。防住这类风险，关键不是只盯着“乱码”，而是切断编码歧义带来的逻辑失控。
统一所有环节的编码声明
Java中很多默认行为依赖系统区域设置（如String.getBytes()或new String(byte[])），而不同环境（开发机、测试服务器、容器）可能用GBK、ISO-8859-1或UTF-8，导致同一段代码表现不一致。
- 所有字符串与字节互转操作，必须显式指定编码：用
str.getBytes(StandardCharsets.UTF_8)代替str.getBytes() - HTTP请求解析时，强制设置Servlet容器的URIEncoding为UTF-8（Tomcat需在
server.xml中配置URIEncoding="UTF-8"） - Spring Boot项目，在
application.properties中添加：server.servlet.encoding.charset=UTF-8server.servlet.encoding.force=true
堵住编码歧义引发的校验绕过
攻击者可能利用编码转换差异，让一个字符串在解码前后呈现不同形态，从而绕过白名单正则或长度限制。例如，某些Unicode规范化形式（如NFD/NFC）会让“é”变成“e\u0301”，表面看是两个字符，实际语义相同。
- 对所有外部输入，在校验前先做Unicode标准化：
String normalized = Normalizer.normalize(input, Normalizer.Form.NFC); - 避免仅靠正则匹配原始字节流；若需处理二进制内容（如上传文件名），应先按约定编码（如UTF-8）解码为String，再校验
- 禁止用
new String(byte[])直接解析HTTP头或表单字段——这些字段的编码应由协议头（如Content-Disposition里的filename*=UTF-8''...）明确指定
隔离编码处理与业务逻辑
把“怎么解码”和“怎么处理”分开，避免因解码失败导致流程中断或异常泄露路径信息。
- 文件上传场景中，不要在Controller里直接调用
file.getOriginalFilename()后拼SQL或写日志——它可能已损坏。改用MultipartFile提供的getInputStream()读取原始字节，或通过Content-Disposition头提取RFC 5987格式的编码文件名 - 日志记录前，对敏感字段（如用户名、路径）做脱敏+编码归一化，防止日志注入或因编码错误写入非法字符导致日志服务崩溃
- 数据库字段若存文件名或路径，统一使用UTF-8建表，并在JDBC连接串中加上
useUnicode=true&characterEncoding=UTF-8
构建编码感知的异常防御层
当遇到MalformedInputException或UnmappableCharacterException，不能简单抛出500或打印堆栈——这会暴露服务端编码策略，还可能被用于探测系统环境。
- 全局捕获
CharacterCodingException子类，在日志中记录“编码不可识别”而非具体异常类型 - 对用户返回通用提示：“文件名包含不支持的字符，请使用英文或标准符号重试”
- 在反序列化入口（如JSON解析）启用严格模式：Jackson可配
JsonParser.Feature.STRICT_DUPLICATE_DETECTION，Gson可设Lenient=false，避免因编码错位导致结构解析偏移
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
