character.isisocontrol()仅覆盖u+0000–u+001f、u+007f及部分不可靠的c1控制符，无法识别u+2028、u+2029等高危unicode分隔符，需结合显式检查与业务策略增强检测。
在 Java 中，Character.isISOControl() 是识别 ASCII 控制字符（U+0000–U+001F 和 U+007F）的有效工具，但**它不覆盖所有可能引发解析问题的控制符**。要真正拦截导致 JSON、XML、日志截断或数据库异常的“危险字符”，需结合 Unicode 范围判断与实际场景约束。
明确 isISOControl() 的覆盖范围
Character.isISOControl(char) 返回 true 仅当字符属于 ISO/IEC 6429 定义的 C0 控制码（U+0000–U+001F）、DEL（U+007F），以及部分 C1 控制码（U+0080–U+009F）——但注意：Java 8 及以后版本中，该方法对 C1 区域的返回值依赖底层平台，不可靠。因此不能单靠它捕获如 U+2028（行分隔符）、U+2029（段落分隔符）等现代文本中常见的“隐形破坏者”。
推荐的增强型检测逻辑
为稳妥拦截各类干扰解析的字符，建议组合使用以下策略：
- 用
Character.isISOControl(c)检测基础控制符（U+0000–U+001F, U+007F） - 显式检查常见“高危 Unicode 分隔符”：
c == '\u2028' || c == '\u2029' || c == '\u0085'（下一行、段落分隔、NEL） - 排除不可见但合法的空白符：保留
Character.isWhitespace(c)中的' '、'\t'、'\n'、'\r'等，除非业务明确禁止换行 - 对输入做预处理时，可统一替换或删除检测到的非法控制符，而非直接抛异常（避免拒绝服务）
实用拦截示例（过滤 + 替换）
以下方法将文本中所有潜在解析风险字符（含 ISO 控制符和关键 Unicode 分隔符）替换为空格，兼顾安全与可用性：
public static String sanitizeControlChars(String input) {
if (input == null) return null;
StringBuilder sb = new StringBuilder();
for (int i = 0; i
若需严格拒绝（如 API 入参校验），可改为抛出 IllegalArgumentException 并附带具体字符码位（(int)c），便于调试定位源头。
特别注意 JSON 和日志场景
JSON 规范（RFC 8259）明确禁止未转义的控制字符（U+0000–U+001F）出现在字符串中；而 Log4j、SLF4J 等日志框架遇到 \u2028 可能导致日志解析器切分行失败。因此，在序列化前调用上述过滤方法，或在接收外部输入（HTTP body、表单、文件读取）时立即清洗，比依赖 Jackson/Gson 的默认行为更可靠。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
