hexformat.parsehex无法解析带空格字符串，因默认只接受连续十六进制字符；需预处理去除空格等非十六进制字符，且输入长度须为偶数。
HexFormat.parseHex 为什么解析不了带空格的字符串
Java 17 的 HexFormat 默认只接受连续十六进制字符，遇到空格、换行或前缀（如 "0x"）直接抛 IllegalArgumentException。
- 常见错误现象：
HexFormat.of().parseHex("a1 b2 c3")报错 “Invalid hex character ' '” - 解决办法：先预处理——用
String.replaceAll("[^0-9A-Fa-f]", "")去除非十六进制字符 - 注意：大小写不敏感，但输入必须是偶数长度；奇数长度会报 “Odd number of hex digits”
- 性能影响很小，但频繁调用时建议复用正则
Pattern.compile("[^0-9A-Fa-f]")而非每次replaceAll
HexFormat.ofDelimiter() 在日志打印场景下的实际用法
想把字节数组转成带空格分隔的可读十六进制串（比如调试网络包），不能直接用 HexFormat.of()，得用带分隔符的变体。
-
HexFormat.ofDelimiter(" ").withUpperCase()生成大写+空格，例如"A1 B2 C3" - 分隔符支持任意字符串，包括
" "、"-"、"0x"（但后者会在每字节前加前缀，不是你想要的"0xA1 0xB2"形式） - 别误用
withPrefix("0x")配合ofDelimiter()：它会在整个结果前加一次前缀，不是每个字节都加 - 如果要每个字节带
"0x"前缀，得自己拼接：Arrays.stream(bytes).mapToObj(b -> String.format("0x%02X", b)).collect(Collectors.joining(" "))
HexFormat 与 Apache Commons Codec / Guava 的性能对比关键点
如果你项目里已经在用 Hex.encodeHexString() 或 BaseEncoding.base16()，迁移到 HexFormat 前得看清三点。
-
HexFormat是无状态、不可变对象，线程安全且轻量；而 Commons Codec 的Hex类是静态工具类，Guava 的BaseEncoding实例也推荐复用 - 吞吐量上三者差别不大，但
HexFormat在小数据（char[] 分配 - 兼容性陷阱：Commons Codec 默认小写，Guava 默认大写，
HexFormat.of()默认小写，但of().withUpperCase()才是显式大写——别靠默认行为做假设 - 没有回退机制：
HexFormat不提供类似 Commons 的decodeHex(String, Charset)，解码只认字节，不涉及字符编码
HexFormat.formatHex(byte[]) 返回的字符串是否可直接用于 Base64 场景
不能。这是个典型混淆点：formatHex() 输出的是十六进制字符串（如 "a1b2c3"），不是原始字节，不能再当二进制数据喂给 Base64 编码器。
- 错误用法：
Base64.getEncoder().encodeToString(hexFormat.formatHex(data).getBytes())—— 这是对十六进制字符串本身做 Base64，不是对原数据 - 正确链路：想存/传原始数据 → 直接 Base64；想存/传十六进制表示 → 就用
formatHex()字符串，别再转 Base64 - 如果协议强制要求“十六进制字符串 + Base64 包裹”，说明设计有问题，应沟通确认原始意图
- 额外提醒：
formatHex()结果不含换行、空格，是纯连续字符串，适合 URL 或 JSON 字段值
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
