Java十六进制转整数方法详解

Integer.parseInt("FF", 16) 抛 NumberFormatException 的主因是字符串含不可见字符或空格，而非进制错误；Java 要求输入严格无空白、无前缀、无非十六进制字符，需先 trim() 再解析。

Integer.parseInt("FF", 16) 为什么抛 NumberFormatException

核心问题不是进制写错了，而是字符串里混入了不可见字符或空格。Java 的 Integer.parseInt 对输入极其严格：开头结尾不能有空白，不能有前缀（如 "0x" 或 "0X"），也不能含非十六进制字符（包括全角字母、中文符号、BOM 头）。

常见错误现象：NumberFormatException: For input string: " FF" 或 "ff " —— 看似正常，实则首尾有空格；又或者从文件/HTTP 响应读出的字符串带 UTF-8 BOM（"\uFEFFFF"），直接解析必挂。

• 务必先调用 str.trim()，再检查是否为空
• 若来源不可控（如用户输入、日志提取），建议用正则预清洗：str.replaceAll("[^0-9a-fA-F]", "")（慎用，会删掉所有非十六进制字符，仅适用于纯数据提取场景）
• 遇到 "0x" 前缀？别手动截取，改用 Integer.decode(str)，它原生支持 "0xFF"、"#FF"、"FF" 三种格式

超过 int 范围的十六进制字符串怎么转

Integer.parseInt 只能处理 32 位有符号整数，即最大到 0x7FFFFFFF（2147483647）。一旦字符串表示的值 ≥ 0x80000000（比如 "FFFFFFFF"），就会因溢出抛异常，而不是返回负数——它根本不会尝试“补码解释”，而是直接拒绝。

使用场景：解析网络协议里的无符号 32 位字段、哈希摘要片段、内存地址等，这些本就不该被当“有符号 int”看待。

• 用 Long.parseLong(str, 16) 替代，只要不超过 0x7FFFFFFFFFFFFFFF 都安全
• 若确定是 32 位无符号值（如 "FFFFFFFF" → 4294967295），用 Integer.parseUnsignedInt(str, 16)（JDK 8+），它返回 int 类型但按无符号逻辑解析
• 极端情况（如 64 位以上十六进制），必须用 BigInteger：new BigInteger(str, 16)

大小写敏感吗？a-f 和 A-F 有区别吗

没区别。Integer.parseInt(str, 16) 内部对字母 a–f 和 A–F 一视同仁，全部映射为 10–15。这不是“兼容模式”，而是规范定义的行为。

但要注意：如果你后续要做字符串比较、缓存 key 或写入日志，大小写不统一可能引发隐性 bug。比如 "ab" 和 "AB" 解析结果相同，但作为 Map key 就是两个不同键。

• 若需标准化输出，解析后再用 String.format("%02X", value) 转成大写定长形式
• 避免用原始字符串做 equals 判断，优先比数值结果
• 注意 locale：String.toUpperCase() 在土耳其语环境下可能把 'i' 转成特殊字符，不要用它来“统一大小写”再解析

性能差异：parseInt vs decode vs valueOf

三者底层几乎一样，但语义和边界行为不同。Integer.valueOf(str, 16) 和 Integer.parseInt(str, 16) 在数值解析阶段完全共用同一套逻辑，区别只在最后一步：前者装箱，后者返基本类型。而 Integer.decode(str) 多一层前缀识别开销，但对不含前缀的字符串，它会 fallback 到 parseInt，实际差距可忽略。

真正影响性能的是字符串本身：长度越长、内容越不规则（如大量无效字符），失败路径越慢（异常构造成本高）。

• 已知格式干净（如固定 8 位 hex），直接用 parseInt 最直白
• 输入格式不确定（可能带 "0x"、"#"），选 decode，别自己写前缀判断
• 不需要装箱对象，就别用 valueOf，徒增 GC 压力
• 高频调用时，考虑缓存常用 hex 字符串的解析结果，避免重复计算

十六进制解析看着简单，但真实环境里最常栽在不可见字符、无符号边界和前缀处理上。别假设输入“应该”合规，先 trim，再判空，再 decode 或 parseUnsignedInt —— 这三步加起来不到十行，省去半夜查 log 的时间。