Xml у рядку doctype з'являються дужки. Мова XML - Documents Type Definitions (DTD). Зумовлені сутності в xml

Шпаргалка по DTD .

DTD – Один із способів формалізованого опису схеми документа XML , зробленого мовою, зрозумілою програмі-аналізатору

В даний час йде відмова від використання DTD на користь XSD (XML Schema Definition ), по ряду причин:

  • DTD використовує відмінний від XML синтаксису.
  • Відсутня типізація вузлів.
  • Відсутня підтримка просторів імен.

Тим не менш, цей спосіб ще широко застосовується оскільки є більш простим і зручним для опису нескладних схем документів.

КОНСТРУКЦІЇ DTD

Опис схеми складається з оголошень розмітки ( markup declaration ), що починаються з пари символів “ ” далі йде одне із слів:

  • ELEMENT (Вказує, що оголошується елемент )
  • ATTLIST (список атрибутів )
  • ENTITY (сутність )
  • NOTATION (позначення )

оголошення розмітки закінчується “ > ”

ОГОЛОШЕННЯ ТИПУ ЕЛЕМЕНТУ

(має бути описаний кожен елемент документа)

Вміст:

  • EMPTY – порожній (наприклад
    )
  • ANY - будь-який вміст (зустрічається рідко)
  • (#PCDATA) – лише символьні дані
  • (список імен вкладених елементів ч.з. кому) – вкладені елементи мають слідувати у документі у тому порядку, в якому вони перераховані в оголошенні. Оголошується лише один рівень вкладеності. Елементи можна групувати дужками.
    Використання роздільника “| ” між елементами вказує, що є один із розділених елементів.
    Після елементів або дужок:
    • “? ” - зустрічається 0 або 1 раз
    • “* ” - 0 або кілька разів
    • “+ ” - 1 або кілька разів

ОГОЛОШЕННЯ АТРИБУТІВ

Атрибути оголошуються після оголошення елемента. Усі атрибути одного елемента оголошуються одразу, одним списком.

Для кожного атрибута записується його ім'я, тип та ознака обов'язковості.

Типи атрибутів:
  • CDATA – (Character set of data ) рядок символів
  • Список значень атрибуту в дужках, перелік чз “|”
  • ID – унікальний ідентифікатор
  • IDREF – ідентифікатор, що містить одне із значень атрибуту ID , ісп як посилання на ін елементи
  • IDREFS – ідентифікатор, що містить набір значень атрибуту типу ID , перерахованих через пробіл, так само ісп як посилання відразу на кілька елементів.
  • ENTITY - Ім'я сутності, що не перевіряється аналізатором ( оголошені в тому ж описіDTD )
  • ENTITIES - Імена не перевіряються аналізатором сутностей.
  • NMTOKEN – слово, що містить лише символи, які застосовуються в іменах ( імена інших елементів або атрибутів, наприклад, щоб посилатися на них)
  • NMTOKENS – слова, перелічені через прогалини
  • NOTATION - Позначення ( позначення, розшифровані в описіDTD)
  • NOTATIONS – список нотацій
ознака обов'язковості:
  • Значення атрибуту за замовчуванням– вказується в лапках і означає, що атрибут необов'язковий.
  • # REQUIRED– атрибут треба обов'язково записувати у елементі.
  • # IMPLIED– атрибут необов'язковий, він не має значення за замовчуванням.
  • # FIXED- У атрибута є тільки одне значення, кіт записується відразу через пропуск.

При використанні простору імен треба завжди вказувати уточнене ( QName), а чи не локальне ім'я.

Атрибути не входять у простір стандартних імен.

Атрибути “ xml:lang ” та “ xml:space ” також повинен бути оголошений у DTD у разі їх застосування

ОГОЛОШЕННЯ СУТНОСТЕЙ

(починаються з “&”, а закінчуються “;”)

Внутрішні сутності- Задаються при оголошенні сутності.

- Можна застосовувати далі в самому DTD нижче за оголошення.

Зовнішні сутності– містяться в окремому файлі або вбудовані у програму-аналізатор.

Параметризовані сутності– ісп тільки всередині опису DTD

Сутності діляться на розбираемые( parsed ) і не розбираються ( unparsed ). Розбираються представляє собою фрагмент документа XML або цілий документ та підлягають обробці програмою-аналізатором після підстановки. Після підстановки розбирання сутність стає частиною XML документа.

Двійковий програмний код, креслення, зображення та ін. не треба обробляти засобами XML , Для цього сутність треба оголосити не розбирається. Для цього в кінці оголошення сутності робиться позначка “ NDATA ” та вказується позначення ( notation ) об'єкта, що вставляється.

ПОПЕРЕДЖЕНІ СУТНІСТЬ У XML

ОГОЛОШЕННЯ ПОЗНАЧЕННЯ ( NOTATION)

Оголошуються подібно до сутностей, також можуть бути внутрішніми і зовнішніми.

Внутрішня

Зовнішня

SYSTEM | PUBLIC - в даному випадкурівнозначні т.к. у public не обов'язково загальновідоме посилання.

РОЗМІЩЕННЯ DTD

Або в окремому файлі “ *.dtd ” вказавши його ім'я у лапках у другій частині прологу DOCTYPE або включити опис безпосередньо в другу частину прологу, уклавши його в квадратні дужки.

]> бла

Використовуйте для визначення структури XML-документів XML-схеми замість DTD

XML-схема має більше потужними можливостяминіж DTD. Для ілюстрації переваг використання механізму XML-схем у перших трьох лістингах порівнюються різні способиподання елементів. Наведена витримка з XML-документа. У показані два елементи, оголошені в синтаксисі DTD, а представлений синтаксис, відповідний XML-схемі. Зверніть увагу, що синтаксис у Лістингу 3 подібний до синтаксису XML. При використанні схеми валідуючий парсер може виконати перевірку, чи є елемент InvoiceNo позитивним цілим числом, і чи складається ProductID із заданого набору символів (шість цифр і однієї літери від A до Z). Парсер, що обробляє DTD-визначення, може лише підтвердити, що ці елементи є рядками.

Лістинг 1: Фрагмент документа XML
123456789 J123456
Лістинг 2: Фрагмент DTD, що описує елементи з Лістингу 1
Лістинг 3: Фрагмент XML-схеми, який описує елементи з Лістингу 1

Використання просторів імен у XML-схемі

Обмеження DTD

Незважаючи на те, що DTD служать розробникам SGML і HTML як механізм опису структурованої інформаціїось уже протягом 20-ти років, DTD мають деякі обмеження в порівнянні з XML-схемами.

