4

之所以提出这个问题，是因为开发人员 Michael Rys 相当激进地拒绝将 CDATA 部分的解析包含在 FOR XML PATH 中，因为“您存储的数据中没有语义差异”。

我在 CDATA 节点和其他需要使用特殊或难看字符的内容中存储了 HTML 块。但是，我觉得没有资格挑战 Rys 有争议的断言，因为我想，在我为方便起见而使用 CDATA 的场景中，从技术上讲，他是正确的。

真正让我吃惊的是，当开发人员在互联网上寻求有关如何使用 FOR XML PATH 呈现 CDATA 段的建议时，受访者不断指示他们使用 FOR XML EXPLICIT，Rys 引用的 XML 呈现方法是“查询从地狱”。

如果我们真的可以在任何人可以建议的每个用例中不使用 CDATA，我想我们应该停止抱怨并从此拒绝 CDATA 的使用。但是，如果有明确定义的情况下 CDATA 是必不可少的，Rys 已经承诺他会将其烘焙到 FOR XML PATH 中，并在此问题的最顶部链接中继续前进。

那么它会是哪一个呢？CDATA 部分真的是过去的遗迹吗？或者 Rys 是否应该伸出手指并允许在 FOR XML PATH 中解析 CDATA？同时，在我们处理它的同时，是否有任何技巧可以让 FOR XML PATH 返回 CDATA 部分？

4

4 回答 4

3

CDATA 部分是不必要的。它们不是“过去的遗物”，因为它们一直是不必要的。

这并不意味着它们没有用。看看几乎任何编程语言或库，你都会发现很多你可以不用的东西，因为它们在语义上等同于其他东西，但如果有人坐在那里必须编写这些东西，它们就会很有用。

就此而言，即使使用程序化生产，也可以采用相反的方法并为每条 c 数据使用 CDATA 部分（臃肿，但它可以在其他地方提高效率）。

FOR XML PATH 不涉及一个人坐在那里必须编写这些东西。它是一种从 SQL 查询结果生成有效 XML 的方法。（这也不是解析 CDATA 部分的问题，而是生成它们 - 另一回事）。

当您想要真正精细的控制时，您不能真正抱怨 FOR XML EXPLICIT 是替代方案 - FOR XML EXPLICIT 有时使用起来如此讨厌的原因正是因为它为您提供了非常精细的控制。事实上，考虑一下他们是否首先添加了对 CDATA 部分的支持，然后添加了对其他所有其他似乎同样重要的调整和配置选项的支持。FOR XML EXPLICIT 需要多长时间才能成为自动选择，因为它比 FOR XML PATH 更直接‽</p>

CDATA 在四种情况下有用：

  1. 你正坐在键盘前自己输入这些东西。
  2. 您正在处理在不同时间设计的具有不同标准的不同技术的混合，并且这些技术将由不同的解析器以不同的方式解释（例如嵌入到 XHTML 中的 javascript - 尽管这里不是 100% 必要，否则它是一场噩梦）。
  3. 您试图用不理解 XML 的东西来解析 XML。
  4. 您正在尝试使用构建在解析器上的东西，该解析器允许区分 CDATA 部分和其他字符数据的低级访问，并且不恰当地使用该低级访问。

有趣的是，这四种情况也是禁止接受 CDATA 部分的四种情况。

案例 1 不适用于此处，它不是人工生成的代码。如果您正在做一些非常疯狂的事情，案例 2 可能适用于此。坦率地说，缺少 CDATA 部分是您最不担心的问题。切换到在查询中生成更简单的 XML 并将其转换到其他地方。案例 3 可能适用于此，但如果确实如此，向 SQL 人员抱怨是不公平的，当您应该向不&lt;example&gt;与<![CDATA[<example>]]>. 案例 4 可以在这里应用，但再次向编写错误代码的人抱怨，而不是向 SQL 人抱怨。

于 2010-12-01T12:30:01.963 回答
2

CDATA如果您不关心其中数据的语义（即您不需要解析它 - 它只是一系列字符）并且您不希望转义其中的任何 XML，则这些部分很有用.

根据w3的定义：

CDATA 段可以出现在任何可能出现字符数据的地方；它们用于转义包含字符的文本块，否则这些字符会被识别为标记。

来自维基百科：

XML 文档的新作者经常误解 CDATA 部分的目的，错误地认为它的目的是“保护”数据在处理过程中不被视为普通字符数据。一些用于处理 XML 文档的 API 确实提供了对 CDATA 部分的独立访问的选项，但这些选项的存在超出了 XML 处理系统的正常要求，并且仍然不会改变数据的隐含含义。字符数据是字符数据，无论它是通过 CDATA 节还是普通标记表示的。

CDATA 部分对于将 XML 代码编写为 XML 文档中的文本数据很有用。例如，如果希望用 XSL 排版一本书来解释 XML 应用程序的使用，那么出现在书中的 XML 标记将写入源文件的 CDATA 部分中。但是，CDATA 节不能包含字符串“]]>”，因此 CDATA 节不可能包含嵌套的 CDATA 节。使用 CDATA 节对包含三元组“]]>”的文本进行编码的首选方法是使用多个 CDATA 节，方法是在“>”之前拆分每个出现的三元组。例如，要编码“]]>”，可以这样写：

于 2010-12-01T11:44:46.070 回答
1

有趣的是，有人可以用这种异想天开的方法扔出一份非常有价值的标准。并不是每个人都将 XML 用于几百个字符的 HTML 或用于下拉列表的项目列表。

我们中的一些人实际上正在使用 XML 来交换数据，非常复杂的数据，如 CCD、CDA CDR，这些都是医疗保健领域的标准文档格式，并且在 ObamaCare 中变得越来越突出。这些文档结构的一部分包含附件，如 DiCOM 图像、PDF 和其他二进制数据，解析器不应读取 CDATA 定义存在的原因。

为什么我要支付解析器读取嵌入在 CCD 文档中的 3 兆字节 DiCom 图像的开销？当它来自原始数据并且是 XML 标准的一部分时，为什么我要被迫分离文档。我希望能够找到并恢复文档，并且是 XML 的内容。

这让我感到困惑，为什么你们都支持解析引擎不解析的数据。如果引擎看到 CDATA 忽略它，那很简单。有些人不需要它的持续争论是无关紧要的。它是标准的一部分，应该保持标准。如果他们想添加已调用的“功能”，则使用选项支持默认行为。

请停止解析 CDATA 并忽略它。

于 2013-02-22T22:50:48.597 回答
0

您是绝对正确的，CDATA 在许多情况下都是必不可少的，它们是 XML 标准的一部分，并且应该受到每个 XML 操作工具/方法的支持。但问题是 MS 通常不在乎 .. 你知道，“640kB 应该对每个人都足够了”这种方法。

编辑：关于 FOR XML EXPLICIT - 这是生成精确格式化的 XML 数据的最佳方法。是的，语法看起来有点痛苦和混乱，但是一旦你使用它几次，你就会钦佩它的美丽和力量。

于 2010-12-01T12:11:49.203 回答