java `pattern`/`matcher` 在处理含unicode字符（如℃、Ω）的字符串时，若正则表达式未正确覆盖目标字符（如大小写不匹配），会导致 `find()` 误判成功但 `group()` 返回空或 `null`，且 `start()` 位置严重偏移——本质是匹配逻辑失败而非编码问题。
这个问题表面看似与Unicode编码（如UTF-8字节序列被String.length()按UTF-16代码单元计数）有关，实则核心在于正则表达式逻辑缺陷：原始模式 (?
关键误区在于：Matcher.find() 并未“误报成功”，而是严格按规则执行了「最长前缀匹配」。我们来拆解实际匹配过程：
- 字符串 "±1℃ ±5% 3kΩ" 经Java内部以UTF-16存储，Ω（U+03A9）是单个BMP字符，k 是ASCII 'k'（U+006B），均无代理对问题；
- 模式 (?:[0-9]*(\\.[0-9]+)?)([KM])?Ω 中，([KM])? 是可选组，当它不匹配时，引擎会尝试跳过该组，直接匹配后续的 Ω；
- 字符串末尾是 "kΩ"，其中 k 不满足 [KM]，于是 ([KM])? 匹配空字符串（即零宽度），紧接着尝试匹配 Ω —— 但注意：Ω 在字符串中实际是 \u03A9，而你的源码里写的 Ω 是否真为U+03A9？更可能的是——你复制粘贴的 Ω 实际是 欧姆符号 Ω（U+2126），它在Unicode中是独立字符，且不等于希腊大写字母 Omega（U+03A9）！
验证这一点：运行 System.out.println((int)'Ω'); —— 若输出 8486（即 0x2126），则说明你用的是U+2126；而正则中硬编码的 Ω 若是从编辑器直接输入，很可能也是U+2126；但若IDE/终端显示异常，或字符串从外部读入时发生编码转换（如ISO-8859-1误读UTF-8），就可能让 Ω 变成两个乱码字符（如 \u00CE\u00A9，即 Ω），这正是你charAt()输出中 char at 14: \u00ce 和 char at 15: \u00a9 的来源——说明字符串已被损坏。
✅ 正确做法如下：
立即学习“Java免费学习笔记（深入）”；
-
统一使用Unicode转义确保字面量精准（避免粘贴歧义）：
Pattern pattern = Pattern.compile("(?[0-9]*(?:\\.[0-9]+)?)(? [KkMm])?\\u2126"); // 或更稳妥：同时支持 U+03A9 和 U+2126 Pattern pattern = Pattern.compile("(? [0-9]*(?:\\.[0-9]+)?)(? [KkMm])?(?:\\u2126|\\u03A9)"); -
修正大小写敏感性（如原答案指出）：
// 错误：只匹配大写 "[KM]?Ω" // 正确：覆盖常见电阻单位 "[KkMm]?Ω" // 注意：Ω需确保是正确Unicode
-
验证字符串完整性（调试必做）：
System.out.printf("Actual Ω char: U+%04X%n", (int) test.charAt(test.length() - 1)); // 输出 2126 → 欧姆符号；输出 03A9 → 希腊Omega -
终极健壮方案：预处理 + 显式Unicode类
// 归一化欧姆符号（将U+2126转为U+03A9，或反之） String normalized = test.replaceAll("\\u2126", "\\u03A9"); // 或使用Unicode属性匹配（Java 7+） Pattern p = Pattern.compile("(?\\d+(?:\\.\\d+)?)\\s*(? [KkMm])?\\s*\\p{So}"); // \\p{So} 匹配Symbol, other（含Ω、℃等）
⚠️ 注意事项：
- String.length() 返回UTF-16代码单元数，对BMP字符（如k, Ω(U+2126), ℃）完全准确，本例偏移非长度计算错误所致；
- Matcher.start()/end() 基于String索引，只要字符串未损坏，位置就是可信的；
- group("name") 为 null 表示对应命名捕获组未参与匹配（即因条件不满足被跳过），不是“位置错”，而是“根本没捕获”。
总结：遇到 find() 成功但 group() 为空，优先检查正则逻辑（大小写、可选组边界、字符字面量真实性），而非假设编码故障；用 printf("U+%04X", (int)c) 定位真实字符，用 \uXXXX 替代不可见符号，可彻底规避此类陷阱。
