Приводимые далее определения были представлены в стандарте Unicode. Все символы делятся на базовые символы (BaseChar, наряду с прочим сюда включены буквы латинского алфавита), идеографические символы (Ideographic), комбинированные символы (CombiningChar, в последнюю группу попадает также большинство диакритических символов). Выделяются также цифры (Digit) и расширения (Extender).
Представленные здесь классы символов могут быть извлечены из базы данных символов Unicode 2.0 следующим образом:
Начальные символы Name (Name start) должны иметь одну из следующих категорий: Ll, Lu, Lo, Lt, Nl.
Символы Name, за исключением Name-start, должны иметь одну из следующих категорий: Mc, Me, Mn, Lm, or Nd.
В XML именах нельзя использовать символы из области совместимости (то есть, символы с кодом, большим чем #xF900 и меньшим чем #xFFFE).
Нельзя использовать символы, имеющие шрифт или расклад совместимости (то есть, имеющие "тэг совместимости форматирования" в 5-м поле базы данных - имеющие метку в поле 5, начинающемся с "<").
Символы [#x02BB-#x02C1], #x0559, #x06E5, #x06E6 обрабатываются как name-start символы, а не как символы name, поскольку классификатор определяет их как алфавитные.
Символы #x20DD-#x20E0 исключены (в соответствии с требованиями Unicode 2.0, глава 5.14).
Символ #x00B7 классифицируется как расширение, поскольку именно таким образом он идентифицируется в перечне свойств.
Символ #x0387 добавлен как name символ, поскольку #x00B7 является его каноническим эквивалентом.
Символы ':' и '_' допустимы в качестве name-start символов.
Символы '-' и '.' допустимы в качестве name символов.
XML построен как подмножество SGML, поэтому каждый XML документ должен также отвечать требованиям, предъявляемым к SGML документу. Детальное сравнение ограничений, которые языки XML и SGML накладывают на документы, см. в статье [Clark].
В данном приложении содержатся некоторые примеры, иллюстрирующие последовательность распознавания и обработки ссылок на сущность и символ, которая была определена в главе 4.4 Обработка XML процессором сущностей и ссылок.
Если DTD содержит декларацию
то в ходе обработки этой декларации сущности XML процессор обнаружит ссылки на символ и обработает их прежде чем следующая строка будет использована в качестве значения сущности "example":
Появление в документе ссылки на элемент "&example;" приведет к тому, что этот текст будет разобран снова. Будут обнаружены начальный и конечный тэги элемента p, а также будут обнаружены и обработаны все три ссылки. В результате элемент p будет иметь следующее содержание (все данные, но без ограничителей и разметки):
Более сложный пример полностью проиллюстрирует эти правила и их эффективность. (Номера строк в следующем примере нужны лишь для комментариев.)
В результате получается следующий сценарий:
в строке 4 ссылка на символ с кодом 37 обрабатывается сразу, и сущность параметра "xx" помещается в таблицу символов со значением "%zz;". И поскольку текст замены повторно не просматривается, ссылка на сущность параметра "zz" обнаружена не будет. (Если же это здесь произойдет, то будет зафиксирована ошибка, поскольку сущность "zz" еще не была декларирована.)
в строке 5 ссылка на символ "<" обрабатывается сразу, и сущность параметра "zz" обзаводится текстом замены "<!ENTITY tricky "error-prone" >", являющимся корректной декларацией сущности.
в строке 6 обнаруживается ссылка на сущность "xx" и, соответственно, производится разбор текста замены для этой сущности (а именно, "%zz;"). При этом обнаруживается ссылка на сущность "zz" и тоже анализируется ее текст замены ("<!ENTITY tricky "error-prone" >"). В результате получаем декларацию общей сущности "tricky" с текстом замены "error-prone".
в строке 8, обнаруживается и обрабатывается ссылка на общую сущность "tricky". В итоге получаем полное содержимое элемента test в виде самодостаточной (и не связанной с какой-либо грамматикой) строки This sample shows a error-prone method.
Как указывалось в главе 3.2. Содержимое элемента, необходимо чтобы модели содержимого, даваемые в декларациях типов элементов, были детерминистическими. Данное требование необходимо для совместимости с языком SGML (в котором детерминистические модели содержания обозначаются термином "unambiguous"). XML процессоры, построенные на базе систем SGML, могут выявлять недетерминистические модели содержания как ошибочные.
К примеру, модель содержимого ((b, c) | (b, d)) является недетерминистической, поскольку, получив исходный b, XML процессор не может знать, какому b в исходной модели он соответствует, не проследив далее по строке, какой элемент следует за указанным b. В данном случае обе ссылки на b можно свести в одну общую ссылку, преобразовав рассматриваемую модель в (b, (c | d)). Теперь исходный элемент b соответствует ровно одному имени в модели содержания, и процессору нет нужды заглядывать вперед чтобы увидеть, что за ним следует. Это может быть и c, и d.
Или более формально: с помощью стандартных алгоритмов по модели содержания может быть выстроен автомат конечных состояний, например алгоритм 3.5 из главы 3.9 в книге авторов Aho, Sethi и Ullman [Aho/Ullman]. Во многих таких алгоритмах для каждой части в регулярном выражении строится сопроводительный набор команд (то есть, в дереве синтаксиса данного регулярного выражения стоится каждый узел листа). Если какая-либо часть выражения имеет сопроводительный набор, в котором более одной позиции сопоставлено с типом элементов с одним и тем же названием, модель содержимого ошибочна и об этом можно сообщать как об ошибке.
Существуют алгоритмы, которые способны многие (хотя и не все) недетерминистические модели содержания автоматически привести к эквивалентным детерминистическым моделям (см. Brüggemann-Klein 1991 [Brüggemann-Klein]).
Декларация кодировки XML для каждой сущности действует как некий внутренний заголовок, указывающий используемую кодировку символов. Очевидно, что прежде чем XML процессор сможет прочесть внутренний заголовок, он должен выяснить используемую кодировку символов, то есть именно то, что пытается показать внутренний заголовок. В общем случае, это безвыходная ситуация. Однако для XML это не совсем так, поскольку XML в общем случае ограничен двумя положениями: предполагается, что каждая реализация поддерживает только ограниченный набор кодировок символов, а декларация кодировки XML занимает определенную позицию и имеет определенное содержание, что позволяет в обычных случаях осуществить автоматическое определение кодировки для каждой сущности. Кроме того, во многих случаях помимо собственно потока данных XML документа доступны и другие источники информации. В зависимости от того, была ли сущность XML представлена процессору с сопроводительной (внешней) информацией или же нет, можно наблюдать две ситуации. Сначала мы рассмотрим первую из них.
Поскольку ни одна из сущностей XML не сопровождается внешней информацией о кодировке и не пользуется кодировками UTF-8 или UTF-16, то первой должна идти декларация кодировки XML. Первыми ее символами должны быть '<?xml', которые способен обнаружить любой процессор, отвечающий требованиям спецификации. Для этого ему необходимо получит от двух до четырех октетов, различные комбинации которых рассматриваются ниже. Изучая перечень этих комбинаций, полезно будет знать, что в кодировке UCS-4 код символа '<' - "#x0000003C", символ '?' соответствует "#x0000003F", а Byte Order Mark, который обязателен для потоков данных в кодировке UTF-16, имеет код "#xFEFF". Запись ## обычно используется для обозначения любого байтового значения, за исключением того, что две следующих друг за другом нотации ## не могут обе соответствовать нулевому коду 00.
с Byte Order Mark:
без Byte Order Mark:
| UCS-4 или иная кодировка с 32-битным кодом, а также ASCII символы, кодированные как ASCII значения, с порядком следования байтов big-endian (1234), little-endian (4321) и нетипичными (2143 и 3412) соответственно. Чтобы определить, какая из поддерживаемых UCS-4 и других 32-битных кодировок используется, необходимо прочесть декларацию кодировки. |
Примечание:
Среди перечисленных выше вариантов есть такие, когда для определения кодировки нет необходимости читать соответствующую декларацию. Однако, согласно главе 4.3.3, декларация кодировки остается необходимой. Поэтому если эта декларация имеется, то ее необходимо прочесть, а полученное название сверить с действительной кодировкой данной сущности. Кроме того, в будущем могут появиться новые кодировки символов, которые потребуют декларирования даже в тех случаях, где сегодня кодировку можно распознать автоматически.
Описанный механизм автоматического распознавания кодировки достаточен для того, чтобы прочесть декларацию кодировки XML и получить идентификатор кодировки символов, который по-прежнему необходим для распознавания отдельных членов в каждой группе кодировок (например, чтобы выделить UTF-8 из 8859, отделить друг от друга отдельные части набора 8859, идентифицировать используемую кодовую страницу EBCDIC и так далее).
Поскольку содержимое декларации кодировки ограничено набором ASCII символов (хотя и скрыто под кодировкой), процессор сможет надежно прочесть всю декларацию кодировки, как только разберется, какая была использована группа кодировок. Поскольку практически все широко используемые кодировки символов попадают в одну из перечисленных выше категорий, то декларирование кодировки XML позволяет достаточно надежно обозначать кодировку символов даже в тех случаях, когда внешние источники информации в операционной системе или на уровне транспортного протокола окажутся ненадежны. Однако такие кодировки символов, как UTF-7, переопределяющие байты ASCII-значений, не могут быть идентифицированы надежно.
Как только процессор определил используемую кодировку символов, он волен поступать соответствующим образом, либо используя для каждой кодировки отдельную процедуру ввода, либо вызывая соответствующую процедуру преобразования для каждого введенного символа.
Как и любые другие самораспознаваемые системы, декларация кодировки XML не сможет работать, если какая-нибудь программа поменяла используемый для сущности набор символов или кодировку, не изменив при этом соответствующим образом декларацию кодировки. Программистам, разрабатывающим процедуры кодирования символов, необходимо тщательно проверять достоверность внешней и внутренней информации, используемой для маркировки сущностей.
Вторая из возможных ситуаций возникает когда XML сущность сопровождает информация о кодировке, извлекаемая из некоторых файловых систем и сетевых протоколов. Если имеется несколько источников информации, то их относительный приоритет и предпочтительный способ разрешения конфликтов должны определяться протоколом более высокого уровня, используемым для передачи XML документов. В частности, можно обратиться к [IETF RFC 2376] и наследующим его документам, определяющим типы MIME text/xml и application/xml, а также содержащим полезное руководство. Однако в целях совместимости желательно руководствоваться следующим правилом:
Если сущность XML находится в файле, то для определения кодировки символов, как правило, используются Byte-Order Mark и декларация кодировки (если таковые имеются).
Данная спецификация была подготовлена и принята к публикации рабочей группой W3C XML (W3C XML Working Group, WG). Однако из того, что WG приняла данную спецификацию, не следует, что все члены WG единогласно проголосовали за это решение. Настоящие и бывшие члены XML WG:
Вторая редакция данной спецификации была подготовлена основной рабочей группой W3C XML (W3C XML Core Working Group, WG). Членами группы на момент опубликования этой редакции являлись:
Вторая редакция спецификации была также преобразована в XMLspec DTD (для которой имеется соответствующая документация). HTML версии спецификации были получены с помощью XSLT стилей xmlspec.xsl, diffspec.xsl и REC-xml-2e.xsl. PDF версия документа была получена с помощью инструментария html2ps и программы выделения.
[an error occurred while processing this directive]