非法字符导致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 = 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内容。
以上就是C#解析XML时遇到“非法字符”？ 编码问题的根源与修复方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1442343.html
微信扫一扫 
支付宝扫一扫 
