非法字符的xml分析错误

因此，我请求作为最后手段，因为我完全没有想法

我有一个Windows ASP.NET ASMX web服务应用程序，它返回带有- 姓名、地址、电子邮件。。。等

但是xml中的某些属性的编码非常奇怪，例如-&x1a我不知道编码发生在哪里。我假设在序列化过程中

我看到它是Windows-1252编码

我发现，在解析XML的过程中，在1252编码的位置出现了一个无效unicode字符的解析错误

---

如何成功解析它？你有什么建议

解析器是正确的，无论产生什么序列化都是错误的。与大多数C0/C1控制字符一样，它实际上是无效的，比这更糟糕的是：将a放入XML 1.0文件*，即使编码为字符引用，如&x1A；，格式也不正确

任何XML解析器都不会读取，也不应该读取。而你可以加入一些可怕的黑客来尝试过滤掉&x1A；在将序列传递给解析器之前，这种粗制滥造的方法在一般情况下是行不通的。应修复序列化程序以停止生成它们

实际上，我不知道在古代可怕的操作系统中经常用来标记文件结尾的字符如何进入ASP.NET应用程序使用的数据集中，但它似乎在名称、地址或电子邮件中没有任何有效的作用。也许你真的需要清理你的数据

---

*：如果在XML 1.1文档中编码为字符引用，则是合法的。如果您绝对必须通过XML往返控制字符，则必须使用XML1.1。尽管这可能会导致与旧的XML解析器的兼容性问题，而且您仍然不能使用U+0000空字符，因此您永远不会完全是二进制安全的。

感谢您的详细回答-我假定数据是作为word文件或类似文件的复制粘贴输入的。是的，这对于0x80-0x9F范围内的C1控制代码来说是很常见的，通常来自代码页1252智能引用错误解释为ISO-8859-1，但0x1A控制代码不用于任何文字，也不用于我能想到的任何其他常见的现代Windows应用程序，我无法控制数据的传输方式-这是进行骇人听闻的黑客攻击并将其从字符串中删除的唯一方法，或者是否有其他方法来表示它（例如在序列化之前）-检查字符串是否为UTF-8合法。这不是编码问题：字符U+001A在UTF-8中同样无效，ISO-8859-1或普通旧式7位ASCII。您可以删除字符串&x1A；使用一个简单的字符串替换，但所有使用字符串/正则表达式处理XML的尝试都有可能破坏不是标记的情况，例如在、或中。但您不能将此输入作为XML处理，因为有了此控制字符，它就不是XML了。如果它应该是XML，您需要找到负责生成它的一方并大声抱怨，直到他们修复它；字符转义/编码进入我们基于web的订单输入系统asp.net mvc 4/WCF，它是由我们的一位专家从Outlook复制/粘贴的。在outlook中，它看起来像是一个聪明的引用，有人试图指出英寸。它成功地保存到我们的数据库中，但是，当我们尝试使用CASTtheDataField作为XML从SQL中选择它时，我们确实会得到一个错误-fwiw我们的DB字段不是XML类型，即使我们存储在其中，因此通常成功的转换失败