【问题标题】:XmlReader does not take doctype notation into regardsXmlReader 不考虑文档类型表示法
【发布时间】:2012-11-13 18:22:55
【问题描述】:

第一次在这些论坛上写作。不过已经读了很久了。

我有一个问题,尝试在 .Net 中使用 XmlReader 验证 Xml 文件。

Xml 文件:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE root [
  <!NOTATION png PUBLIC "-//W3C//NOTATION Portable Network Graphics//EN">
  <!ENTITY mypic SYSTEM "mypic.png" NDATA png>
]>
<root>
  <img ref="mypic" />
</root>

Xsd 文件:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema id="myschema"
    elementFormDefault="qualified"
    xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="img">
    <xs:complexType>
      <xs:attribute name="ref" type="xs:ENTITY" />
    </xs:complexType>
  </xs:element>

  <xs:element name="root">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="img" />
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

C#sn-p:

XmlReaderSettings settings = new XmlReaderSettings();
settings.ValidationEventHandler += settings_ValidationEventHandler;
settings.ValidationType = ValidationType.Schema;
settings.DtdProcessing = DtdProcessing.Parse;
settings.ValidationFlags |= XmlSchemaValidationFlags.ProcessIdentityConstraints
            | XmlSchemaValidationFlags.ProcessInlineSchema
            | XmlSchemaValidationFlags.ProcessSchemaLocation
            | XmlSchemaValidationFlags.ReportValidationWarnings;

using (XmlReader reader = XmlReader.Create("myschema.xsd")) 
{
    settings.Schemas.Add(XmlSchema.Read(reader, new ValidationEventHandler(settings_ValidationEventHandler)));
}

using (XmlReader reader = XmlReader.Create("mydata.xml", settings))
{
    while (reader.Read()) ;
}

我收到一个验证错误说明:

Reference to an unparsed entity, 'mypic'.

根据其他验证器进行验证,但不是根据 XmlReader。

我已经尝试了我能想到的一切,所以现在我向你们求助。 非常感谢任何帮助。

【问题讨论】:

    标签: c# .net xml validation xmlreader


    【解决方案1】:

    通过使用 Reflector,我发现 NOTATION 和 ENTITY 声明确实被解析了。

    验证器将找到您的 mypic 实体引用并将其视为外部且未解析,因为它具有非空 NDATA 声明。

    但是,我还发现验证器在遇到未解析实体引用时总是会发送对未解析实体的引用验证错误。

    我不明白为什么 Microsoft 将此报告为错误。在我看来,验证器应该忽略未解析的实体引用或将它们报告为警告,而不是错误。

    忽略来自验证器的这些错误应该是安全的,并且仍然认为 XML 是有效的,除非当然报告了任何其他错误。

    那么,如何判断上报的错误是否是可忽略的对未解析实体的引用-error?

    我看到三个选项:

    1. 检查错误消息是否以字符串Reference to an unparsed entity 开头。如果您的代码在非英语平台上运行,这将中断。

    2. 使用反射获取内部GetRes属性的值,看是否等于Sch_UnparsedEntityRef。如果 Microsoft 决定更改内部 API,这将中断。

    3. 序列化异常,判断序列化的res成员是否等于Sch_UnparsedEntityRef。如果 Microsoft 决定更改序列化格式,这将中断。

    所有这些选项都是“黑客”。第一个最有可能破裂。然而,第三个应该是安全的。 Microsoft 不太可能更改序列化格式,因为这可能会破坏与其他代码的兼容性。

    以下示例说明了如何确定是否忽略在 settings_ValidationEventHandler 方法中收到的验证异常。

    基于错误信息(不安全):

        static bool IsUnparsedEntityReferenceError_BasedOnMessage(
            XmlSchemaException error)
        {
            return error != null && error.Message.StartsWith(
                "Reference to an unparsed entity", StringComparison.Ordinal);
        }
    

    基于反射(相当安全):

        static readonly PropertyInfo GetResProp = typeof(XmlSchemaException)
            .GetProperty("GetRes", BindingFlags.NonPublic | BindingFlags.Instance);
    
        static bool IsUnparsedEntityReferenceError_BasedOnReflection(
            XmlSchemaException error)
        {
            return error != null && GetResProp != null && 
                "Sch_UnparsedEntityRef".Equals(GetResProp.GetValue(error, null));
        }
    

    基于序列化格式(最安全):

        static bool IsUnparsedEntityReferenceError_BasedOnSerializer(
            XmlSchemaException error)
        {
            if (error == null)
            {
                return false;
            }
            else
            {
                SerializationInfo info = new SerializationInfo(
                    typeof(XmlSchemaException), new FormatterConverter());
    
                error.GetObjectData(info, default(StreamingContext));
                return "Sch_UnparsedEntityRef" == info.GetString("res");
            }
        }
    

    【讨论】:

    • 感谢您提供非常全面的回答!我担心这是 XmlReader 的限制。这并不能解决我的问题,但它至少可以帮助我。我会将其标记为已接受,因为我认为没有更好的答案。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-03-06
    • 1970-01-01
    • 2015-01-08
    • 1970-01-01
    • 1970-01-01
    • 2018-01-26
    • 1970-01-01
    相关资源
    最近更新 更多