【问题标题】:How to get case-insensitive elements in XML如何在 XML 中获取不区分大小写的元素
【发布时间】:2010-10-26 12:19:03
【问题描述】:

据我所知,XML 元素类型名称以及属性名称 区分大小写。

有没有办法或任何技巧来获取不区分大小写的元素?

说明: 通过 XSD 定义了一个语法,用于某些客户端上传 数据。用户 - 内容生成器 - 正在使用不同的 工具,但其中许多都使用纯文本编辑器或其他工具。有时,当这些人试图上传他们的文件时,他们会遇到不兼容错误。 这是一个常见的错误,他们混合了小写和大写标签,尽管它是 一直很清楚标签区分大小写。

我可以访问定义此语法的 XSD 文件,并且可以更改它。 问题是如何避免这种容易出错的小写/大写标签问题。

有什么想法吗?

提前致谢!

【问题讨论】:

  • 感谢您的回答。在这种情况下,不幸的是 XML 不是机器生成的。是手写的:-)
  • 将输入转换为小写不是一种选择吗?
  • 不,不是。用户可以通过 GUI 直接上传文件。
  • 解析输入文件并保存到目录?

标签: xml xsd case-sensitive


【解决方案1】:

如果我正确理解您的问题,则只能通过第 3 方解析工具在创建和上传之间更正大小写错误。

即XML 文件 > 针对 XSD 解析并更正 > 上传批准

您可以在运行时通过为您的客户端开发一个容器应用程序来创建他们的 XML 文件来执行此操作。或者,您可以在服务器端编写一个应用程序来获取上传的文件并检查语法。无论哪种方式,您都必须做出决定然后做一些工作!

很大程度上取决于问题的规模。如果您在 XSD 中的不同情况下有类似的标签,例如但是你收到了,那么你将需要一个基于节点计数等的复杂解决方案。

如果您完全被客户端使用随机大小写来对抗仅包含小写标签的 XSD,那么您应该能够解析文件并将所有标签一次性转换为小写。这是假设标签之间的内容是多写的,您不能只转换完整的文档。

您如何做到这一点取决于您的情况。显然,让客户对自己的提交进行错误检查会更容易。如果这不切实际,那么您需要在此过程中确定一个机会之窗,以便在遇到错误之前将文件转换为正确的格式。

有太多的方法可以在这里讨论。这主要取决于您可用的技能或资金。

【讨论】:

  • 你说的是对的。我正在寻找的是 XSD 级别的东西。我的意思是,如果我能在 XSD 级别解决这个问题,我宁愿避免更改服务器端方法。
  • 无论如何,感谢您的评论。似乎是在 XSD 级别没有办法。 +1
  • 很好的答案,非常符合我的意思! +1
  • 您的问题是您想使用 XSD 来强制未链接的文档完全遵循架构。如果没有某种形式的验证,您就无法做到这一点,这意味着要么向客户提供工具,要么验证和更正客户提交的内容。 XSD 本身纯粹是对 XML 文件中保存的数据结构和内容的描述。它背后的想法是,它允许您轻松地将各种数据集映射到单个 XML 文档(用于文档传输)。它不对文档本身执行任何操作。
【解决方案2】:

XPath/Xslt 处理器区分大小写。如果您指定了错误的大小写,他们将无法选择节点/属性。

如果你想输出节点名称并希望它是大写的,你可以这样做:

upper-case(local-name())

【讨论】:

    【解决方案3】:

    正如@Melkisadek 所说,XSD 验证的存在是有目的的。如果您允许用户上传带有无效 XML 的文件,那么当访问这些文件中的数据时,您的应用程序必然会失败。此外,让 XSD 验证输入 XML 模式的整个目的都落空了。如果您愿意放弃整个架构验证功能,那么您需要使用 XSLT 将所有标签转换为您想要的大写或小写(请参阅@Rashmi 的回答)。

    这类似于允许用户在社会安全号码输入字段中输入特殊字符,只是因为用户更愿意输入特殊字符(是的,这个例子很愚蠢,想不出更好的例子! )

    因此,在我看来,解决方案在于保持架构验证原样,但为用户提供一种在上传前验证架构的方法。例如,如果这是 Web 应用程序,您可以在页面上提供一个按钮,该按钮使用 Javascript 来根据您的架构验证文件。或者,仅在上传文件时在服务器上进行验证。在这两种情况下,请提供适当的反馈,例如错误实体所在的行号、字符位置以及标记错误的原因。

    【讨论】:

      【解决方案4】:

      理论上,您可以尝试破解 XML Schema 来验证大写错误的元素名称。

      这可以通过使用 XML Schema 中的 替换组 机制来完成。例如,如果您的架构已定义:

        <xsd:element name="foobar" type="xsd:string"/>
      

      那么您可以将以下内容添加到 XML 架构中:

        <xsd:element name="Foobar" type="xsd:string" substitutionGroup="foobar"/>
        <xsd:element name="FooBar" type="xsd:string" substitutionGroup="foobar"/>
        <xsd:element name="fooBar" type="xsd:string" substitutionGroup="foobar"/>
        <xsd:element name="FOOBAR" type="xsd:string" substitutionGroup="foobar"/>
      

      等等

      尝试并预测他们可能犯的错误。对于每个元素,可能有 2^n 种可能的情况组合,其中 n 是名称的长度(假设名称的每个字符都是一个字母)。

      在实践中,这太麻烦了,只会拖延问题而不是解决问题,而且可能行不通。如果用户没有意识到 XML 是区分大小写的,那么他们可能没有与开始标记的大小写匹配的结束标记,并且仍然无法验证。

      正如其他人所说,要么预处理提交的输入以修复案例,要么让用户在提交之前生成正确的输入。

      【讨论】:

      • 看来你只能在顶层以下的元素上这样做,否则你会得到s4s-att-not-allowed: Attribute 'substitutionGroup' cannot appear in element 'element'.
      【解决方案5】:

      简单的解决方案是在您从用户加载 xml 时将所有标签/属性发送到小写,然后才通过为所有小写标签/属性设计的 xsd 对其进行检查

      【讨论】:

        【解决方案6】:

        XML 通常是机器生成的。因此,在宽度&lt;RANdOm /&gt; 的情况下,您应该没有真正的问题。

        如果真正的问题是两个不同的系统正在生成两种不同类型的标签(&lt;Widget /&gt;&lt;widget /&gt;),我想您可以简单地在 XSD 中定义这两种情况。

        【讨论】:

          【解决方案7】:

          上传后,遍历 XML 文件(通过 DOM 或 SAX)并在验证之前修复大小写?

          【讨论】:

            猜你喜欢
            • 2011-09-14
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2012-02-03
            • 1970-01-01
            • 1970-01-01
            • 2021-11-01
            • 2015-04-08
            相关资源
            最近更新 更多