似乎 PCDATA 和 CDATA 的松散定义是
- PCDATA 是字符数据，但要被解析。
- CDATA 是字符数据，不会被解析。
但是后来有人告诉我，实际上已经解析了 CDATA 或者实际上没有解析 PCDATA ......所以这有点令人困惑。有谁知道真正的交易是什么？
更新：我实际上在维基百科上添加了 PCDATA 定义......所以不要太认真地对待这个答案，因为这只是我对它的粗略理解。
问问题
25010 次
6 回答
10
PCDATA 和 CDATA 都被解析。它们都是字符数据。
它们都必须只包含有效字符。例如，如果您的文档编码为 UTF-8，则 CDATA 部分的内容仍必须是有效的 UTF-8 字符。所以随机二进制数据可能会阻止文档格式正确。如果只是为了找到结束部分标记，仍然会解析 CDATA 部分。但是其他类似标记的字符，如 <、> 和 & 被解析器忽略并按原样传递。
PCDATA 文字<和&（和'/或"属性值）中的 OTOH 必须转义，否则它们将被解释为标记。实体也将扩大。
所以是的，CDATA 部分确实被解析了。我不确定为什么你被告知 PCDATA 没有被解析。
于 2009-05-14T10:59:01.903 回答
7
于 2009-05-13T13:20:07.890 回答
3
- PCDATA 是将由解析器解析的文本。文本内的标签将被视为标记，实体将被展开。
- CDATA 是不会被解析器解析的文本。文本内的标签 不会被视为标记，实体也不会被展开。
默认情况下，一切都是 PCDATA。在下面的例子中，忽略根，<bar>将被解析，它没有内容，只有一个孩子。
<?xml version="1.0"?>
<foo>
<bar><test>content!</test></bar>
</foo>
当我们要指定一个元素只包含文本，不包含子元素时，我们使用关键字PCDATA，因为这个关键字指定元素必须包含可解析的字符数据——即除小于(< ) 、大于 (>) 、和号 (&)、引号 (') 和双引号 (")。
在下一个示例中， bar 是 CDATA，未进行解析，并且具有 content "<test>content!</test>"。
<?xml version="1.0"?>
<foo>
<bar><![CDATA[<test>content!</test>]]></bar>
</foo>
SGML 中有几个内容模型。#PCDATA 内容模型表示元素可能包含纯文本。它的“已解析”部分意味着其中的标记（包括 PI、注释和 SGML 指令）被解析而不是显示为原始文本。这也意味着实体引用被替换。
另一种允许纯文本内容的内容模型是 CDATA。在 XML 中，元素内容模型可能不会隐式设置为 CDATA，但在 SGML 中，这意味着在元素的内容中忽略了标记和实体引用。然而，在 CDATA 类型的属性中，实体引用被替换。
在 XML 中，#PCDATA 是唯一的纯文本内容模型。如果您想在元素中允许文本内容，您可以使用它。CDATA 内容模型可以通过#PCDATA 中的 CDATA 块标记显式使用，但默认情况下元素内容可能不会定义为 CDATA。
在 DTD 中，包含文本的属性类型必须是 CDATA。属性声明中的 CDATA 关键字与 XML 文档中的 CDATA 部分具有不同的含义。在 CDATA 部分中，所有字符都是合法的（包括 <、>、&、' 和“字符），除了“]]>”结束标记。
#PCDATA 不适用于属性的类型。它用于“叶子”文本的类型。
仅出于历史原因，#PCDATA 前面带有一个散列（也称为“hashtag”或 octothorp）。
于 2012-07-24T05:26:29.920 回答
1
你的第一个定义是正确的。
PCDATA 被解析，这意味着实体被扩展并且文本被视为标记。XML 解析器不解析 CDATA。
于 2009-05-13T13:21:30.417 回答
0
如果在 XHTML DTD 中只有元素默认设置为 CDATA，它会节省很多丑陋的手动覆盖……为什么脚本块会包含其他元素？如果有这样的元素，它们将由 JS 解释器在 DOM 操作操作中处理——在这种情况下，XML 解析器在文档插入和呈现之前仍应完全忽略它们。我想它可能是为了强制使用外部脚本资源文件而设计的，这最终是一件好事。
于 2013-03-12T09:38:36.543 回答