非法字符导致C#解析XML失败，常见于控制字符、编码不匹配或BOM处理不当；可通过预处理清理非法字符，如移除ASCII 0-31的不可见字符（保留\t、\n、\r），修复UTF-8字节序列，统一文本编码为UTF-8，避免混合编码输入。
在使用C#解析XML时，如果遇到“非法字符”错误，通常不是代码本身的问题，而是数据源中存在不符合XML规范的字符或编码不匹配导致的。这类问题常见于处理外部系统传入的XML文件、网络请求返回的数据或日志导出内容。下面分析其根源并提供有效的修复方法。
非法字符的常见来源
XML标准对允许的字符有严格限制。以下几类字符容易引发解析异常：
- 控制字符（Control Characters）： ASCII码0–31之间的字符（如\x00、\x01、\x1F），除了制表符（\t）、换行（\n）和回车（\r）外，其他均不允许出现在XML文本中。
- UTF-8中的非法字节序列： 数据虽然声明为UTF-8，但实际包含损坏的多字节序列（如被截断的中文字符），会导致XmlReader读取失败。
- BOM（字节顺序标记）处理不当： UTF-8 BOM（EF BB BF）虽合法，但在某些流处理场景下可能被误判为非法开头。
- 混合编码输入： 原始数据混用了GBK、ISO-8859-1等编码写入了UTF-8格式的XML中。
检查与清理非法字符的方法
在解析前预处理字符串可有效避免异常。推荐使用正则或遍历方式移除不可见控制字符：
string CleanInvalidXmlChars(string text)
{
// 移除XML不允许的控制字符，保留 \t, \n, \r
var validChars = new StringBuilder();
foreach (char c in text)
{
if (c == '\t' || c == '\n' || c == '\r' ||
(c >= 0x20 && c <= 0xD7FF) ||
(c >= 0xE000 && c <= 0xFFFD))
{
validChars.Append(c);
}
}
return validChars.ToString();
}
将原始XML字符串先通过此函数过滤后再交给XDocument.Parse()或XmlReader，能显著降低报错概率。
确保正确的编码读取方式
很多“非法字符”其实是编码识别错误造成的。例如文件是UTF-8但被当作ANSI读取，就会出现乱码和非法字节。
建议显式指定编码：
using (var stream = new FileStream("data.xml", FileMode.Open, FileAccess.Read))
using (var reader = new XmlTextReader(stream))
{
reader.Encoding = Encoding.UTF8; // 强制使用正确编码
var doc = new XmlDocument();
doc.Load(reader);
}
若不确定原始编码，可借助StreamReader自动检测：
using (var sr = new StreamReader("data.xml", Encoding.Default, true))
{
string content = sr.ReadToEnd();
// 再次调用CleanInvalidXmlChars(content)
XDocument doc = XDocument.Parse(CleanInvalidXmlChars(content));
}
从网络或数据库获取数据时的注意事项
HTTP响应可能未正确设置Content-Type中的charset，或者数据库字段存储时发生编码转换丢失。此时应：
- 查看响应头
Content-Type，确认服务器声称的编码。 - 若内容来自SQL Server，检查字段是否为
NVARCHAR（支持Unicode）而非VARCHAR。 - 下载文件后不要用记事本打开保存，这可能导致默认编码更改。
基本上就这些。关键是理解：XML解析器非常严格，任何不符合规范的字符都会直接抛出异常。提前清洗数据、明确编码路径，就能稳定解析绝大多数真实环境中的XML内容。
