迁移服务至Windows10后编码问题导致字符串对比出现差异

问题根因解释 #

1. Â字符出现的原因
   xA0是不间断空格的Unicode码点（对应XML的 、HTML的 ），它用UTF-8编码时会生成两个字节0xC2 0xA0。如果你错误地用Latin-1（Windows ANSI编码的核心子集）解码这两个字节，0xC2会被识别为字符Â，0xA0还是显示为空格，就出现了你看到的 异常字符。
2. 记事本编码显示差异的原因
   Windows 7的记事本编码检测逻辑存在缺陷，无BOM的UTF-8文件大概率会被误识别为ANSI编码；Windows 10优化了编码检测逻辑，所以同一个无BOM的UTF-8文件会在两个系统上显示不同的编码，属于正常的系统特性差异，不是文件本身的问题。
3. 之前的尝试无效的原因
   Java的String本身是UTF-16编码的字符序列，你写的getBytes(StandardCharsets.UTF_8)再转回String的操作只是做了一次无差错的编码-解码循环，不会修改字符串的实际内容，所以没有任何效果。你修改后的nodeToString方法也是多余的，绕了一圈和原来的StringWriter版本输出完全一致。

修复方案 #

你的问题本质是字符串对比时的编码不统一：你读取本地文件用于对比时，用了Windows默认的ANSI编码，把UTF-8编码的0xC2 0xA0解码成了 两个字符，和内存里的单个xA0字符自然匹配不上。按以下步骤调整即可：

• 写入文件的逻辑保持不变，始终指定UTF-8编码写入即可，不需要调整nodeToString相关代码
• 读取本地文件做对比时，必须显式指定UTF-8编码，不要用系统默认编码：

// Java 11+ 简化写法
String fileContent = Files.readString(Paths.get("你的XML文件路径"), StandardCharsets.UTF_8);

// 低版本Java兼容写法
byte[] fileBytes = Files.readAllBytes(Paths.get("你的XML文件路径"));
String fileContent = new String(fileBytes, StandardCharsets.UTF_8);

• 如果业务允许替换不间断空格，也可以直接在返回的字符串里统一替换为普通空格，从根源避免编码歧义：

retVal = retVal.replace('\u00A0', ' ');

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