Question

似乎PCDATA和CDATA的宽松定义是

PCDATA是字符数据，但是要解析。
CDATA是字符数据，不是要解析。

然后有人告诉我CDATA实际上已被解析或者PCDATA实际上没有被解析...所以这有点混乱。有谁知道真正的交易是什么？

更新：我实际上在维基百科上添加了PCDATA定义...所以不要太认真地回答这个问题，因为这只是我对它的粗略理解。

Answer 1

来自WIKI：

简单来说，PCDATA代表Parsed Character Data。这意味着字符将由XML，XHTML或HTML解析器解析。（<将更改为＆lt;，<p>将被视为段落标记等。将其与CDATA进行比较，其中字符不由XML，XHTML或HTML解析器解析。

CDATA

术语CDATA，意思是字符数据，用于标记语言SGML和XML中的不同但相关的目的。该术语表示文档的某一部分是一般字符数据，而不是具有更具体，有限结构的非字符数据或字符数据。

Answer 2

解析PCDATA和CDATA。它们都是字符数据。

它们都必须只包含有效字符。例如，如果您的文档编码是UTF-8，则CDATA部分的内容仍必须是有效的UTF-8字符。因此，随机二进制数据可能会阻止文档格式正确。此外，CDATA部分仍然被解析，如果只是为了找到结束部分标记。但是其他类似标记的字符，例如＆lt;，＆gt;和＆amp;被解析器忽略并按原样传递。

PCDATA中的OTOH

和＆amp; （和属性值中的'或'）必须进行转义，否则它们将被解释为标记。实体也将被扩展。

所以是的，确实解析了CDATA部分。我不知道为什么你被告知虽然没有解析PCDATA。

Answer 3

PCDATA - 解析字符数据

CDATA - （未分析）字符数据

http://www.w3schools.com/XML/xml_cdata.asp

Answer 4

PCDATA是将由解析器解析的文本。文本内的标签将被视为标记，实体将被扩展。
CDATA是解析器不解析的文本。文本里面的标签会不被视为标记，实体不会被扩展。

默认情况下，一切都是PCDATA。在下面的示例中，将忽略根，将解析它，它将没有内容，但只有一个子。

<?xml version="1.0"?>
<foo>
<bar><test>content!</test></bar>
</foo>

当我们想要指定一个元素只包含文本而没有子元素时，我们使用关键字PCDATA，因为该关键字指定该元素必须包含可解析的字符数据 - 即除了字符之外的任何文本 - 比（＆lt;），大于（＆gt;），＆符号（＆amp;），引号（'）和双引号（“）。

在下一个示例中，bar是CDATA，未解析，内容为“content！”。

<?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部分，除了“]]＆gt;”结束标记之外，所有字符都是合法的（包括＆lt;，＆gt;，＆amp;，'和'字符）。

#PCDATA不适合属性的类型。它用于“叶子”文本的类型。

由于历史原因，＃pCDATA以哈希（也称为“哈希标签”或octothorp）为前缀。

Answer 5

您的第一个定义是正确的。

解析PCDATA，这意味着实体已展开，并且该文本被视为标记。 CDATA不会被XML解析器解析。

Answer 6

如果在XHTML DTD中默认情况下只将元素设置为CDATA，则会节省大量难看的手动覆盖...为什么脚本块会包含其他元素？如果存在这样的元素，它们将由JS解释器在DOM操作操作中处理 - 在这种情况下，在文档插入和呈现之前，XML解析器仍应完全忽略它们。我想它可能是为了强制使用外部脚本资源文件而设计的，这最终是一件好事。

实际上PCDATA和CDATA是什么？

6 个答案: