C#写入XML与记事本保存XML的行为差异原因咨询

首先明确：这类差异和NTFS流没有直接关联，核心原因基本集中在以下两点：

• BOM（字节顺序标记）不匹配
  调用File.WriteAllText(filepath, xmlCode)时如果不手动指定编码，C# 默认会写入带BOM的UTF-8内容，文件开头会多3个不可见字节0xEF 0xBB 0xBF。如果你的XML内容开头没有匹配的编码声明，或者解析器版本较老不识别带BOM的XML，会直接把这三个字节判定为非法首字符，抛出解析错误。
  而Win10 1903及之后版本的记事本，默认保存UTF-8格式文件是不带BOM的，复制内容重存的过程会自动去掉文件头的BOM字节，解析器就能正常识别内容。
• 不可见控制字符/换行符不兼容
  如果拼接xmlCode时字符串开头混入了零宽空格、其他不可见控制字符，或者换行符使用了类Unix的\n（LF）而非Windows标准的\r\n（CRLF），严格模式的XML解析器也会报错。记事本保存文件时会自动过滤开头的无效控制字符、统一换行符格式，相当于对内容做了一次自动清洗，消除解析异常。

关于同事提到的NTFS流：NTFS的交换数据流（ADS）不会修改文件主内容流的字节，仅当文件带有网络来源标记的Zone.Identifier流时，可能触发系统权限拦截，但这类报错属于权限错误，和XML解析错误无关，基本可以排除。

1. 写入XML文件时显式指定无BOM的UTF-8编码，从根源避免BOM问题，参考代码：

using System.Text;

// 构造不带BOM的UTF-8编码实例
UTF8Encoding utf8WithoutBom = new UTF8Encoding(false);
File.WriteAllText(filepath, xmlCode, utf8WithoutBom);

2. 写入前预处理XML字符串：裁剪掉字符串开头的所有空白、不可见控制字符，确保<?xml ... ?>声明位于文件最起始位置。
3. 快速验证方式：将C#生成的文件、记事本另存的文件分别放入十六进制编辑器对比前几个字节，如果C#生成的文件前3字节为EF BB BF、记事本保存的文件无该段字节，即可确认是BOM导致的异常。

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