2

我没有在网上找到任何关于 xml 标签长度限制的提及。我正在寻找构建 XML 模式，作为第三方向我们发送数据的规范。

Schema（和数据）应该符合我们的自定义本体/数据字典，它是分层的和用户可定制的。

自然映射用于层次结构中的节点，用于命名 XSD/XML 中的类型和标签。但是，因为本体中的叶节点名称不必是唯一的，所以我正在考虑将层次结构中节点的完整路径编码为标记名称，并针对 XML 词法规则进行适当的修改。

因此，如果我的本体有多个“lisa”节点，它们在层次结构中的不同位置表示不同的东西，我可以使用节点的完整路径来生成不同的 XML 类型/标签名称，这样你就可以拥有

 <abe_homer_lisa> simpsons lisa ... </abe_homer_lisa>
 <applei_appleii_lisa> ... apple lisa </applei_appleii_lisa>
 <mona_lisa> and paintings </mona_lisa>

...同一文件中任何不同“lisa”类型的数据，没有歧义。

我在网上找不到任何指定最大标签长度（或符合标准的引擎的最小支持标签长度）的东西。（这里很好地总结了 XML 的词法规则）

关于属性长度也有同样的问题，如果标准对属性没有规定限制，那么我怀疑标签是否有限制，但可能存在实际限制。

我怀疑即使是实际限制也会比我的需要大得多（我希望大多数时候事情会小于 255 个字符）；基本上，如果 Java XML 处理器、标准 ETL 工具和常见的 XSLT 处理器都可以处理比这大得多的标签，那么这将不是问题。

4

6 回答 6

7

我认为您不太可能找到无法处理 1K 字符名称的工具，此时您会遇到严重的性能和可用性问题，而不是硬限制。

但是你的设计是错误的。XML 是分层的，利用事实而不是试图与之抗争。

于 2013-01-11T14:06:43.553 回答
4

我所知道的标签名称长度没有限制，但根据尝试解析 XML 的工具，即使 XML 规范可能没有提及任何限制，也可能存在一些实现限制。

另一方面，为什么不使用 XML 的原生和固有的层次结构。为什么将所有内容编码为 <abe_homer_lisa> 而不是将其编码为：

<abe>
    <homer>
        <lisa>simpsons lisa</lisa>
    </homer>
</abe>
<applei>
    <appleii>
        <lisa> ... apple lisa </lisa>
    </applei>
</appleii>
于 2013-01-11T11:07:25.670 回答
3

我强烈建议使用已建立的 XML 机制来区分元素，即使用名称空间。这样你就会有例如

<lisa xmlns="http://example.com/simpsons">..</lisa>

<lisa xmlns="http://example.com/apple">...</lisa>

W3C 模式语言以及 XSLT 和 XPath 都完全支持名称空间。

于 2013-01-11T11:16:05.720 回答
0

根据上面 Michael Kay（XML 专家）和 Mihai Stancu 的评论，我会说我最初问题的答案是：

  • 没有官方限制
  • 绝对最低限度可能支持 1000 多个字符的工具
  • 在此之前可能会遇到性能问题[鉴于处理这些文件的 XML 工具必须对非常长的字符串进行大量的字符串索引和比较] 和可用性方式
  • XML 命名空间和/或使用文档树的结构来提供区分上下文可能是“唯一化”标签名称的更好方法

我正在回答关于合法标签长度的那个非常具体的问题，因为我发现同样的问题是关于属性长度而不是标签，我认为如果其他人用谷歌搜索它，可能值得有“一个”答案。感谢所有受访者。关于我的设计是否合理的有效点；我将在别处解释理由。

于 2013-01-14T14:10:59.797 回答
0

感谢那些指出可能有更明智的方法来解决潜在问题的人（确保 XML 模式中的类型/标记名称是唯一的）。

重新使用节点层次结构来提供上下文：我同意这通常是合适的。但是（我并没有真正解释我在 q 中的确切问题域）在这种特殊情况下，我必须处理的树结构数据字典中的用户可配置项分组是非常随意的，几乎与字典描述的数据中的关系。

所以在

 <abe>
   <homer>
     <lisa>lisa1</lisa>
   </homer>
 </abe>

例如，另一个 lisa 节点应该在同一个 homer 节点下，还是在不同的节点下？本垒打应该在同一个abe节点下吗？对于有问题的数据，这种区别或多或少是没有意义的：就像根据某本书碰巧引用的索引页对数据进行分组一样。我想我可以任意调用并将其锁定在 XSD 中。

如果使用 XSL 之类的东西来提取数据，那没关系，//abe/homer/lisa 将获取所有 lisa 节点，而不管它们是如何组合在一起的。在实践中，有人可能会从 CSV 文件或其他任何东西生成这些文件，所以我希望结构尽可能平坦。

命名空间同上：尽管它们是为此目的而设计的（为名称提供上下文并确保在将不同类型的数据捆绑在一个文件中时意外冲突不会导致歧义），但实际上它们会添加一个额外的层对于从源系统生成数据的人来说，这很复杂。

在我的确切情况下，我希望这个任意分组中的名称冲突不太可能（并且反映使用不当），因此只需要合理处理，而不会对大多数情况施加不当惩罚。

于 2013-01-14T15:00:10.033 回答
-1

与传统观点相反，我强烈建议不要使用所谓的 XML 命名空间机制。久而久之，它会给你带来痛苦。对命名空间说不。你不需要它们。

您认为元素可以通过它们的上下文（在这种情况下，通过它们的“路径”表示）来区分的直觉是正确的。但是，您将整个路径编码为元素名称的想法可能不是最佳的。考虑改为使用简单名称以及保存上下文或路径的属性。（将此属性命名为“上下文”或“路径”或任何更令人回味的东西！）这足以区分含义。[*]

对于不同的内容模型，您可以使用相同技术的变体。给每个不同的类型一个方便的名称，并在另一个名为“本体”的属性中记录“真实”名称。

至于您的问题，XML 规范对名称的长度没有任何固有的限制，尽管出于纯粹的技术原因，您可能会发现某些地方引用了 65536 个字符的限制。同样的“限制”也可能适用于属性值文字的长度。每个原子名称平均有 20 个字符，20 级层次结构仍然少于 500 个字节的路径，因此您可能无需担心。

[*] 注意：这种技术实际上很古老，但在 XML 思维空间中几乎完全被遗忘了。例如，在 HTML 中，有一个单一的元素类型被命名为涵盖所有类型的 GUI 控件，并且由于 ' '属性INPUT而没有混淆。type

于 2013-01-11T14:07:46.963 回答