Java处理希腊语带重音元音编码异常及规范化实现方案

你最初推测的「不同字符集编码导致」并不准确，只要文本已经被正确解码为Unicode字符串，该现象的核心成因是Unicode标准定义的两种语义完全等价、但码位存储方式不同的归一化规则：

• NFC（标准预组合形式）：带附加符号（比如希腊语的重音）的字符会以单个独立码位存储，比如你观察到的单字符έ对应码位U+03AD，本身就集成了基础元音+重音的完整语义。
• NFD（标准分解形式）：带附加符号的字符会被拆分为「基础字符码位 + 独立组合附加符号码位」的序列存储，比如你看到的双字符版本έ，就是基础元音ε（U+03B5）+ 组合尖重音符号 ́（U+0301）两个独立码位拼接的结果。

不同来源的文本（比如不同操作系统输入法导出的内容、不同网页/文档的导出规则）可能默认采用不同的归一化形式，就会出现视觉上完全无差异，但底层码位序列、字符串长度、匹配结果完全不同的情况。这类问题不止存在于希腊语，所有带附加符号的文字（拉丁语、西里尔语、阿拉伯语、汉语拼音等）都存在同类等价表示差异，手动枚举替换的方式不可能覆盖所有场景。

JDK 1.6及以上版本内置了专门处理Unicode归一化的工具类java.text.Normalizer，不需要手动枚举任何字符映射，一行代码即可完成全场景的统一转换，将所有分解形式的带附加符号字符合并为单字符预组合形式：

import java.text.Normalizer;

// 将文本统一转换为NFC预组合形式，自动合并所有基础字符+组合附加符号为等价的单字符
String normalizedText = Normalizer.normalize(originalText, Normalizer.Form.NFC);

补充说明 #

• 该实现完全遵循Unicode官方的等价映射规则，除了希腊语重音元音，所有符合Unicode规范的带附加符号字符的形式不一致问题都可以统一解决，不存在枚举遗漏的问题。
• 如果业务场景需要反向转换（将单字符预组合形式拆分为基础字符+独立组合符号），只需要将第二个参数替换为Normalizer.Form.NFD即可。
• 不建议继续使用正则逐一枚举替换的方案：一方面覆盖范围极难补全，另一方面正则对多组合符号（比如一个字符同时加重音、分音符等多个附加符号）的边界识别很容易出现匹配错误。

内容的提问来源于stack exchange，提问作者NickAth