Згідно DTD елементможе бути представлений одним із трьох способів:

  • Текстовий рядок
  • Текстовий рядок, змішаний з іншим дочірнім елементом
  • Набір дочірніх елементів

DTD не має синтаксису XML і пропонує лише обмежену підтримку для типів та просторів імен.

При спільній роботі одна сторона може обробляти документи інших сторін, і різні сторони можуть представляти свої елементи даних по-різному. Більше того, в окремому документі їм може знадобитися незалежно один від одного посилатися на елементи з однаковим ім'ям, створені різними сторонами. Використання XML-схеми дозволяє розрізняти визначення з тим самим ім'ям за допомогою визначення різних просторів імен.

Така схема XML визначає набір нових імен, таких як імена елементів, типів, атрибутів, груп атрибутів, чиї визначення та оголошення описані у схемі. В імена визначаються як InvoiceNo, ProductID та ProductCode.

Імена, визначені у схемі належать так званому цільового простору імен. Саме собою простір імен є фіксованим, довільним ім'ям, яке має відповідати синтаксису URL. Наприклад, простір імен для схеми, представленої в , можна задати так: http://www.SampleStore.com/Account .

Синтаксис оголошення простору імен іноді може спантеличити. Оголошення починається з http:// , проте воно не посилається на файл із описом схеми. Насправді, посилання http://www.SampleStore.com/Account взагалі не веде на жодний файл, а тільки на призначене ім'я.

Визначення та оголошення у схемі можуть посилатися на імена, які можуть належати іншим просторам імен. У цій статті ми посилаємось на такі простори імен як на вихідні простори імен. У кожній схемі може бути визначено один цільовий простір імен та можливо безліч вихідних просторів імен. Взагалі, кожне ім'я у заданій схемі належить певному простору імен. Імена простору імен можуть бути досить довгими, проте їх можна скоротити за допомогою синтаксису оголошення xmlns у документі XML-схеми. Всі ці концепції проілюстровані у .

Лістинг 4: Цільовий та вихідний простір імен

У XML-схемі, представленій з простором імен targetNamespace є http://www.SampleStore.com/Account , воно містить імена InvoiceNo , ProductID і ProductCode . Імена schema , element , simpleType , pattern , string і positive-integer належать вихідному простору імен http://www.w3.org/1999/XMLSchema , яке скорочується як xsd шляхом оголошення xmlns . У псевдонімі xsd немає нічого особливого, можна вибрати інше ім'я. Для зручності та простоти в частині статті, що залишилася, ми будемо використовувати префікс xsd для посилання на простір імен http://www.w3.org/1999/XMLSchema , пропускаючи уточнення xsd в деяких частинах коду. У нашому прикладі targetNamespace також є одним з вихідних просторів імен, оскільки ім'я ProductCode використовується у визначенні інших імен.

Малюнок 1: Простір імен для Лістингу 4
Лістинг 5: Безліч вихідних просторів імен, імпорт простору імен

Визначення елементів

Визначенням елемента полягає у визначенні його імені та моделі контенту. У схемі XML модель контенту елемента визначається його типом. Отже, елементи в XML-документі можуть мати лише значення, які підходять до типів, визначених у його схемі.

Прості типи

Специфікація XML-схеми визначає кілька простих типів для значень, як показано в Таблиці 2 -передбачені прості типи значень.

Тип елемента може бути простим чи комплексним (складним). Елемент простого типуне може містити інших елементів або атрибутів. Комплексний тип може створювати ефект вбудовування елементів в інші елементи, або може асоціювати атрибути з елементом. До цього моменту ми використовували лише приклади з простими типами, визначеними користувачем (див. ProductCode). У специфікацію XML-схеми також включені прості типи визначені (див. вставку ). Зумовлений простий типобмежує значення за їх базовим типом. Наприклад, значенням зумовленого простого типу ProductCode є підмножина значень базового типу string.

Прості, не вкладені елементи мають простий тип

Елемент, який не містить атрибутів або інших елементів, може бути віднесений до простого типу, визначеного або визначеного користувачем, такого як string , integer , decimal , time , ProductCode і т.п.

Лістинг 7: Деякі прості типи елементів

Елементи з атрибутами мають комплексний тип

Тепер спробуємо додати до простого елемента price з атрибут currency. Ви не зможете цього зробити, оскільки елемент простого типу не може мати атрибутів. Якщо ви бажаєте додати атрибут, вам необхідно визначити price як елемент комплексного типу. У прикладі з , ми визначаємо, так званий анонімний тип, У якому комплексному типу не дається явного імені. Інакше кажучи, атрибут name елемента complexType не визначено.

Лістинг 8: Елемент комплексного типу

Елементи, що містять вкладені елементи, повинні мати комплексний тип.

У XML-документі елемент можуть бути вкладені інші елементи. Ця вимога виражається безпосередньо в DTD. XML-схема натомість визначає елемент та його тип, який може містити оголошення інших елементів та атрибутів. Приклад наведено у .

Таблиця 1: Порівняння комплексних типів даних у DTD та XML-схемі

