非法字符的xml解析错误

发布时间：2020-12-16 07:48:15 所属栏目：百科来源：网络整理

导读：所以,我要求作为最后的手段,因为我完全没有想法. 我有一个Windows ASP.NET ASMX Web服务应用程序,它返回一个带有 – 的序列化Person对象 – 姓名,地址,电子邮件等但是xml中的一些属性编码非常奇怪,例如 – #x1a(我不知道编码发生的位置.我假设在序列化过程

所以,我要求作为最后的手段,因为我完全没有想法.

我有一个Windows ASP.NET ASMX Web服务应用程序,它返回一个带有 – 的序列化Person对象 –
姓名,地址,电子邮件等

但是xml中的一些属性编码非常奇怪,例如 – & #x1a(我不知道编码发生的位置.我假设在序列化过程中)

googling those characters我看到它是“Windows-1252”编码.

我发现,在解析XML时,问题出现在1252编码位置的“无效unicode字符”的解析错误.

我怎样才能成功解析它？你建议什么解决方案？

解析器是正确的,无论生成什么序列化都是错误的.与大多数C0 / C1控制字符一样,它是无效的 – 实际上,更糟糕的是：没有良好的形式 – 将 U+001A SUBSTITUTE放入XML 1.0文件(*),即使编码为字符引用,例如& #X1A ;.

没有XML解析器会读取它,也不应该读取它.虽然你可以设置一些可怕的黑客来试图过滤掉在将它们传递给解析器之前的序列,这样的粗暴黑客对于一般情况不起作用.应修复序列化程序以停止生成它们.

实际上我不知道角色(通常用于标记古老可怕的操作系统中的文件结尾)是如何进入ASP.NET应用程序使用的数据集中的,但它似乎不能在一个ASP.NET应用程序中扮演任何有效的角色.姓名,地址或电子邮件.也许您真的需要考虑清理数据.

(*：如果在XML 1.1文档中编码为字符引用,那将是合法的.如果您绝对必须通过XML往返控制字符,则必须使用XML 1.1.虽然这可能导致旧XML解析器的兼容性问题,你仍然不能使用U 0000 NULL字符,所以你永远不会完全是二进制安全的.)

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!