что на самом деле PCDATA и CDATA?
но потом кто-то сказал мне, что CDATA фактически разбирается или PCDATA на самом деле не разбирается. так что это немного путаница. Кто-нибудь знает, что такое реальная сделка?
Обновление. Я фактически добавил определение PCDATA в Википедии. поэтому не принимайте этот ответ слишком серьезно, так как это только мое грубое понимание этого.
6 ответов
Проще говоря, PCDATA означает Parsed Character Data. Это означает, что символы должны анализироваться синтаксическим анализатором XML, XHTML или HTML. ( < будет изменено на <, <p> будет считаться абзацем абзаца и т.д.). Сравните это с CDATA, где символы не обрабатываются с помощью анализатора XML, XHTML или HTML.
Термин CDATA, то есть символьные данные, используется для различных, но связанных целей в языках разметки SGML и XML. Термин означает, что определенная часть документа является общим символьным данным, а не несимметричными данными или символьными данными с более конкретной ограниченной структурой.
Анализируются как PCDATA, так и CDATA. Они являются символьными данными.
Оба они должны включать только допустимые символы. Например, если ваша кодировка документа — UTF-8, содержимое разделов CDATA должно оставаться действительным символом UTF-8. Поэтому случайные двоичные данные, вероятно, будут препятствовать правильному оформлению документа. Также разделы CDATA все еще разобраны, если только найти тег в конце раздела. Но другие подобные разметке символы, такие как <, > и и игнорируются и передаются как есть с помощью синтаксического анализатора.
OTOH в PCDATA litteral < и (и «или» в значениях атрибутов) должны быть экранированы, или они будут интерпретироваться как разметка. Объекты также будут расширены.
Итак, да, секции CDATA действительно разбираются. Я не уверен, почему вам сказали, что PCDATA не анализируется.
PCDATA — анализируемые данные символов
Данные о символах CDATA — (Unparsed)
- PCDATA — это текст, который будет анализироваться парсером. Теги внутри текста будут рассматриваться как разметка, и сущности будут расширены.
- CDATA — это текст, который не анализируется парсером. Теги внутри текста будут не обрабатываться как разметка, а сущности не будут расширяться.
По умолчанию все это PCDATA. В следующем примере игнорируется корень, будет проанализирован, и у него не будет контента, кроме одного ребенка.
Когда мы хотим указать, что элемент будет содержать только текст, а не дочерние элементы, мы используем ключевое слово PCDATA, потому что это ключевое слово указывает, что элемент должен содержать анализируемые символьные данные — то есть любой текст, кроме символов, чем (<), больше, чем ( > ), амперсанд (&), цитата (‘) и двойная кавычка («).
В следующем примере панель является CDATA и не анализируется и содержит контент «content!».
В SGML существует несколько моделей контента. Модель содержимого #PCDATA говорит, что элемент может содержать простой текст. «Разработанная» часть означает, что разметка (включая PI, комментарии и SGML-директивы) в ней анализируется вместо отображения в качестве исходного текста. Это также означает, что ссылки на сущности заменяются.
Другим типом модели контента, допускающей содержимое обычного текста, является CDATA. В XML модель содержимого элемента не может быть неявно установлена на CDATA, но в SGML это означает, что ссылки на разметку и сущности игнорируются в содержимом элемента. Однако в атрибутах типа CDATA заменяются ссылки на сущности.
В XML #PCDATA — единственная модель текстового контента. Вы используете его, если вообще хотите разрешить текстовое содержимое в элементе. Модель содержимого CDATA может использоваться явно через разметку блока CDATA в #PCDATA, но содержимое элемента не может быть определено как CDATA по умолчанию.
В DTD тип атрибута, который содержит текст, должен быть CDATA. Ключевое слово CDATA в объявлении атрибута имеет другое значение, чем раздел CDATA в документе XML. В разделе CDATA все символы являются законными (включая <, > , &, и «characters» ), за исключением тега «]] > » end.
#PCDATA не подходит для типа атрибута. Он используется для типа текста «листа».
Определение типа документа — DTD
Можно сказать, что XML документы состоят из элементов и атрибутов. В DTD описываются и некоторые другие объекты, опредеделения которых смотрите ниже, но документы всегда поддерживают эти две основные концепции.
По отношению к документу DTD могут быть и . Внутренние DTD описываются в непосредственно в файле XML документа вот так:
Строка <!DOCTYPE queue [ называется . За ключевым словом должно следовать имя корневого элемента XML документа (в примере — queue). Далее, в квадратных скобках следует список , и — именно из этих компонентов состоит XML документ. Заканчивает DTD последовательность ]>.
DTD может также располагаться и во внешнем файле. Внешние DTD делятся на системные (SYSTEM) и общедоступные (PUBLIC). В любом случае файл DTD должен иметь расширение . Связывание системного DTD и XML документа выглядит следующим образом:
В данном случае анализатору указывается, что DTD находится во внешнем файле, по адресу "./dtd/msg_queue.dtd". Существует ряд общеизвестных DTD, разработанных для определенных целей. В случае использования такого DTD его объявление будет иметь несколько другой вид:
На то, что DTD является общеизвестным, указывает ключевое слово . Рассмотрим поподробнее строку "-//W3C//DTD XHTML 1.1//EN". Если DTD является стандартом ISO, то данная строка начинается словом ISO. Если DTD не является стандартом ISO, но используемый стандарт был принят группой стандартизации, то DTD начинается со знака (+). Если же но не был принят официально группой стандартизации, то объявление следует начинать со знака (-). Далее, с разделителем (//) следуют владелец данного DTD, имя DTD и язык. Из приведенного примера видно, что используется DTD, не стандартизованное официально, принадлежащее компании , с именем .
Приведем несколько доводов в пользу внешних DTD:
- Внешние DTD могут быть общеизвестными (public).
- Внешние DTD позволяют отделить структуру от содержания. Вы можете изменить и расширить правила словаря, не открывая содержания XML документов.
- Можно однажды написанное DTD использовать во множестве документов.
Далее в уроке подробно рассматриваются элементы DTD.
Сущности
В языке XML есть возможность продекларировать фрагменты содержания, а затем ссылаться на них при необходимости, что позволяет сэкономить время и силы разработчикам. Объявляя сущность в DTD мы определяем ее имя и содержание, на которое она ссылается. Ссылаясь на сущность, мы заставляем анализатор заменить ссылку на содержимое сущности. Сущности бывают
- (parsed entity) — содержимое сущности анализируется, т.е, например, при встрече в нем ссылок на другие сущности, они так же замещаются их содержимым; разметка внутри таких сущностей так же интерпретируется.
- (unparsed entity) — это не обязательно текст в XML формате, или совсем не текст (графика или другое мультимедиа содержание).
Ниже приведен пример объявления и использования анализируемых сущностей author и copyright (обратите внимание: сущность copyright ссылается на author):
Строка <!ENTITY author "Иванов Иван Иванович"> объявляет сущность author со значением "Иванов Иван Иванович". Ссылка на сущность выглядит как символьная подстановка в HTML: &author;. При разборе документа анализатор встретит ссылку на сущность и заменит ее на значение сущности. В итоге документ примет следующий вид:
Из приведенного рисунка видно, что ссылка на сущность &author; была замененна ее содержимым "Иванов Иван Иванович", причем и в "теле" другой сущности — ©right;. Анализируемые сущности могут также содержать и разметку.
Внешние сущности
Текст замещения может содержаться во внешнем файле, тогда объявление сущности будет выглядеть так:
Вместо ключевого слова может быть использованно слово , в случае, если речь идет об общедоступной сущности (см. системные и общедоступные DTD).
В XML существует ряд предопределенных сущностей, служащих для преодоления ограничений, связанных с синтаксисом языка. Перечень их приведен в таблице ниже:
What is the use of PCDATA in XML?
By default everything in XML is parsed character data(#PCDATA), then why do we need to specify #PCDATA in DTD. Somebody please explain. Thanks.
1 Answer 1
I’m not sure which of the following questions you are asking.
Question 1: What is the point of having a #PCDATA keyword in content models?
As @mzjin has already pointed out, the #PCDATA keyword is used when declaring mixed content; it (or something logically equivalent to it) is needed in order to allow declarations to distinguish between elements which can contain character data, like
and elements which contain other elements, optionally separated by insignificant whitespace, but not character data, like
When you say «by default everything in XML is parsed character data», what do you mean? There is no ‘default’ declaration defined in XML for elements not declared in the DTD. Some processors may assume a declaration of that form for undeclared elements, in order to attempt to keep going while reading an invalid document, and that can be useful. But it’s not a rule defined by XML.
Question 2: why is it called ‘parsed’ character data, when all character data in an XML document passed through a parser and is thus necessarily ‘parsed’?
The keyword PCDATA , inherited from ISO 8879 (which defines SGML), does indeed stand for ‘parsed character data’, but its denotation is narrower than you appear to be thinking. It means character data in which all potential delimiters will be recognized, including
- <! for comments and CDATA sections (and, in SGML, also for conditional sections)
- < for start-tags and sole-tags
- </ for end-tags
- &# for numeric character references
- & for entity references
This property distinguishes parsed character data (in the technical sense) from two other kinds of character data, denoted by the keywords RCDATA (replaceable character data) and CDATA (just character data), in which different sets of delimiters are recognized. (RCDATA is part of SGML, but not of XML.)
In a CDATA marked section, for example, the only delimiter recognized is the end of the marked section, ]]> .
In an attribute declared CDATA, the only delimiters recognized are & , &# , and the closing quotation mark of the attribute-value specification (either » or ‘ ).
In an SGML document, marked sections can occur with the keyword RCDATA ; in them, entity references ( & , numeric character references ( &# ), and the marked-section end delimiter ( ]]> ) will be recognized, but not start- and end-tag open delimiters (and, if I’m reading 8879 right, also not marked-section open delimiters <
Анализируются как PCDATA, так и CDATA. Они оба персонаж поле.
Оба они должны включать только допустимые символы. Например, если кодировка вашего документа — UTF-8, содержимое разделов CDATA должно по-прежнему содержать действительные символы UTF-8. Таким образом, случайные двоичные данные, вероятно, помешают правильно сформировать документ. Также разделы CDATA по-прежнему анализируются, хотя бы для того, чтобы найти тег конечного раздела. Но другие подобные разметке символы, такие как <,> и &, игнорируются и передаются синтаксическим анализатором как есть.
OTOH в PCDATA litteral <и & (и ‘или «в значениях атрибутов) должны быть экранированы, иначе они будут интерпретированы как разметка. Сущности также будут расширены.
Так что да, разделы CDATA действительно разбираются. Я не уверен, почему вам сказали, что PCDATA не анализируется.
ответ дан 30 мая ’13, 19:05
PCDATA — проанализированные символьные данные
CDATA — (неразборчивые) символьные данные
- PCDATA — это текст, который будет проанализирован парсером. Теги внутри текста будут рассматриваться как разметка, а объекты будут расширены.
- CDATA — это текст, который будет не анализироваться парсером. Теги внутри текста будут не будут рассматриваться как разметка, и объекты не будут расширены.
По умолчанию все — PCDATA. В следующем примере, игнорируя корень, <bar> будет проанализирован, и у него не будет содержимого, кроме одного дочернего элемента.
Когда мы хотим указать, что элемент будет содержать только текст, а не дочерние элементы, мы используем ключевое слово PCDATA, потому что это ключевое слово указывает, что элемент должен содержать анализируемые символьные данные, то есть любой текст, кроме символов, меньших чем (< ), больше (>), амперсанд (&), кавычки (‘) и двойные кавычки («).
В следующем примере полоса — это CDATA, она не анализируется и имеет содержимое «<test>content!</test>» .
В SGML есть несколько моделей содержимого. Модель содержимого #PCDATA говорит, что элемент может содержать простой текст. Его «проанализированная» часть означает, что разметка (включая PI, комментарии и директивы SGML) в нем анализируется, а не отображается как необработанный текст. Это также означает, что ссылки на сущности заменяются.
Другой тип модели содержимого, допускающий использование обычного текстового содержимого, — это CDATA. В XML для модели содержимого элемента не может быть неявно установлено значение CDATA, но в SGML это означает, что разметка и ссылки на сущности игнорируются в содержимом элемента. Однако в атрибутах типа CDATA ссылки на сущности заменяются.
В XML #PCDATA — единственная модель текстового содержимого. Вы используете его, если хотите разрешить текстовое содержимое в элементе. Модель содержимого CDATA может использоваться явно через разметку блока CDATA в #PCDATA, но содержимое элемента не может быть определено как CDATA по умолчанию.
В DTD тип атрибута, который содержит текст, должен быть CDATA. Ключевое слово CDATA в объявлении атрибута имеет другое значение, чем раздел CDATA в документе XML. В разделе CDATA допустимы все символы (включая символы <,>, &, ‘и «), кроме конечного тега«]]> ».
#PCDATA не соответствует типу атрибута. Используется для типа «листового» текста.
Перед #PCDATA стоит хэш (также известный как «хэштег» или octothorp) просто по историческим причинам.