XML-документ
Cool XML <Title> <Author>Cool Guy</Author> </Book> </span><h5>DTD</h5><span> <!ELEMENT Book (Title, Author)> <!ELEMENT Title (#PCDATA)> <!ELEMENT Author (#PCDATA)> </span><h5>XML-схема</h5><span> <element name="Book" type="BookType"/> <complexType name="BookType"> <element name="Title" type="string"/> <element name="Author" type="string"/> </complexType> </span><h5>Лістинг 10: Приховування BookType як локального типу</h5><span> <element name="Title" type="string"/> <element name="Author" type="string"/> <element name="Book"> <complexType> <element ref="Title"/> <element ref="Author"/> </complexType> </element> </span><h2>Вираз складних обмежень для елементів</h2><p>XML-схема пропонує більшу гнучкість, ніж DTD при вираженні обмежень моделі контенту елементів. На найпростішому рівні, такому як у DTD, ви можете асоціювати з елементом атрибути, а також вказати, що в ньому може з'являтися послідовність лише з одного (1), нуля або більше (*), або одного або більше (+) елементів із заданого набір елементів. У XML-схемі можна висловити додаткові обмеження, використовуючи цієї мети, наприклад, атрибути minOccurs і maxOccurs для елемента element і елементи choice , group і all .</p><h5>Лістинг 11: Вираз обмежень для типів елементів</h5><span> <element name="Title" type="string"/> <element name="Author" type="string"/> <element name="Book"> <complexType> <element ref="Title"/> <element ref="Author"/> </complexType> </element> </span><p>У тег Title є опціональним по відношенню до тега Book (таке саме правило можна задати і в DTD). Однак тут також говориться, що в елементі Book повинен бути хоча б один і не більше двох елементів Author. Значенням атрибутів minOccurs та maxOccurs тега element за замовчуванням є 1. Елемент choice вказує на те, що може з'явитися лише один із зазначених дочірніх елементів. Інший елемент all визначає, що всі дочірні елементи можуть з'являтися тільки один раз, разом і в будь-якому порядку, або зовсім не з'являтися. У оголошується, що обидва теги Title і Author повинні з'являтися в Book у будь-якому порядку, або не з'являтися взагалі. Подібні обмеження важко висловити за допомогою DTD.</p><h5>Лістинг 12: Покажчик того, що елемент повинен мати всі типи.</h5><span> <xsd:element name="Title" type="string"/> <xsd:element name="Author" type="string"/> <xsd:element name="Book"> <xsd:complexType> <xsd:all> <xsd:element ref="Tile"/> <xsd:element ref="Author"/> </xsd:all> </xsd:complexType> </xsd:element> </span><h2>Підбиття підсумків</h2><p>У цьому документі ми розкрили за допомогою простих прикладів найбільш фундаментальні концепції, необхідні визначення структури елементів за допомогою XML-схеми. Доступно також безліч інших потужних механізмів:</p><ul><li>XML-схема містить всебічну підтримку для успадкування типів, дозволяючи повторно використовувати певні структури. Таке використання називають <i>аспектами</i>. Ви можете вивести нові типи, що представляють менше підмножини значень інших типів, наприклад, для визначення підмножини за перерахуванням, діапазоном або збігом з шаблоном. В одному з прикладів цієї статті тип ProductCode було визначено з використанням аспекту pattern. У підтипі також можна додати нові елементи та атрибути для базового типу.</li><li>Декілька механізмів, що дозволяють контролювати загальне визначення підтипу або замінювати його у певному документі. Наприклад, можна вказати, що тип InvoiceType (тип номера інвойсу) не може містити підтипи, тобто ніхто не зможе визначити нову версію InvoiceType. Можна також задати, що в окремому контексті типу ProductCode не може бути заміщення підтипів.</li><li>Крім використання підтипів, можна визначати еквівалентні типи, тобто значення одного типу може бути замінено значенням іншого.</li><li>XML-схема забезпечує механізм для заміщення елемента або типу шляхом оголошення їх як абстрактних.</li><li>Для більшої зручності можна позначити та задати імена групам атрибутів або елементів. Це дозволяє повторно використовувати їх у наступних зверненнях.</li><li>XML-схема надає три елементи - appInfo, documentation і annotation - для використання коментарів, як людьми (documentation) так і додатками (appInfo)</li><li>Ви можете виразити унікальні обмеження, що ґрунтуються на певних атрибутах дочірніх елементів.</li> </ul><p>Додаткову інформацію про XML-схеми можна отримати з документацій на сайтах W3C і dW XML zone. Тепер, коли специфікація XML-схеми отримала підтвердження як кандидата на рекомендацію W3C, ви, без сумніву, можете використовувати її в повній мірі.</p> <h3></h3> <p>У <b>XML</b>- документах <b>DTD</b>визначає набір дійсних елементів, ідентифікує елементи, які можуть бути в інших елементах, і визначає дійсні атрибути для кожного з них. Синтаксис <b>DTD</b>дуже своєрідний і від автора-розробника потрібні додаткові зусилля при створенні таких документів (складність <b>DTD</b>є однією з причин того, що використання <b>SGML</b>, що вимагає визначення <b>DTD</b>для будь-якого документа, не набуло такого широкого поширення як, наприклад, <b>HTML</b>). Як уже зазначалося, у <b>XML</b>використовувати <b>DTD</b>не обов'язково - документи, створені без цих правил, правильно оброблятимуться програмою-аналізатором, якщо вони задовольняють основним вимогам синтаксису <b>XML</b>. Однак контроль за типами елементів та коректністю відносин між ними в цьому випадку повністю покладатиметься на автора документа. Доки граматика нашої нової мови не описана, її зможемо використовувати тільки ми, і для цього ми будемо змушені застосовувати спеціально розроблене програмне забезпечення, а не універсальні програми-аналізатори.</p> <p>У <b>DTD</b>для <b>XML</b>використовуються такі типи правил: правила для елементів та його атрибутів, описи категорій(макровизначень), опис форматів бінарних даних. Усі вони описують основні конструкції мови - елементи, атрибути, символьні константи, зовнішні файли бінарних даних.</p> <p>Для того, щоб використовувати <b>DTD</b>у нашому документі, ми можемо або описати його у зовнішньому файлі та при описі <b>DTD</b>просто вказати посилання на цей файл або безпосередньо всередині самого документа виділити область, в якій визначити потрібні правила. У першому випадку в документі вказується ім'я файлу, що містить <b>DTD</b>- Описи:</p> <span><?xml version="1.0" standalone="yes" ?> <! DOCTYPE journal SYSTEM "journal.dtd"> ... </span> <p>Усередині документа DTD-декларації включаються таким чином:</p> <span>... <! DOCTYPE journal [ <!ELEMENT journal (contacts, issues, authors)> ... ]> ... </span> <p>У тому випадку, якщо використовуються одночасно внутрішні та зовнішні описи, то програмою-аналізатором спочатку розглядатимуться внутрішні, тобто. їхній пріоритет вищий. Під час перевірки документа <b>XML</b>- процесор насамперед шукає <b>DTD</b>всередині документа. Якщо правила всередині документа не визначені та не заданий атрибут</span> standalone ="yes" <span>, то програма завантажить вказаний зовнішній файл та правила, що знаходяться в ньому, будуть зчитані звідти. Якщо ж атрибут <b>standalone</b>має значення " <b>yes"</b>, то використання зовнішніх <b>DTD</b>описів буде заборонено.</p> <h4><span>Визначення елемента</span></h4> <p>Елемент у <b>DTD</b>визначається за допомогою дескриптора! <b>ELEMENT</b>, в якому вказується назва елемента та структура його вмісту.</p> <p>Наприклад, для елемента <flower>можна визначити таке правило:</p> <!ELEMENT flower PCDATA> <p>Ключове слово <b>ELEMENT</b>вказує, що цією інструкцією описуватиметься елемент <b>XML</b>. Всередині цієї інструкції задається назва елемента <b>(flower)</b>та тип його вмісту.</p> <p>У визначенні елемента ми вказуємо спочатку назву елемента <b>(flower)</b>а потім його модель вмісту - визначаємо, які інші елементи або типи даних можуть зустрічатися всередині нього. В даному випадку вміст елемента flower визначатиметься за допомогою спеціального маркера <b>PCDATA</b>(що означає</span> parseable character data <span>- будь-яка інформація, з якою може працювати програма-аналізатор). Існує ще дві інструкції, що визначають тип вмісту: <b>EMPTY</b>,<b>ANY</b>. Перша вказує на те, що елемент повинен бути порожнім (наприклад,</span><red/> <span>), друга - те що, що вміст елемента спеціально не описується.</p> <p>Послідовність дочірніх для поточного елемента об'єктів задається у вигляді списку розділених ком назв елементів. При цьому для того щоб вказати кількість повторень включень цих елементів можуть використовуватися символи +, *, ? :</p> <span><!ELEMENT issue (title, author+, table-of-contents?)> </span> <p>У цьому прикладі вказується, що всередині елемента <issue>мають бути визначені елементи <b>title</b>, <b>author</b>і <b>table-of-contents</b>, причому елемент <b>title</b>є обов'язковим елементом і може зустрічатися лише один раз, елемент author може зустрічатися кілька разів, а елемент <b>table-of-contents</b>є опціональним, тобто. може бути відсутнім. У тому випадку, якщо існує кілька можливих варіантів вмісту елемента, що їх визначається, їх слід розділяти за допомогою символу <b>"|" </b>: </p> <span><!ELEMENT flower (PCDATA | title)*> </span> <p>Символ <b>* </b>у цьому прикладі вказує на те, що обумовлена ​​послідовність внутрішніх елементів може бути повторена кілька разів або зовсім не використовуватися.</p> <p>Якщо визначенні елемента вказується " змішане " вміст, тобто. текстові дані або набір елементів, необхідно спочатку вказати <b>PCDATA</b>, а потім розділений символом <b>"|" </b>Список елементів.</p> <p>Приклад коректного <b>XML</b>- Документа:</p> <span><?xml version="1.0"?> <! DOCTYPE journal [ <!ELEMENT contacts (address, tel+, email?)> <!ELEMENT address (street, appt)> <!ELEMENT street PCDATA> <!ELEMENT appt (PCDATA | EMPTY)*> <!ELEMENT tel PCDATA> <!ELEMENT email PCDATA> ]> ... <contacts> <address> <street>Marks avenue</street> <appt id="4"> </address> <tel>12-12-12</tel> <tel>46-23-62</tel> <email>info@j.com</email> </contacts> </span> <h4><span><b>Визначення атрибутів</b> </span></h4> <p>Списки атрибутів елемента визначаються ключовим словом! <b>ATTLIST</b>. Усередині нього задаються назви атрибутів, типи їх значень та додаткові параметри. Наприклад, для елемента</span><article> <span>можуть бути визначені такі атрибути:</p> <span><!ATTLIST article id ID #REQUIRED about CDATA #IMPLIED type (actual | review | teach) "actual" "" > </span> <p>У цьому прикладі для елемента <b>article</b>визначаються три атрибути: <b>id,</b><i> </i><b>про</b>і <b>type</b>які мають типи <b>ID</b>(ідентифікатор), <b>CDATA</b>та список можливих значень відповідно. Усього існує шість можливих типів значень атрибуту:</p> <ul><li><span><b>CDATA</b>- вмістом документа можуть бути будь-які символьні дані</span></li> <li><span><b>ID</b>- Визначає унікальний ідентифікатор елемента в документі</span></li> <li><span><b>IDREF</b>(<b>IDREFS</b>)- вказує, що значенням атрибута має виступати назва (або кілька таких назв, розділених пробілами у другому випадку) унікального ідентифікатора певного в цьому документі елемента</span></li> <li><span><b>ENTITY</b>(<b>ENTITIES</b>) - значення атрибута має бути назвою (або списком назв, якщо використовується <b>ENTITIES</b>) компонента (макровизначення), визначеного у документі</span></li> <li><span><b>NMTOKEN</b> (<b>NMTOKENS</b>) - вміст елемента може бути лише одне окреме слово (тобто цей параметр є обмеженим варіантом <b>CDATA</b>) </span></li> <li><span>Список допустимих значень визначається список значень, які може мати даний атрибут.</span></li> </ul><p>Також для визначення атрибута можна використовувати такі параметри:</p> <ul><li><span><b>#REQUIRED</b>- визначає обов'язковий атрибут, який має бути заданий у всіх елементах даного типу</span></li> <li><span><b>#IMPLIED</b>- атрибут не є обов'язковим</span></li> <li><span><b>#FIXED</b>"значення" - вказує, що атрибут повинен мати лише зазначене значення, проте саме визначення атрибута не є обов'язковим, але в процесі розбору його значення у будь-якому випадку буде передано програмі-аналізатору</span></li> <li><span>Значення - задає значення атрибуту за замовчуванням</span></li> </ul><h4><span><b>Визначення компонентів (макровизначень)</b> </span></h4> <p>Компонент <b>(entity)</b>є визначення, вміст яких може бути повторно використано в документі. В інших мовах програмування такі елементи називаються макровизначення. Створюються <b>DTD</b>- компоненти за допомогою інструкції <b>!ENTITY</b>: </p> <span><!ENTITY hello " Мы рады приветствовать Вас!" > </span> <p>Програма-аналізатор, переглядаючи насамперед вміст області <b>DTD</b>- ухвал, опрацює цю інструкцію і при подальшому розборі документа буде використовувати вміст <b>DTD</b>- компонента там, де буде зустрічатися його назва. Тобто. тепер у документі ми можемо використовувати вираз <b>&hello</b>; , яке буде замінено на рядок <i>" </i><b>Ми раді вітати Вас"</b> </p> <p>У загальному випадку, усередині <b>DTD</b>можна задати три типи макровизначень:</p> <p><b>Внутрішні макровизначення</b> </span><span>- призначені визначення строкової константи, з допомогою можна організовувати посилання часто змінювану інформацію, роблячи документ читальнішим. Внутрішні компоненти включаються до документа за допомогою амперсанта <b>& </b> </p> <p>У <b>XML</b>існує п'ять встановлених внутрішніх символьних констант:</p> <ul><li><span><b>< </b>- Символ <b>"<" </b> </span></li> <li><span><b>> </b>- Символ <b>">" </b> </span></li> <li><span><b>& </b>- Символ <b>"&" </b> </span></li> <li><span><b>" </b>- Символ апострофа <b> """ </b> </span></li> <li><span><b>" </b>- символ подвійної лапки <b>""" </b> </span></li> </ul><p><b>Зовнішні макровизначення</b> </span><span>- Вказують на вміст зовнішнього файлу, причому цим вмістом можуть бути як текстові, так і двійкові дані. У першому випадку в місці використання макросу будуть вставлені текстові рядки, у другому – бінарні дані, які аналізатором не розглядаються та використовуються зовнішніми програмами.</p> <span><!ENTITY logotype SYSTEM "/image.gif" NDATA GIF87A> </span> <p><b>Макровизначення правил</b> </span><span>- макровизначення параметрів можуть використовуватися тільки всередині області DTD та позначаються спеціальним символом <b>% </b>, що вставляється перед назвою макросу. При цьому вміст компонента буде поміщений безпосередньо в текст <b>DTD</b>- правила</p> <p>Наприклад, для наступного фрагмента документа:</p> <span><!ELEMENT name (PCDATA)> <!ELEMENT title (PCDATA | name)*> <!ELEMENT author (PCDATA | name)*> <!ELEMENT article (title, author)*> <!ELEMENT book (title, author)*> <!ELEMENT bookstore (book | article)*> <!ELEMENT bookshelf (book | article)*> </span> <p>можна використовувати більш коротку форму запису:</p> <span><!ELEMENT name (PCDATA)> <! ENTITY %names "PCDATA | name"> <!ELEMENT article (%names;)*> <!ELEMENT book (%names;)*> <!ENTITY %content "book | article"> <!ELEMENT bookstore (%content;)*> <!ELEMENT bookshelf (%content;)*> </span> <p>Макровизначення часто використовуються для опису параметрів у правилах атрибутів. У цьому випадку з'являється можливість використовувати однакові визначення атрибутів для різних елементів:</p> <span><!ENTITY %itemattr "id ID #IMPLIED src CDATA"> <!ENTITY %bookattr "ISDN ID #IMPLIED type CDATA"> <!ENTITY %artattr " size CDATA"> <!ELEMENT book (title, author,content)*> <!ATTLIST book %itemattr %bookattr;> <!ELEMENT article (title, author, content)*> <!ATTLIST article %itemattr %artattr;> </span> <h4><span><b>Типізація даних</b> </span></h4> <p>Досить часто під час створення <b>XML</b>- елемента розробнику потрібно визначити, дані якого типу можуть використовуватися як його вміст. Тобто. якщо ми визначаємо елемент</span><span><last-modified>10.10.98</last-modified> </span><span>, то хочемо бути впевненими, що в документі в цьому місці буде рядок, що представляє собою дату, а не число або довільну послідовність символів. Використовуючи типизацію даних, можна створювати елементи, значення яких можуть використовуватися, наприклад, як параметри <b>SQL</b>- Запитів. Програма клієнт у разі має знати, якого типу даних належить поточне значення елемента й у разі відповідності формує <b>SQL</b>-Запит.</p> <p>Якщо як програма на стороні клієнта використовується верифікуючий <b>XML</b>-процесор, то інформацію про тип можна передавати за допомогою спеціально створеного для цього атрибуту елемента, що має відповідне <b>DTD</b>- Визначення. У процесі аналізу програма-аналізатор передасть значення цього атрибуту клієнтському додатку, який зможе використовувати цю інформацію належним чином. Наприклад, щоб вказати, що вміст елемента має бути довгим цілим, можна використовувати наступне <b>DTD</b>- Визначення:</p> <span><!ELEMENT counter (PCDATA)> <!ATTLIST counter data_long CDATA #FIXED "LONG"> </span> <p>Задавши атрибуту значення за промовчанням <b>LONG</b>і визначивши його як <b>FIXED</b>, ми дозволили цим програмі-клієнту отримати необхідну інформацію про тип вмісту даного елемента, і тепер вона може самостійно визначити відповідність типу цього вмісту вказаному в <b>DTD</b>- Визначення.</p> <p>Ось приклад <b>XML</b>- документа, в якому визначаються та використовуються кілька елементів з різними типами даних:</p> <span><!ELEMENT price (PCDATA)> <!ATTLIST price data_currency CDATA #FIXED "CURRENCY"> <!ELEMENT rooms_num (PCDATA)> <!ATTLIST rooms_num data_byte CDATA #FIXED "BYTE"> <!ELEMENT floor (PCDATA)> <!ATTLIST floor data_byte CDATA #FIXED "INTEGER"> <!ELEMENT living_space (PCDATA)> <!ATTLIST living_space data_float CDATA #FIXED "FLOAT"> <!ELEMENT counter (PCDATA)> <!ATTLIST counter data_long CDATA #FIXED "LONG"> <!ELEMENT is_tel (PCDATA)> <!ATTLIST is_tel data_bool CDATA #FIXED "BOOL"> <!ELEMENT house (rooms_num, floor,living_space, is_tel, counter, price)> <!ATTLIST house id ID #REQUIED> ... <house id="0"> <rooms_num>5</rooms_num> <floor>2</floor> <living_space>32.5</living_space> <is_tel>true</is_tel> <counter>18346</counter> <price>34 нар. 28 до.</price> </house> ... </span> <p>Як видно з прикладу, механізм створення елементів документа при цьому не змінився. Вся необхідна для перевірки типів даних інформація закладена для визначення елементів усередині блоку <b>DTD</b>. </p> <p>Наприкінці хотілося б зазначити, що <b>DTD</b>надає нам дуже зручний механізм здійснення контролю над вмістом документа. На сьогоднішній день практично всі програми перегляду документів Інтернет використовують <b>DTD</b>-Правила. Однак, це далеко не єдиний спосіб перевірки коректності документа. Зараз у <b>W3</b>Консорціум знаходиться на розгляді нового стандарту мови опису структури документів, званий схемами даних. Наступний розділ присвячений роботі з ними.</p></td> <p>DTD є сукупністю синтаксичних правил, на основі яких перевіряється структура документа XML. В DTD явно визначається структура документа XML, вказуються елементи та їх атрибути, а також наводиться інша інформація, що поширюється на всі документи XML, створені на основі цього DTD.</p> <p>Зверніть увагу, що наявність DTD не є обов'язковою. Якщо DTD існує, система XML керується ним під час інтерпретації документа XML. Якщо DTD немає, передбачається, що система XML повинна інтерпретувати документ за власними правилами. Втім, для документів XML все ж таки рекомендується створювати DTD, оскільки це спрощує їх інтерпретацію та перевірку структури.</p> <p>DTD можна включити безпосередньо до документа XML, послатися на нього за URL або використовувати комбінацію цих двох способів. При безпосередньому включенні DTD до документа XML визначення DTD розташовується відразу після прологу:</p><p> <!DOCTYPE имя_корневого_элемента [ ; ...прочие объявления... ] > </p><p>Атрибут _ім'я_кореневого_елемента відповідає імені кореневого елемента в тегах, що містять весь документ XML. У секції "інших оголошень" знаходяться визначення елементів, атрибутів і т.д.</p> <p>Можливо, ви хочете розмістити DTD в окремому файлі, щоб забезпечити модульну структуру програми. Давайте подивимося, як виглядає посилання зовнішній DTD в документі XML. Завдання вирішується однією простою командою:</p><p> <!DOCTYPE имя_корневого_элемента SYSTEM "some_dtd.dtd"> </p><p>Як і у випадку внутрішнього оголошення DTD, ім'я_кореневого_елемента має відповідати імені кореневого елемента в тегах, що містять весь документ XML. Атрибут SYSTEM свідчить про те, що some_dtd.dtd знаходиться на локальному сервері. Втім, файл some_dtd.dtd також можна послатися за його абсолютного URL. Нарешті, у лапках вказується URL зовнішнього DTD, розташованого на локальному або віддаленому сервері.</p> <p>Як створити DTD для лістингу 14.1? По-перше, ми збираємося створити у документі XML посилання зовнішній DTD. Як згадувалося в попередньому розділі, посилання на DTD виглядає так:</p><p> <!DOCTYPE cookbook SYSTEM "cookbook.dtd"> </p><p>Повертаючись до лістингу 14.1, бачимо, що cookbook є ім'ям кореневого елемента, a cookbook.dtd - ім'ям DTD-файлу. Вміст DTD показаний у лістингу 14.2, а нижче наведено докладні описи всіх рядків.</p> <h2>Лістинг 14.2. DTD для лістингу 14.1 (cookbook.dtd)</h2> <?xml version="1.0"?> <!DOCTYPE cookbook [ <!ELEMENT cookbook(recipe+)> <!ELEMENT recipe(title, description, ingredients, process)> <!ELEMENT title(#PCDATA)> <!ELEMENT description(#PCDATA)> <!ELEMENT ingredients(ingredient+)> <!ELEMENT ingredient(#PCDATA)> <!ELEMENT process Cstep+)> <!ELEMENT step(#PCDATA)> <!ATTLIST recipe category CDATA #REQUIRED> ] > <p>Що означає цей загадковий документ? Незважаючи на зовнішню складність, насправді він є досить простим. Давайте переберемо весь вміст лістингу 14.2:</p><p> <?xml version="1.0"?> </p><p>Перед нами пролог XML, про який вже говорилося вище.</p><p> <!DOCTYPE cookbook [ </p><p> <!ELEMENT cookbook(recipe+)> </p><p>Третій рядок описує елемент XML, у разі - кореневий елемент cookbook. Після нього слідує слово recipe, укладене в круглі дужки. Це означає, що в теги cookbook полягає вкладений тег з ім'ям recipe. Знак + говорить про те, що в батьківських тегах cookbook знаходиться одна або кілька пар тегів recipe.</p><p> <!ELEMENT recipe(title, description, ingredients. process)> </p><p>Четвертий рядок описує тег recipe. У ній повідомляється, що в тег recipe входять чотири вкладені теги: title, description, ingredients і process. Оскільки після імен тегів не вказуються ознаки повторення (див. наступний розділ), всередині тегів recipe повинна бути укладена одна пара кожного з перерахованих тегів.</p><p> <! ELEMENT title(#PCDATA)> </p><p>Перед нами перше визначення тега, який містить вкладених тегів. Відповідно до визначення він містить #PCDATA, тобто довільні символьні дані, що не вважаються частиною розмітки.</p><p> <!ELEMENT ingredients(ingredient+)> </p><p>Відповідно до визначення елемент ingredients містить один або кілька тегів з ім'ям ingredient. Зверніться до лістингу 14.1, і ви все зрозумієте.</p><p> <! ELEMENT ingredient(#PCDATA)> </p><p>Оскільки елемент ingredient відповідає окремому інгредієнту, логічно, що цей елемент містить прості символьні дані.</p><p> <! ELEMENT process(step+)> </p><p>Елемент process містить один або кілька екземплярів елемента Step.</p><p> <! ELEMENT step(#PCDATA)> </p><p>Елемент step, як і елемент ingredient, відповідає окремому пункту у списку вищого рівня. Отже, він має містити символьні дані.</p><p> <!ATTLIST recipe category CDATA #REQUIRED> </p><p>Зверніть увагу: елемент recipe у лістингу 14.1 містить атрибут. Цей атрибут, category, визначає загальну категорію, до якої належить рецепт – у наведеному прикладі це категорія «італійська кухня» (Italian). У визначенні ATTLIST вказується ім'я елемента, і ім'я атрибута. Крім того, віднесення кожного рецепта до певної категорії полегшує класифікацію, тому атрибут оголошується обов'язковим (#REQUIRED).</p><p>Останній рядок просто завершує визначення DTD. Визначення завжди має бути належним чином завершено, інакше буде помилка.</p> <p>На завершення цього розділу я наведу зведення основних компонентів типового файлу DTD:</p> <ul><li>оголошення типів елементів;</li><li>оголошення атрибутів;</li><li>ID, IDREF та IDREFS;</li><li>оголошення сутностей.</li> </ul><p>Деякі з цих компонентів вже зустрічалися в описі лістингу 14.2. Далі кожен компонент буде більш докладно описаний.</p> <h2>Оголошення елементів</h2> <p>Усі елементи, що використовуються в документі XML, повинні бути визначені в документі DTD. Ми вже зустрічалися з двома поширеними різновидами визначень: елемента, що містить інші елементи, і елемента, що містить символьні дані. Дане визначення свідчить, що елемент містить лише символьні дані:</p><p> <! ELEMENT описание(#РСDАТА)> </p><p>Наступне визначення елемента process говорить про те, що він містить одно вкладений елемент з ім'ям step:</p><p> <!ELEMENT process(step)> </p><p>Втім, процеси з одного кроку зустрічаються досить рідко - швидше за все, кроків буде кілька. Щоб вказати, що елемент містить один або кілька екземплярів вкладеного елемента step, слід скористатися ознакою повторення:</p><p> <!ELEMENT process(step+)> </p><p>Кількість вкладених елементів можна задати кількома способами. Повний список операторів елементів наведено у табл. 14.1.</p> <h2>Таблиця 14.1. Оператори елементів</h2> <p>Якщо елемент міститиме кілька вкладених елементів, їх слід перерахувати через кому у визначенні батьківського елемента:</p><p> <!ELEMENT recipe(title, description, ingredients, process)> </p><p>Оскільки ознаки повторення не зазначені, кожен тег повинен зустрічатися рівно один раз.</p> <p>Визначення елемента уточнюється з допомогою логічних операторів. Припустимо, ви працюєте з рецептами, які завжди входять макарони (pasta) з одним або декількома типами сиру (cheese) або м'яса (meat). У цьому випадку елемент ingredient визначається наступним чином:</p><p> <!ELEMENT ingredient(pasta+,(cheese | meat)+)> </p><p>Оскільки елемент pasta обов'язково повинен бути присутнім на елементі ingredient, він вказується з ознакою повторення +. Потім слідує або елемент cheese, або елемент meat; ми поділяємо альтернативи вертикальною рисою і укладаємо їх у круглі дужки зі знаком +, оскільки до рецепту завжди входить або одне, або інше.</p> <p>Існують інші різновиди визначень елементів. Ми розглянули лише найпростіші випадки. Тим не менш, наведеного матеріалу цілком достатньо для розуміння прикладів, наведених у частині цього розділу, що залишилася.</p> <h2>Оголошення атрибутів</h2> <p>Атрибути елементів описують значення, пов'язані з елементами. Елементи XML, як і елементи HTML, можуть мати нуль, один або кілька атрибутів. Загальний синтаксис оголошення атрибутів виглядає так:</p> <b> <!ATTLIST имя_элемента имя_атри6ута1 тип_данных1 флаг1 </b> <p>Ім'я_елемента визначає ім'я елемента, що включає тег. Потім перераховуються атрибути, пов'язані з цим елементом. Оголошення кожного атрибута складається з трьох основних компонентів: імені, типу даних та прапора, що визначає особливості даного атрибуту. Замість крапки (...) можуть бути розміщені оголошення інших атрибутів.</p> <p>Просте оголошення атрибута вже зустрічалося нам у лістингу 14.2:</p><p> <!ATTLIST recipe category CDATA #REQUIRED> </p><p>Проте, як очевидно з наведеного загального визначення, допускається одночасне оголошення кількох атрибутів. Допустимо, на додаток до атрибуту категорії ви хочете пов'язати з елементом recipe додатковий атрибут difficulty(складність приготування). Обидва атрибути оголошуються в одному списку:</p><p> <!ATTLIST recipe category CDATA #REQUIRED difficulty CDATA #REQUIRED> </p><p>Форматувати оголошення не обов'язково; проте, багаторядкові оголошення наочніше однорядкові. Крім того, оскільки обидва атрибути є обов'язковими, тег reci ре не може обмежитися яким-небудь одним атрибутом, він повинен включати обидва атрибути відразу. Наприклад, наступний тег вважатиметься невірним: <recipe difficulty="hard"></p> <p>Чому? Тому що в ньому відсутній атрибут категорії. Правильний тег повинен містити обидва атрибути:</p><p> <recipe category="Italian" difficulty="hard"> </p><p>Особливі умови обробки атрибута описуються трьома прапорами, наведеними в табл. 14.2.</p> <h2>Таблиця 14.2. Прапори атрибутів</h2> <h2>Типи атрибутів</h2> <p>Атрибут елемента може бути оголошений з певним типом. Типи атрибутів описані далі.</p> <h3>Атрибути CDATA</h3> <p>Найчастіше атрибути містять загальні символьні дані. Такі атрибути називають атрибутами CDATA. Наступний приклад вже зустрічався на початку цього розділу:</p><p> <!ATTLIST recipe category COATA #REQUIRED> </p><h3>Атрибути ID, IDREF та IDREFS</h3> <p>Ідея однозначного представлення даних (наприклад, інформації про користувача або товар, що зберігається в базі даних) за допомогою ідентифікаторів неодноразово зустрічалася в попередніх розділах книги. Ідентифікатори також часто використовуються в XML, оскільки перехресні посилання між документами застосовуються не тільки у загальних завданнях обробки даних, але й у World Wide Web (гіперпосилання).</p> <p>Ідентифікатори елементів надаються атрибуту ID. Допустимо, ви хочете пов'язати з кожним рецептом унікальний ідентифікатор. Відповідний фрагмент DTD може мати такий вигляд:</p><p> <!ELEMENT recipe(title, description, ingredients, process)> <!ATTLIST recipe recipe-id ID #REQUIRED> <!ELEMENT recipe-ref EMPTY> <!ATTLIST recipe-ref go IDREF #REQUIRED> </p><p>Після цього оголошення елемента recipe у документі може виглядати так:</p><p> <recipe recipe-id="ital003"> <title>Spaghetti alla Carbonara

Рецепт однозначно визначається ідентифікатором ital003. Слід пам'ятати, що атрибут redpe-id відноситься до типу ID, тому ital003 не може використовуватися як значення атрибуту recipe-id іншого елемента, інакше документ вважатиметься синтаксично неправильним. Тепер припустимо, що пізніше ви захотіли послатися на цей рецепт з іншого документа – скажімо, зі списку улюблених рецептів користувача. Саме тут у гру вступають перехресні посилання та атрибут IDREF. Атрибуту IDREF надається ідентифікатор, який використовується для посилань на елемент, - за аналогією з тим, як URL використовується для ідентифікації сторінки в гіперпосиланні. Розглянемо наступний фрагмент коду XML:

У процесі обробки документа XML елемент замінюється наочнішим посиланням на рецепт із зазначеним ідентифікатором (наприклад, назвою рецепту). Ймовірно, його буде відформатовано у вигляді гіперпосилання, щоб спростити перехід до зазначеного рецепту.

Перераховані атрибути

При оголошенні атрибута можна перерахувати всі допустимі значення, які приймає атрибут. У нашому прикладі це було б зручно, оскільки ви можете одразу визначити список допустимих категорій. Наведене вище оголошення записується у такому вигляді:

Зверніть увагу: при використанні списків допустимих значень включати в оголошення тип CDATA не потрібно, оскільки всі ці значення відносяться до формату CDATA.

Перераховані атрибути зі значенням за промовчанням

Іноді зручно оголосити для атрибута значення за замовчуванням. Швидше за все, вам уже доводилося робити це раніше при побудові форм з списками, що розкриваються. Наприклад, якщо більшість рецептів у вашій кухонній книзі відноситься до італійської кухні, атрибут recipe часто ставиться до категорії Italian. У цьому випадку категорію Italian можна призначити за замовчуванням:

Якщо атрибут категорії не заданий явно, за умовчанням йому надається значення Italian.

Атрибути ENTITY та ENTITIES

Дані в документах XML не завжди є текстовими - документ може містити двійкову інформацію (наприклад, графіку). Такі дані можна посилатися за допомогою атрибута entity. Наприклад, в описі елемента description можна вказати атрибут recipePicture з графічним зображенням:

Також можна оголосити одразу кілька сутностей, замінивши ENTITY на ENTITIES. Значення поділяються пробілами.

Атрибути NMTOKEN та NMTOKENS

Атрибути NMTOKEN є рядками із символів, що входять в обмежений набір. Оголошення атрибута з типом NMTOKEN передбачає, що значення атрибуту відповідає встановленим обмеженням. Як правило, значення атрибуту NMTOKEN складається з одного слова:

Можна оголосити кілька атрибутів, замінивши NMTOKEN на NMTOKENS. Значення поділяються пробілами.

Оголошення сутностей

Оголошення сутності нагадує команду define у ​​деяких мовах програмування, включаючи РНР. Посилання на сутності коротко згадувалися в попередньому розділі «Знайомство із синтаксисом XML». Про всяк випадок нагадаю, що посилання на сутність використовується як заміна для іншого фрагмента змісту. У процесі обробки документа XML всі входження сутності замінюються змістом, який вона представляє. Існує два види сутностей: внутрішні та зовнішні.

Внутрішні сутності

Внутрішні сутності нагадують рядкові змінні, що зв'язують ім'я із фрагментом тексту. Наприклад, якщо ви хочете визначити ім'я для посилання на інформацію про авторські права, можна оголосити сутність такого виду:

У процесі обробки документа всі екземпляри &Соруright замінюються текстом «Copyright 2000 YourCompanyName. All Rights Reserved». Весь код XML в тексті, що замінює, обробляється так, ніби він був присутній у вихідному документі.

Внутрішні сутності зручні у ситуаціях, коли ви плануєте використовувати сутність щодо відносно невеликій кількості документів XML. При велику кількість документів краще скористатися зовнішніми сутностями.

Зовнішні сутності

Зовнішні сутності використовуються для посилань зміст, що у іншому файлі. Сутності цього можуть містити текстову інформацію, але можуть посилатися і двійкові дані (наприклад, графіку). Повернувшись до попереднього прикладу, припустимо, що ви вирішили зберегти інформацію про авторські права в окремому файлі, щоб спростити її редагування у майбутньому. Посилання на створений файл виглядає так:

Під час подальшої обробки документа XML всі посилання &Соруright замінюються вмістом документа copyright.xml. Весь код XML в тексті, що замінює, обробляється так, ніби він був присутній у вихідному документі.

Зовнішні сутності зручно використовувати для посилань на графічні зображення. Наприклад, якщо ви хочете включити в документ XML графічний логотип, створіть зовнішню суть:

Ресурси, присвячені XML

Хоча наведеного вище матеріалу цілком достатньо для розуміння базової структури документів XML, цей опис не є повним. Нижче наведено посилання на ресурси Інтернету, що містять більш детальну інформацію:

У частині розділу, що залишилася, розказано про те, як використовувати РНР для обробки документів XML. На перший погляд, завдання здається дуже складним (лексичний аналіз будь-яких документів будь-якого типу викликає чимало труднощів).

Але варто познайомитися з базовою стратегією роботи з XML в РНР, і все виявляється напрочуд просто.

Головний письменник з питань технологій

Вам хтось надіслав електронною поштою файл DTD, і ви не знаєте, як його відкрити? Можливо, ви знайшли файл DTD на вашому комп'ютері і вас зацікавило, що це файл? Windows може сказати вам, що ви не можете відкрити його, або, у гіршому випадку, ви можете зіткнутися з відповідним повідомленням про помилку, пов'язану з файлом DTD.

До того, як ви зможете відкрити файл DTD, вам необхідно з'ясувати, який вид файлу відноситься розширення файлу DTD.

Tip:Неправильний DTD файл з'єднання errors може бути симптомом інших підданих ідентифікацій з вами в операційній системі Windows. Ці неправильні навантаження можуть також створювати поєднані симптоми так само, як високі Windows startups, комп'ютери freezes, і інші PC performance issues. Там,наскільки висока відповідь на те, що ви скануєте свою Windows Registry для вvalid file asociations й інші питання пов'язані з fragmented Registry.

Відповідь:

Файли DTD мають файли даних, який переважно асоційований з DesignTools 2D Design (TechSoft UK Limited).

Файли DTD також асоційовані з ArcView UNIX Hyperhelp Supporting File (ESRI), SGML Document Definition File та FileViewPro.

Інші типи файлів можуть також використовувати розширення файлу DTD. Якщо вам відомі будь-які інші формати файлів, які використовують розширення DTD-файлу, будь ласка, зв'яжіться з нами , щоб ми змогли відповідним чином оновити нашу інформацію.

Як відкрити файл DTD:

Найшвидший і легкий спосібвідкрити свій файл DTD - це двічі клацнути мишею. В даному випадку система Windowsсама вибере необхідну програмудля відкриття файлу DTD.

У випадку, якщо ваш файл DTD не відкривається, ймовірно, що на вашому ПК не встановлена ​​необхідна прикладна програмадля перегляду або редагування файлів із розширеннями DTD.

Якщо ваш ПК відкриває файл DTD, але в неправильній програмі, вам потрібно змінити налаштування асоціації файлів у вашому реєстрі Windows. Іншими словами, Windows асоціює розширення файлів DTD з неправильною програмою.

Встановити необов'язкові продукти – FileViewPro (Solvusoft) | | | |

DTD Multipurpose Internet Mail Extensions (MIME):

  • mime text/xml

DTD Інструмент аналізу файлів™

Ви не впевнені, який тип файлу DTD? Бажаєте отримати точну інформаціюпро файл, його творця і як його можна відкрити?

Тепер миттєво можна отримати всю необхідну інформацію про файл DTD!

Революційний DTD Інструмент аналізу файлів™ сканує, аналізує та повідомляє детальну інформаціюпро файл DTD. Наш алгоритм (очікується видача патенту) швидко проаналізує файл і через кілька секунд надасть докладну інформацію в наочному форматі, що легко читається.†

Вже через кілька секунд ви точно дізнаєтеся тип вашого файлу DTD, додаток, зіставлений з файлом, ім'я файлу користувача, статус захисту файлу та іншу корисну інформацію.

Щоб почати безкоштовний аналіз файлу, просто перетягніть файл DTD всередину пунктирної лініїнижче або натисніть «Переглянути мій комп'ютер» та виберіть файл. Звіт про аналіз файлу DTD буде показаний внизу прямо у вікні браузера.

Перетягніть файл DTD сюди для початку аналізу

Переглянути мій комп'ютер »

Будь ласка, також перевірте мій файл на віруси

Ваш файл аналізується... будь ласка, зачекайте.



ПОХОДЖЕННЯ СТАТТІ