Исторический анализ форматов файлов-документов

Причины столь длительного пути к появлению единого международного стандарта на файл электронного документа можно понять, только проанализировав весь длительный путь развития обработки документов с помощью средств вычислительной техники. Исследуя историческую перспективу, также можно определить основные требования к формату файла – документа, достоинства и недостатки предлагаемых сегодня решений. Данный исторический обзор не претендует на полноту, однако авторы попытались остановиться на наиболее значимых моментах, необходимых по их мнению для понимания сегодняшнего состояния стандартизации форматов файлов.

ASCII

До середины пятидесятых годов прошлого столетия проблема обмена текстовой информациейперед создателями ЭВМ не стояла. Вычислительные системы были разобщены и каждая система оперировала собственной кодировкой символов. По мере прихода компьютеров в бизнес – сферу появилась необходимость электронного обмена. В то время, по воспоминаниям Роберта Бемера, разработчика ASCII, «Мы пользовались свыше 60 способами кодирования символов. Это было настоящим вавилонским столпотворением». В 1963 году комитет ANSI X3.4 опубликовал первую версию ASCII. ASCII (англ. American Standard Code for Information Interchange — американский стандартный код для обмена информацией) — 7-битную компьютерную кодировку для представления латинского алфавита, десятичных цифр, некоторых знаков препинания, арифметических операций и управляющих символов. ASCII следует считать одним из самых долгоживущих стандартов в истории вычислительной техники, с теми или иными изменениями он поддерживается практически всеми современными компьютерами. Возможности вычислительных систем 60-х годов позволяли отвести только по семь бит на символ, что ограничило размер кодовой таблицы128 символами, что было явно недостаточно для поддержки национальных алфавитов, отличных от латиницы. Некоторое время для кириллического и других алфавитов использовался принцип транслитерации — конверсия систем письма, при которой каждый графический элемент (знак) одной системы письма представляется (заменяется) одним и тем же графическим элементом другой системы письма. Транслит или кодировка «волапюк» еще и сегодня используется в устаревших системах мобильной связи при невозможности использовать кириллицу. Однако подобная ситуация не могла устраивать пользователей вычислительной техники и с появлением возможности добавить восьмой бит для кодирования символов произошел массовый переход на 8-битные кодировки, где появилась возможность использовать 256 символов.

Русские 8-битовые кодировки

Кодировки «нелатинских» алфавитных письменностей устроены следующим образом. Они кодируются восьмибитовой таблицей (1 байт = 1 символ), т. е. числами 0 - 255так, что младшая половина кодовой таблицы 0 - 127 десятичные совпадает с ASCII, а старшая половина 128 - 255 содержит национальную кодировку, т. е. русские буквы в русских кодовых таблицах, турецкие в турецких и т. д. Такая организация национальных кодовых таблиц позволяет правильно отображать и обрабатывать латинские буквы, цифры и знаки препинания на любом компьютере, независимо от его системных настроек. История русских кодировок — это пример неразберихи, редкостной даже для нашей компьютерной действительности. В ней, как в зеркале отразились все проблемы ранних лет российской компьютеризации, взаимоотношение между государством и сообществом программистов, проблемы по взаимодействию с международными организациями по стандартизации и много других аспектов. История русских восьмибитных кодировок требует подробного изучения и осмысления всякий раз, когда возникает вопрос о принятии нового стандарта в IT. Советские стандартизирующие организации принимали ГОСТы, производители компьютеров (Apple) и операционных систем (Microsoft) их дружно игнорировали и вводили собственные кодировки. В результате мы получили наследство из четырех разных ГОСТов, две кодировки от Microsoft (для DOS и для Windows), кодировку от Apple для Mac'ов, кодировку ISO, которой практически никто не пользуется (все, естественно, несовместимые между собой). Подробно эта ситуация описана в работе Roman Czyborra. В настоящее время наиболее часто можно встретить следующие кодовые страницы:

Windows-1251, она же Microsoft code page 1251 (CP1251), она же ANSI Cyrillic — в системах Windows;
Семейство кодовых страниц KOI8 — в системах на основе UNIX (и Linux);
Альтернативная кодировка, она же IBM code page 866 — в системах DOS;

Однако не исключена возможность получения файла и в другой, более «экзотической» кодировке. И хотя технологические проблемы преобразования текстов давно уже решены, а современные офисные пакеты, например OpenOffice.org, позволяю прочесть и сохранить файл практически в любой восьмибитной кодировке, неудобство подобной ситуации более чем очевидно. Несомненным достоинством традиционных кодовых таблиц является предельная краткость представления текстовой информации. Однако, эта краткость влечет за собой и несколько недостатков, органически с ней связанных:

Поскольку символы разных языков представляются одними и теми же значениями от 0 до 255, то для правильной их визуализации исполняющая система должна знать не только код символа, но и название кодовой таблицы. При этом, несмотря на все усилия стандартизаторов, разнобой в названии кодировок полный (например, ASCII может называться ANSI_X3.4-1968, ANSI_X3.4-1986, cp367, csASCII, IBM367, iso-ir-6, ISO646-US, ISO_646.irv:1991, ascii, us, us-ascii, us-ascii-1968, x-ansi; и так далее).
По этой же причине оказывается практически невозможным сочетание нескольких кодовых таблиц в одном документе. Это ведет к «типографской бедности» текстовых документов, поскольку громадное число полезных символов, не входящих в данную национальную кодировку, выбрасывается за борт.
Кодовые таблицы, ориентированные на алфавитные системы письма, не смогли решить проблему кодирования дальневосточных иероглифов и индийских слоговых азбук. Между прочим, это означает, что почти половина населения Земли лишена возможности работать с компьютером на родном языке.

Выход из ситуации был достигнут созданием стандарта Unicode.

UNICODE

Unicode - стандарт кодирования символов, позволяющий представить знаки практически всех письменных языков. Стандарт предложен в 1991 году некоммерческой организацией Unicode Consortium, объединяющей крупнейшие IT-корпорации. Применение этого стандарта позволяет закодировать очень большое число символов из разных письменностей: в документах Unicode могут соседствовать китайские иероглифы, математические символы, буквы греческого алфавита, латиницы и кириллицы, при этом становятся ненужными кодовые страницы. Стандарт состоит из двух основных разделов: универсальный набор символов (UCS, Universal Character Set) и семейство кодировок (UTF, Unicode Transformation Format). Универсальный набор символов задаёт однозначное соответствие символов кодам — элементам кодового пространства, представляющим неотрицательные целые числа. Семейство кодировок определяет машинное представление последовательности кодов UCS. Коды в стандарте Unicode разделены на несколько областей. Область с кодами от U+0000 до U+007F содержит символы набора ASCII с соответствующими кодами. Далее расположены области знаков различных письменностей, знаки пунктуации и технические символы. Часть кодов зарезервирована для использования в будущем. Под символы кириллицы выделены коды от U+0400 до U+052F. Для решения проблем с 8-битными кодировками было признано необходимым создание единой «широкой» кодировки. Предварительные расчеты показали, что для кодирования всех этих письменностей достаточно 16-битового диапазона, т. е. диапазона от 0000 до FFFF. Каждой письменности был выделен свой блок в этом диапазоне, который постепенно заполнялся кодами символов этой письменности. На сегодня кодирование всех живых официальных письменностей можно считать завершенным. Первая версия Юникода представляла собой кодировку с фиксированным размером символа в 16 бит, то есть общее число кодов было 216 (65 536). Отсюда происходит практика обозначения символов четырьмя шестнадцатеричными цифрами (например, U+0410). При этом в Юникоде планировалось кодировать не все существующие символы, а только те, которые необходимы в повседневном обиходе. Редко используемые символы должны были размещаться в «области символов для частного использования» (Private Use Area), которая первоначально занимала коды U+D800…U+F8FF. Чтобы использовать Юникод также и в качестве промежуточного звена при преобразовании разных кодировок друг в друга, в него включили все символы, представленные во всех более-менее известных кодировках. В дальнейшем, однако, было принято решение кодировать все символы и в связи с этим значительно расширить кодовую область. Одновременно с этим, коды символов стали рассматриваться не как 16-битные значения, а как абстрактные числа, которые в компьютере могут представляться множеством разных способов (см. Способы представления). Поскольку в ряде компьютерных систем (например, Windows NT) уже были реализованы 16-битные символы, было решено всё наиболее важное кодировать только в пределах первых 65 536 позиций (так называемая англ. Basic Multilingual Plane, BMP). Остальное пространство используется для «Дополнительных символов» (англ. Supplementary Characters): систем письма вымерших языков или очень редко используемых китайских иероглифов, математических и музыкальных символов. Для совместимости со старыми 16-битными системами была изобретена система UTF-16, где первые 65 536 позиций отображаются непосредственно как 16-битные числа, а остальные представляются в виде «суррогатных пар» (первый элемент пары из области U+D800…U+DBFF, второй элемент пары из области U+DC00…DFFF). Для суррогатных пар была использована часть кодового пространства, ранее отведённого для «символов для частного использования». Поскольку в UTF-16 можно отобразить только 220+216 (1 114 112) символов, то это и было выбрано в качестве окончательной величины кодового пространства Юникода. Хотя кодовая область Юникода была расширена за пределы 216 уже в версии 2.0, первые символы в «верхней» области были размещены только в версии 4.0. В настоящее время используется версия 5.0 UTF-8 (Unicode Transformation Format — формат преобразования Юникода) — это представление Юникода, обеспечивающее наилучшую совместимость со старыми системами, использовавшими 8-битные символы. Текст, состоящий только из символов с номером меньше 128, при записи в UTF-8 превращается в обычный текст ASCII. И наоборот, в тексте UTF-8 любой байт со значением меньше 128 изображает символ ASCII с тем же кодом. Остальные символы Юникода изображаются последовательностями длиной от 2 до 6 байтов (на деле, только до 4 байт, поскольку использование кодов больше 221 не планируется), в которых первый байт всегда имеет вид 11xxxxxx, а остальные — 10xxxxxx. Формат UTF-8 был изобретён 2 сентября 1992 года Кеном Томпсоном и Робом Пайком и реализован в экспериментальной операционной системе Plan 9. Сейчас стандарт UTF-8 официально закреплён в документах RFC 3629 и ISO/IEC 10646 Annex D. В настоящее время именно UTF-8 применяется в большинстве современных компьютерных систем.

Языки разметки текста

Однако для того, чтобы текстовый файл превратился в документ,сохранения и отображения только текста явно недостаточно. Любой документ имеет внутреннюю структуру, так или иначе связанную с его внешним представлением.Возможности существующих к началу 80-х годов форматов файлов, предназначенных только для хранения текстовых символов, не позволяли задать тексту дополнительные параметры. Это подтолкнуло отрасль к созданию специальных языков текста, позволяющих обозначить его логическую структуру. Под языком разметки текста в компьютерной терминологии принято пониматьнабор символов или последовательностей, вставляемых в текст для передачи информации о его выводе или строении. Текстовый документ, написанный с использованием языка разметки, содержит не только сам текст (как последовательность слов и знаков препинания), но и дополнительную информацию о различных его участках — например, указание на заголовки, выделения, списки и т. д. В более сложных случаях язык разметки позволяет вставлять в документ интерактивные элементы и содержание других документов. Разметка документа преследует следующие две основные цели:

выделение смысловых частей (логических элементов) документа и связей между ними;
указание действий, которые должны быть осуществлены с этими элементами.

Для достижения первой цели предназначена структурная разметка. Действия, направленные на получение внешнего представления, задаются разметкой представления. В качестве примеров приведены два возможных способа разметки.

<div1 type="Section"> <head>Введение</head> <p>Так уж сложилось, что большую часть информации человек предпочитает хранить в виде документов...</p> </div1>

<font face="Arial Bold" size=16>1. Введение<hspace size=20> <tab size=5><font face="Times New Roman" size=12> Так уж сложилось, что большую часть информации человек предпочитает хранить в виде документов...

В первом случае мы описываем раздел, который имеет заголовок и текст в виде абзаца, то есть определяем структуру документа. Структурная разметка говорит о том, как текст устроен, то есть из каких он частей состоит, и как эти части друг с другом соотносятся. Во втором случае мы показываем, каким образом данный текст должен быть отображен на бумаге или на мониторе — выделить шрифтом Arial Bold размера 16, отступить по вертикали 20, сделать табуляцию 5, выделить шрифтом Times New Roman размера 12. Здесь мы имеем дело с разметкой представления документа, которая говорит о том, что делать с текстом, как его отображать. Исторически разметка представления появилась раньше, и в течение длительного времени разметка документа была ориентирована исключительно на внешний (бумажный) вид документа. Но в последнее время ситуация существенно меняется — быстрый рост числа документов, их создание, хранение и использование в электронном виде, автоматизированная обработка и обмен документами предъявляют новые требования к разметке. В числе этих требований — независимость от среды представления, возможность осуществления эффективного поиска, возможность повторного использования как документа целиком, так и отдельных его элементов. Сейчас существует большое число устройств, с помощью которых можно отображать документы. Среди таких устройств — и дисплеи от компьютерных до мобильных, и принтеры от формата A1 до встроенных в кассовые аппараты, и различные синтезаторы речи, и многое другое. Для воспроизведения некоторого документа на всех этих устройствах требуется либо наличие огромного количества вариантов одного и того же документа, только размеченного разными способами, либо существование единой универсальной разметки и программных средств для корректного преобразования в соответствующее внешнее представление "на лету". Быстрый рост количества документов привел к тому, что поиск нужной информации стал занимать все больше и больше времени. Например, если нам необходимо найти в Интернет информацию об авторе статей по фамилии Дуров, то простой контекстный поиск даст нам огромное количество ссылок на те места, где встречается данная фамилия. После чего нам придется либо просмотреть все полученные ссылки, либо задавать дополнительную информацию для сужения области поиска. Если бы мы могли сразу указать, что фамилию следует искать только среди авторов журнальных статей технического плана, это во много раз упростило бы поиск. Но для этого необходимо, чтобы документы, среди которых ведется поиск, были размечены должным образом с явным выделением элементов "автор", "тематика" и т.п. Возможность повторного использования документов или отдельных его частей приводит к тому, что мы не составляем каждый раз заново отчет или деловое письмо, используем в своей работе шаблоны контрактов, изменяя лишь некоторую существенную для данного случая информацию. Но делаем мы это преимущественно вручную. Если говорить об автоматизированном формировании, связывании, повторном использовании документов, то это становится возможным только тогда, когда документы как информационные объекты являются структурированными, а используемая метаинформация полно и ясно описывает характеристики каждого элемента документа. Все перечисленные задачи можно решить, используя исключительно структурный подход при разметке документов. Именно структурная разметка позволяет выделять смысловые элементы, определять их связи с другими элементами как в рамках одного документа, так и вне этих рамок.
Среди тех, кто впервые сформулировал идеи языка разметки, называютУильяма В. Тунниклиффа , Брайана Рида и одного из активных создателей SGML Чарльза Гольдфарба. Однако первым, кто на практике реализовал идеи языка разметки и создал полноценный инструмент, позволяющий данный язык успешно использовать, был несомненно выдающийся американский математик и программист Дональд Кнут. Система TeX (произносится "тех", от слова "технология") была задумана профессором Стэнфордского университета Дональдом Э. Кнутом в процессе подготовки к изданию 3-го тома "Искусства программирования для ЭВМ". Оказалось, что существовавшие тогда средства подготовки к печати математических текстов совершенно непригодны для выполнения столь сложной работы быстро и качественно. Работа по созданию TeX началась в 1978 году и Кнут планировал закончить ее в течение своего годичного отпуска (sabbatical year, полагается университетским профессорам каждые семь лет), но несколько ошибся в сроках - окончательный вариант программы появился в 1985. С тех пор TeX сделался стандартом де-факто для многих серьезных издательских проектов: все книги самого Кнута набираются в TeX, статьи в издания American Mathematical Society, American Physical Society принимаются только в этом формате, он использовался во множестве проектов онлайн-документации. Примерно в одно время с выходом системы и языка разметки TeXД. Кнута, молодая в то время фирма Adobe в 1984 выпустила на рынок язык разметки PostScript.

PostScript

Postscript имел огромные преимущества перед другими коммерческими системами того времени:

Платформонезависимость. Один и тот же файл мог печататься как на лазерном принтере, выдававшем тогда 300 dpi, так и на фотонаборном устройстве с 2400 dpi с наилучшим качеством в каждом случае.
Любой производитель мог лицензировать интерпретатор PostScript и использовать PostScript со своим устройством.
Спецификации PostScript были общедоступны, таким образом, любой разработчик мог писать программы, поддерживающие PostScript.

Adobe рисковала, выпуская PostScript, и, возможно, ей не удалось бы убедить рынок в необходимости такого языка, если бы не Стив Джобс из Apple Computer. В 1985 году продажи компьютеров Macintosh начали падать, и Apple нужен был “killer app” – нечто, что мог бы только её компьютер. Стив Джобс инвестировал 2,5 миллиона долларов в Adobe, которая создала PostScript-контроллер для принтера Apple LaserWriter, и в Aldus, создавшую программу, использовавшую все возможности Macintosh и LaserWriter – PageMaker. Появившаяся тогда возможность допечатной подготовки на компьютере спасла Apple и превратила Adobe и Aldus в крупные компании. Другие производители фотонаборной аппаратуры, начиная с Linotype, оценили PostScript и вскоре оснастили свою фотонаборную аппаратуру интерпретаторами PostScript. PostScript стал стандартом в области допечатной подготовки. Фактически PostScript является полноценным языком программирования. Написанный вручную или созданный программой код с помощью интерпретатора языка превращается внабор графических команд печатающего устройства. С использованием возможностей языка PostScript фирма Adobe в 1993 году создала кроссплатформенный формат файла PDF (Portable Document Format), позволяющий отобразить практически на любом электронном устройстве, для которого существует программа просмотра документ в том виде, в котором он был задуман его автором, со всеми элементами разметки, а также вывести его на печать. Данный формат очень быстро стал стандартом в создании финальной копии электронных документов для их массового распространения. Фирма Adobe через некоторое время открыла спецификацию формата PDF , которая доступна на сайте компании и планирует направить данный формат в ISO для утверждения его в качестве открытого стандарта.

SGML

Стандартный обобщенный язык разметки (Standard Generalized Markup Language, SGML) был утвержден международной организацией по стандартизации (International Standards Organisation, ISO) в качестве стандарта ISO 8879:1986 в 1986 году. Изначально SGML был разработан для совместного использования машинно-читаемых документов в больших правительственных и аэрокосмических проектах. SGML — это метаязык, то есть средство формального описания прикладных языков разметки, предназначенных для кодирования структурированных документов. Разметка в SGML Разметка, определяемая в рамках SGML, основывается на двух постулатах:

разметка должна описывать структуру документа, а не указывать, что с документом или его частями должно происходить;
разметка должна быть строгой, чтобы программы и базы данных могли быть использованы для хранения и обработки размеченных документов. Структура документа с точки зрения SGML представляет собой граф компонентов, вершины которого являются компонентами, а ребра — связями между ними. Основным компонентом структурированного текста является элемент. Таким образом, можно сказать, что каждый структурированный документ состоит из некоторого набора семантических элементов, связанных друг с другом по определенным правилам.

Тело элемента (содержательный текст) обрамляется открывающим и закрывающим маркерами. Каждый маркер состоит из имени элемента, уникального для элементов одинаковой семантики, и может иметь некоторое количество атрибутов. Атрибуты предназначены для более детального описания текста среди семантически однородных элементов. Важным достоинством SGML является то, что он не определяет заранее имена элементов и их атрибуты. Например, если автор документа считает, что семантически корректнее определить в тексте два типа списков: список фамилий и список компаний, то он может ввести два элемента listofpeople и listofcompanies. В дальнейшем эти элементы могут обрабатываться как различные семантические единицы. Чтобы документ являлся синтаксически корректным с точки зрения SGML, необходимо, чтобы его разметка подчинялась некоторому набору правил, определяемых стандартом ISO. Одно из правил состоит в том, что допускается лишь полная вложенность одного элемента в другой. Таким образом, в каждом документе всегда будет один корневой элемент и некоторое количество иерархически вложенных элементов. (Вообще говоря, допускается наложение на документ двух независимых разметок, элементы одной из которых могут не являться вложенными в другую, но это предмет отдельного обсуждения.) Вложенность является одним из видов связей между вершинами графа компонентов. Размеченный документ предназначен для дальнейшей обработки различными программами, каждая из которых может применять свои правила обработки к тем или иным элементам документа. Одна программа может преобразовывать текст к виду, пригодному для печати на бумаге, а другая — лишь извлекать некоторые данные (например, названия терминов) и помещать их в таблицу или базу данных. Типы документов. Структурная разметка не предназначена для обеспечения удобочитаемости документов. Для этого существует разметка представления и соответствующие программные средства, преобразующие структурную разметку в разметку представления. Эти и другие программы, обрабатывающие документ, должны уметь распознавать элементы структуры и атрибуты элементов и применять необходимые операции к определенным элементам. В SGML это достигается с помощью определений типов документов (Document Type Definition, DTD), посредством конструкций языка, называемых декларациями элементов. В то время как разметка документа занимается описанием семантических единиц, DTD определяет набор всех возможных разметок документов описываемого типа. Тип документа формально определяется его составными частями и их структурой. Например, письмо можно определить как документ, имеющий реквизиты отправителя и получателя, заголовок, несколько абзацев и дату отправления. Если документ не имеет реквизитов отправителя, то, в соответствии с нашим определением, письмом он не является. DTD определяет допустимые элементы для данного типа документа на любом из уровней вложенности, допустимое содержание каждого из элементов и набор допустимых атрибутов. При этом наличие DTD является обязательным для любого документа. Можно сказать, что в рамках SGML имеют право на существование информационные объекты, состоящие из размеченного документа и его DTD. Декларация элементов в DTD определяет допустимое содержание как тела элемента, так и его атрибутов. Предположим, например, что необходимо дать определение элемента <list>, представляющего собой список. В этом случае декларации могут выглядеть так, как показано

<!ELEMENT list - - (head?, item+)> <!ELEMENT head - 0 (#PCDATA)> <!ELEMENT item - 0 (p+)> <!ELEMENT p- 0 (#PCDATA)>

Первая декларация (вторая строка листинга, так как первая является комментарием) обозначает, что список может включать необязательный заголовок, но обязательно содержит один или несколько элементов списка. Вторая декларация говорит, что заголовок содержит некоторое количество символов (текст). Третья декларация указывает на то, что каждый элемент списка, в свою очередь, состоит из одного или более абзацев. И, наконец, последняя декларация, как и вторая, говорит, что абзацы содержат символьный текст. Символ "0" в колонке MIN обозначает, что закрывающий маркер в данном элементе может быть опущен без нарушения структуры документа. Следующий открывающий маркер такого же элемента или маркер внешнего элемента фактически будет выполнять ту же функцию. Возможное использование списков приведено на примере

<list> <head>Перечень важных дел <item> <p>В 11-00 переговоры <p>Необходимо подготовить полный комплект документов <item> <p>В 14-00 совещание у руководства </list>

Работа с объектами. Одним из достоинств SGML является то, что он позволяет работать не только со структурированными текстами, но и с произвольными информационными объектами. Для этого вводится понятие объекта (entity). Объектом может быть строка символов или файл (текстовый или бинарный). Для включения его в документ используется конструкция, известная в ряде языков программирования как ссылка на объект. Например, объявление <!ENTITY SGML "Standard Generalized Markup Language"> определяет объект, называющийся SGML, значением которого является строка "Standard Generalized Markup Language". Это пример декларации объекта (entity declaration), которая содержит внутренний объект (internal entity). Следующее объявление, напротив, вводит системный объект (system entity): <!ENTITY picture SYSTEM "picture.gif"> В этом случае определен объект, являющийся рисунком, а не структурированным текстом. При обработке документа некоторой программой файл picture.gif может быть, например, выведен на экран монитора для иллюстрации соответствующего текста. Возможности и недостатки SGML. SGML представляет собой достаточно емкий и, в то же время, сложный метаязык. На его основе создаются языки разметки, используемые в различных областях: подготовка книг, документации, построение систем визуализации данных и т.д. Такие языки, как HTML, XML, MathML, CML и многие другие созданы на основе SGML и полностью ему соответствуют. Широта охвата порождает вместе с тем и ряд недостатков. Так, например, создание единого DTD для подготовки документации в рамках одной организации, несомненно, имеет преимущества, такие как унификация исходного кода, возможность автоматического индексирования данных, ведение единого словаря терминов, написание стандартных средств обработки документов, получение стандартного бумажного представления и т.п. Но как только мы выходим за рамки организации, проекта или отрасли, то все упирается в утверждение данного DTD в качестве общего стандарта. Кроме того, как только принимается стандарт на некоторый DTD, сразу начинается борьба за его расширение, и так может продолжаться до бесконечности. Другой недостаток проявляется при создании программ (например, для редактирования SGML-документов), которые должны позволять работать с любыми возможными DTD и учитывать все возможности, предоставляемые стандартом SGML. К сожалению, это возможно лишь теоретически, так как объем таких программ будет чрезвычайно велик.

HTML

Язык разметки HTML (от англ. Hypertext Markup Language — «язык разметки гипертекста») родился в Лаборатории физики высоких энергий (CERN) в Женеве в 1990 году и был разработан британским учёным Тимом Бернерсом-Ли. Первоначально HTML был предназначен для разметки научных документов и их последующего совместного использования сотрудниками разных институтов и лабораторий. HTML состоял из небольшого фиксированного набора элементов — заголовков нескольких уровней, абзацев, списков и др., но главной его особенностью было использование гиперссылок и специальных меток (anchors) для указания точек перехода. Все вместе позволяло достаточно легко размечать простые документы и устанавливать связи как между ними, так и между компонентами одного документа. Человек всегда обрабатывает и анализирует информацию нелинейным образом. Поэтому возможности нелинейного хранения информации, простота использования языка разметки и широкие возможности применения привели к тому, что популярность HTML стала быстро расти и вне академических рамок. Как это часто бывает с любыми гениальными открытиями, успех превзошел все ожидания создателей. Гонка стандартов. В 1992 году HTML был формализован в качестве SGML DTD, при этом в его спецификацию была заложена возможность дальнейшего расширения. Простой синтаксис языка, в отличие от SGML, позволял создавать простые программы для анализа размеченного текста и его отображения. Начался бурный рост публикаций в HTML-формате и рост числа приложений, поддерживающих этот формат. Потребности пользователей, а также конкурентная борьба производителей программного обеспечения привели к тому, что в HTML стали добавляться неспецифицированные элементы разметки. Отсутствие строгих синтаксических правил и использование нестандартных элементов вынудили производителей программного обеспечения допускать использование синтаксически некорректных конструкций. Отметим, что в WWW найдется не так много документов, полностью удовлетворяющих общепринятым спецификациям. В целях регулирования процесса роста и стандартизации предлагаемых решений для WWW в октябре 1994 года была создана координирующая рабочая группа — World Wide Web Consortium (W3C), которая сегодня объединяет представителей более чем 370 организаций. Основными задачами W3C являются накопление информации о WWW, необходимой как разработчикам, так и пользователям, подготовка и утверждение стандартов (технических спецификаций) на технологии, связанные с WWW, и создание прототипов и образцов приложений для демонстрации использования новых технологий. Положительная роль W3C в судьбе HTML очевидна — этот язык удалось сохранить от разделения на несколько диалектов, правда, ценой постоянного принятия все новых и новых расширенных спецификаций, которые сменяют друг друга с периодичностью раз в два года. Но нельзя же до бесконечности расширять язык, изначально предназначенный совсем для других целей! Борьба за перетягивание одеяла на свою сторону двумя крупнейшими разработчиками Web-навигаторов в конце концов привела к тому, что стандарты начали плыть, а пользователям приходилось очень часто менять программное обеспечение. Сами же пользователи все больше и больше становились зависимыми от разработчиков программных продуктов — у них не было возможности добавлять собственные расширения в языки разметки. Структура или представление. За время своего существования HTML претерпел множество изменений, что весьма неприятно для создателей документов и разработчиков программ. Но гораздо большей неприятностью стало то, что, изначально задуманный как язык структурной разметки, в результате своего развития HTML превратился в язык разметки представления. Чего стоит, например, форматирование документа для улучшения его внешнего вида с помощью таблиц! Исходный текст таких документов становится практически нечитаемым, а доля полезной информации составляет лишь несколько процентов. К счастью, ситуация постепенно начинает улучшаться. В последней на момент написания статьи версии языка HTML 4.01 содержится около 80 элементов. Темп роста их числа заметно уменьшился. Этому способствовало, прежде всего, введение атрибута CLASS во все элементы. Используя этот атрибут, можно определить новые семантические единицы без изменения синтаксиса языка в целом.Немного неуклюжее, но все же решение. Кроме того, несомненным шагом вперед (или назад) по направлению к структуризации языка стало удаление ряда элементов, отвечающих только за внешнее представление, и декларирование строгой необходимости использования таблиц стилей (style sheets) для целей внешнего представления.
Недостатки HTML. Несмотря на массовое признание и использование HTML, а также на ряд разумных шагов, предпринятых W3C, в HTML все еще имеются существенные недостатки. Отсутствие жесткой иерархии элементов приводит к тому, что один и тот же документ может быть размечен и, соответственно, будет интерпретироваться программным обеспечением различными способами. Так, например, текст HTML-документа или любая его часть может предваряться заголовком любого уровня, что оставляет автору слишком большую свободу выбора, а читателю создает некоторые трудности при работе с документами разных авторов. Далеко не всякая метаинформация может быть простым и корректным образом вставлена в документ, поэтому при преобразовании произвольного документа в формат HTML часть информации может быть потеряна. Использование атрибута CLASS только частично решает эту проблему. Для некоторых областей деятельности HTML не предоставляет возможностей ни структурно размечать требуемые элементы, ни правильным образом выводить их на экран или принтер. Математикам необходима возможность работы с формулами, химикам нужно отображать структуру химических соединений, и, вместе с тем, всем разработчикам и пользователям WWW необходимо наличие единых принципов разметки документов, универсальность их обработки и отображения.

XML

В предыдущих разделах мы попытались проанализировать достоинства и недостатки двух "идейных антиподов" среди языков разметки — SGML и HTML. С одной стороны, максималистский подход при создании SGML привел к чрезмерной сложности языка и соответствующих программных продуктов, что неприемлемо для массового потребления. С другой стороны, простота и ограниченность HTML создавала трудности при описании сложных информационных объектов, поиске необходимой информации, создании приложений, обменивающих данными через Интернет. Поэтому в 1996 году была сформирована рабочая группа W3C, основной задачей которой являлось создание нового языка разметки. Этот язык должен был включать в себя гораздо больше возможностей SGML, чем HTML, но, в то же время, оставаться подходящим для использования в WWW. Чуть позже этот язык стал известен как XML (eXtensible Markup Language, расширяемый язык разметки). Разработка нового языка разметки велась около двух лет, и в начале февраля 1998 года W3C утвердила в качестве рекомендации первую спецификацию XML — XML версии 1.0, а затем версию 1.1. За сравнительно недолгий срок с момента своего появления на свет XML сумел завоевать огромную популярность среди разработчиков Интернет-технологий. Число созданных и разрабатываемых программных продуктов на основе XML, число компаний, включающих поддержку XML в свои уже готовые продукты, количество публикаций в компьютерной прессе уже весьма велико и продолжает расти. Что это — дань моде или естественное желание сохранить конкурентоспособность, используя современные и прогрессивные технологии? Основные понятия. Как и SGML, XML является метаязыком для формального описания прикладных языков разметки, предназначенных для кодирования структурированных документов. Спецификация XML определяет, как стандартным способом разметить документ, выделяя все семантически значимые компоненты. При разработке нового языка разметки учитывались достоинства и недостатки уже существующих языков, а также то, что основным местом применения XML является Интернет. Основные требования к создаваемому языку были сформулированы следующим образом:

XML должен быть годен к непосредственному применению в Интернет.
XML должен быть совместимым с SGML (XML-документ должен одновременно являться и SGML-документом без внесения каких-либо изменений или дополнений).
Число необязательных свойств в XML должно быть минимальным, в идеале нулевым (любая XML-программа должна уметь читать любой XML-документ).
XML-документы должны быть легко читаемы с помощью простейших текстовых процессоров.
XML-разметка должна быть простой для понимания.

Формальное описание нового языка разметки состоит из нескольких взаимосвязанных частей:

Спецификации eXtensible Markup Language (XML) 1.0, которая определяет синтаксис языка.
Спецификаций XML Pointer Language (XPointer) и XML Linking Language (XLink), которые определяют стандартные механизмы установления связей между компонентами XML-документов.
Спецификации eXtensible Style Language (XSL), которая определяет механизмы для внешнего представления XML-документов.

Структура. По своей структуре XML-документ очень похож на SGML- или HTML-документ. В качестве примера приведен уже упоминавшийся текст. Существует несколько основных правил составления XML-документа.

<?xml version="1.0"?> <Section> <head-of-section>Введение</head-of-section> <paragraph>Так уж сложилось, что большую часть информации человек предпочитает хранить в виде документов...</paragraph> </Section>

Каждый документ начинается с пролога. В данном случае — это инструкция <?xml version="1.0"?>, которая является XML-декларацией. Ее наличие идентифицирует XML-документ и указывает, какой версии XML он соответствует. В данном листинге нет указания на используемое определение типа документа (DTD), так как, в отличие от SGML, XML не требует обязательного определения DTD для каждого документа. При необходимости описание или указание на месторасположение DTD также помещается в прологе документа. За прологом следует тело документа, которое представляет собой жесткую структуру элементов, подчиняющихся принципу вложенности. Именование элементов либо соответствует объявленному DTD, либо произвольно. Обязательным является наличие как открывающего, так и закрывающего маркера в каждом элементе, ибо без этого при отсутствии DTD определить структуру документа невозможно. Каждый из элементов может по аналогии с SGML содержать атрибуты, предназначенные для более детального описания семантически однородных элементов. Возможно наличие пустых элементов, то есть элементов без содержимого. Такие элементы обозначаются с помощью символа '/' перед закрывающей угловой скобкой, например: <Empty-Marker/> В общем случае XML-документ может иметь шесть типов компонент:

элементы;
ссылки на текстовые или бинарные объекты (entity references);
комментарии;
инструкции обработки;
отмеченные разделы данных (CDATA sections);
декларация типа документов.

Не останавливаясь подробно на всех типах компонентов, отметим лишь, что инструкции обработки, в соответствии со своим названием, предназначены для предоставления информации программам, которые будут в дальнейшем обрабатывать документ. Тип документа определяется тем же способом, что и в SGML, а отмеченные разделы данных позволяют передавать размещенные в них данные или текст "как есть", без анализа его структуры. Структурная и синтаксическая корректность. Необязательность определения DTD, с одной стороны, существенно облегчает XML-разметку, но, с другой стороны, может значительно усложнить программы обработки. Каким образом определить в данном случае корректность XML-документа? Чтобы определить класс правильно составленных (с точки зрения XML) документов, вводятся понятия структурной и синтаксической корректности. XML-документ является структурно корректным, если он отвечает следующим требованиям:

Конструкция документа должна отвечать общим правилам составления документа, определенным в спецификации. В частности, некоторые конструкции (например, инструкция <?xml version="1.0"?>) могут присутствовать только в определенных местах документа.
Никакой атрибут не используется более одного раза в одном маркере элемента.
Значения атрибутов не ссылаются на внешние объекты.
Все непустые элементы удовлетворяют принципу вложенности.
Все используемые объекты продекларированы.
Нет ссылок на бинарные объекты непосредственно из текста. Такие ссылки возможны лишь в момент декларации объекта.
Текстовые объекты не являются рекурсивными.

По определению, если документ не является структурно корректным, то он не является и XML-документом. При наличии у документа DTD возможна его проверка на синтаксическую корректность. При этом XML-документ считается синтаксически корректным, если он, во-первых, является структурно корректным, а, во-вторых, полностью соответствует всем правилам, изложенным в соответствующем DTD. Ссылки в XML-документах. Для языка разметки с непредопределенными названиями элементов и даже отсутствующим иногда DTD невозможно определить стандарт на механизм связывания через элементы. Напротив, ссылающиеся и указуемые объекты должны иметь специальные атрибуты, которые идентифицируют их в этом качестве. Все элементы XML имеют специально зарезервированный атрибут XML-LINK. Присутствие этого атрибута в элементе определяет наличие ссылки, а значение атрибута указывает, какой тип ссылки в данном месте используется. В XML, в отличие от HTML, возможно создание не только однонаправленных гипертекстовых ссылок по типу "один-к-одному", но и:

Двунаправленных ссылок. Используя HTML и перейдя по стандартной гипертекстовой ссылке на новую страницу, пользователь имеет только одну возможность перехода назад — нажатием кнопки "Back" в Web-навигаторе. При использовании двунаправленных ссылок пользователь не только может вернуться по ссылке в то место, откуда пришел, но и перейти на те страницы, которые ссылаются на указуемый объект.
Ссылок с возможностью перехода к одному или нескольким объектам ("один-ко-многим"). У пользователя появляется возможность выбора между несколькими точками назначения при использовании всего одной ссылки.
Ссылок к объектам, размещенным в базах данных. Гипертекстовые ссылки в HTML опираются только на файловую адресацию информации, а XLink предоставляет возможность динамического изменения адресов местонахождения информации с помощью баз данных.

То, что произойдет при переходе по ссылке, определяется атрибутом SHOW, который может иметь одно из следующих значений: EMBED, REPLACE, NEW. В первом случае указуемый объект будет импортирован в то место, откуда идет ссылка. Это произойдет либо при показе документа, либо при его обработке. Такой подход может быть полезен при вставке некоторого текста из другого файла, или для вставки картинки внутрь текста. При этом возможна как автоматическая подстановка объекта, так и ручная, требующая от пользователя некоторых действий. Во втором случае ссылающийся объект будет заменен на указуемый. Это может быть полезным, например, при наличии двух вариантов некоторого компонента. При помощи этого механизма возможен просмотр обеих версий или обработка по выбору, в зависимости от наличия тех или иных инструкций обработки. В последнем случае исходный объект исчезает, и происходит полный переход к указуемому объекту. Такой механизм реализован в обычных гипертекстовых ссылках, когда при переходе по ссылке на экране отображается новая HTML-страница. Механизмы ссылок и адресации в XML описываются в трех спецификациях W3C: XPath, XPointer и Xlink. Xlink описывает механизмы связывания: организацию многонаправленных и однонаправленных ссылок между ресурсами, аннотированных ссылок и внешних наборов ссылок. XPath поддерживает спецификацию месторасположений в XML-документах в терминах элементов и списков элементов и является языком для адресации частей XML-документа. Xpath использует компактный не-XML-синтаксис для возможности применения XPath внутри указателей ресурсов и значений атрибутов XML. Он оперирует с абстрактной структурной моделью документа, а не с его синтаксическим выражением, и моделирует документ как некое дерево элементов для осуществления навигации по иерархической структуре XML-документа. XPointer, построенный на основе XPath, определяет язык для поддержки адресации внутренних структур XML-документа. В частности, он позволяет определять ссылки к элементам, символьным строкам и т.п. вне зависимости от того, имеют ли они универсальный атрибут идентификации (ID). Для этого XPointer использует структуру документа и возможность выбора его частей на основе типов элементов, значений атрибутов, относительного расположения, содержания или порядка следования элемента. Так, например, возможно ссылаться на первый абзац третьей главы. И даже после осуществления другой разбивки на главы и абзацы или добавления нескольких абзацев впереди указуемого эта ссылка все равно приведет нас именно к первому абзацу третьей главы. Это свойство чрезвычайно полезно, если нужно сослаться на некоторое место в чужом документе, к которому нет прав на редактирование, а автор не расставил меток на требуемом участке документа. XLink определяет конструкции, которые могут быть использованы в XML-документах для описания связей между объектами. XLink может описывать простые ссылки (simple links), которые очень похожи на гипертекстовые ссылки в HTML, но при этом они могут быть более детально классифицированы, например, по типу приложения, которое будет использовать данный документ. Кроме этого, XLink в комбинации с XPointer может описывать расширенные ссылки (extended links) и указуемые точки объекта, являющиеся многонаправленными по своей природе. Косвенные ссылки (indirect links) позволяют упростить сопровождение большого количества документов. Рассмотрим случай, когда необходимо изменить месторасположение какого-нибудь документа, скажем, перенести его в другой каталог или на другой сервер. При использовании простых гипертекстовых ссылок это привело бы к необходимости найти все места во всех документах, откуда определены ссылки на перемещаемый документ, и внести соответствующие исправления. При этом разрешения на редактирование ко всем документам получить практически нереально. Потребуются просто титанические усилия, чтобы осуществить задуманное, поэтому документ, на который ссылаются другие документы, становится неперемещаемым по файловой системе. С использованием косвенных ссылок все оказывается гораздо проще. Связывание документов происходит не напрямую, а через некоторый промежуточный файл ссылок. При изменении месторасположения документа необходимо лишь внести изменения в этот промежуточный файл, а все остальные документы при этом останутся нетронутыми. Отображение документов. Используя XML, автор документа может самостоятельно определять тот набор элементов, который наиболее точным образом будет соответствовать его структурным компонентам. Но свобода выбора имеет свою цену — набор используемых элементов не обладает предопределенной семантикой. Для совместной работы с XML-документами необходим стандартный механизм получения внешнего представления. Таким механизмом для XML является XSL (eXtensible Style Language, расширяемый язык стилей). Обычные таблицы стилей, используемые, например, для работы с HTML, содержат набор инструкций, которые говорят программе (Web-навигатору, текстовому редактору или процессору печати), каким образом преобразовывать структуру документа во внешнее представление. При этом таблицы стилей, как правило, содержат такие инструкции, как:

отображать гипертекстовые связи синим цветом;
начинать главу с новой страницы;
вести сквозную нумерацию рисунков по всему документу.

Необходимо понимать, что использование или наложение стиля — это не что иное, как преобразование исходного документа к требуемому виду. Документ, отображаемый на экране, и документ, написанный и размеченный автором — это совсем не одно и тоже. Степень трансформации может меняться в зависимости от презентационных целей — страница документа для публикации в Интернет и для высококачественной полноцветной полиграфической печати должна обрабатываться по-разному, но в любом случае требуется некоторое преобразование. Использование языков разметки с предопределенной семантикой позволяет существенно упростить реализацию таблицы стилей. Программа, обрабатывающая, например, размеченную таблицу, может отобразить ее различным способом, но она заранее, даже без использования таблицы стилей, знает, что обрабатываемый объект является таблицей. В случае использования XML-разметки XSL не только должен определять, каким образом тот или иной элемент будет отображаться, скажем, на экране, но и каким объектом он будет в итоге являться. Для того чтобы передать содержание XML-документа наиболее эффективным образом, необходимо две вещи: стандартный язык, описывающий требуемую разметку на выходе (в XSL это форматирующие объекты — formatting objects), и средство для преобразования исходного документа к требуемой разметке (в XSL это язык трансформации — transformation language). XSL включает стандартный словарь форматирующих объектов с хорошо определенными свойствами для осуществления контроля. Эти форматирующие объекты, такие как страница, блок текста, таблица, список и другие, позволяют авторам стилей получать высококачественное внешнее представление. Работа с XML начинается с обработки исходного текста программой-анализатором (parser). Эта программа проверяет структурную и синтаксическую корректность XML-документа и создает дерево элементов исходного документа. Далее вступает в действие XSL-процессор, который в качестве исходных данных берет построенное дерево и соответствующий стиль. Шаг за шагом, начиная с корневого элемента, XML-процессор по шаблону, определенному в таблице стилей, обрабатывает всю структуру документа. Получающееся в результате дерево элементов может состоять из форматирующих объектов, которые и описывают внешнее представление документа. Форматирующие объекты представляют собой описание, независимое от устройства представления, и, следовательно, конечный документ может быть использован различными устройствами вывода. Возможна и альтернатива форматирующим объектам. Так, в случае необходимости преобразования к HTML-виду, вместо форматирующих объектов будут использованы элементы языка разметки HTML. При этом результирующий документ будет выглядеть очень похожим на HTML-документ и обрабатываться стандартными Web-навигаторами. Однако следует понимать, что любое XSL-преобразование XML-документа в результате даст тоже XML-документ. Основными преимуществами XSL над другими механизмами наложения стилей, помимо возможности работы с элементами непредопределенной семантики, являются:

возможность изменения порядка следования элементов в результирующем документе;
возможность сортировки и сравнения элементов текста (список используемых терминов, упомянутых авторов);
повторная обработка некоторых элементов (например, для печати разными стилями названия главы в начале страницы, в колонтитуле, оглавлении);
возможность генерации вспомогательного текста ("Глава", "Оглавление", "Список иллюстраций" и т.п.);
подавления вывода некоторого текста (удаление редакторских примечаний или вывод только предисловия, а не полного документа).

WYSIWYG

Несмотряна высокою технологическую зрелость и активное использование языков разметки, например при создании сложных комплексов документации, в сети Интернет и во множестве других приложений, массового распространения в офисной деятельности данные средства создания документов длительное время не находили должного применения. Это объясняется прежде всего тем, что долгое время разметка документов производилась как правило вручную, для создания качественного документа необходимо было обладать целым рядом специфических навыков, уметь «держать в голове» код страницы, представляя себе, как он будет выглядеть на экране или бумаге. Для большинства офисных служащих подобный подход к созданию документов был просто неприемлем. Рынок приложений дляконечных пользователей на долгие годы захватили проприетарные текстовые процессоры, работающие по способу редактирования WYSIWYG. WYSIWYG (сокращение от What You See Is What You Get, англ. что видишь, то и получишь) - способ редактирования, при котором материал в процессе редактирования выглядит примерно так же, как и конечный результат. Термин WYSIWYG впервые использовали Арлин и Хосе Рамос, опубликовав в 70-е годы серию статей в газете Стенфордского университета, в которых ои сформулировали представление о современных системах допечатной подготовки текста . Фраза «What You See Is What You Get» принадлежит известному американскому комику Лерою «Флипу» Вильсону, чей персонаж Джеральдино был популярен в среде американских IT специалистов в семидесятые годы прошлого века. Первыми продуктами, где данная технология была реализована, хотя и в неполном объеме, принято считать редактор Bravo для компьютеров Xerox Alto и систему презентации Bruno для систем HP-1000. Первыми действительно массовыми редакторами стали WordStar компании MicroPro, WordPerfect иMS Word. Работая под управлением операционной системы MS DOS, они весьма ограниченно реализовывали концепциюWYSIWYG, показывая разметку разными цветами. Только MS Word позволял реально видеть текст, набранный «жирным» или «курсивным» текстом. По настоящему полноценным WYSIWYG редактором под MS DOS можно назвать разве что ChiWriter, разработанный Каем Хортсманном в 1986 году для работы с математическими формулами. Ситуация коренным образом изменилась с появлением компьютеров Macintosh, а затем выходом в 1990 году операционной системы MS Windows 3.0. В течение очень короткого времени появилось с десяток редакторов текста, реализующих полноценную технологиюWYSIWYG на персональном компьютере, из которых самыми популярными и заметными были уже знакомые WordPerfect иMS Word. В то время никто серьезно не задумывался о необходимости интероперабельности, ресурсы вычислительной техники были достаточно ограничены и массовое появление столь значительного количества доступных средств редактирования текста породило значительное количествонесовместимыхмежду собой бинарных форматов файлов документов. Каждый производитель тщательно берег свой формат файла, постоянно выпускал новые версии продукта, соревнуясь с другими добавлении новых возможностей в программные продукты и постоянно изменяя структуру формата файла. Во многих случаях даже между версиями форматов файлов одного и того же производителя не было совместимости и пользователи были вынуждены сохранять документы в простом ASCII файле и заново размечать их. К концу 90-х годов в этой конкурентной борьбе явно определились два лидера - MS Word и WordPerfect. Ценой титанических усилий путем реверс-инжиниринга программисты обоих компаний смогли обеспечить базовую совместимость между форматами файлов, однако полной ее нельзя было назвать. Постепенно серьезные ошибки в маркетинговой политики свели позицииWordPerfect практически к нулю, и примерно к 2000 году текстовый процессор MS Word, входящий уже в то время в состав пакета MS Office и его формат файла .doc сталистандартом де-факто электронного документа в большинстве стран мира. Однако подобная ситуация не могла продолжаться слишком долго. По мере роста объема документами между различными коммерческими, правительственными и иными организациями, ростом числа публикаций документов в Интернет все яснее ставилась непригодность данного формата:

Формат .doc является бинарным, не имеет читаемой внутренней структуры, что делает практически невозможным его автоматическое преобразование.
Формат .doc является собственностью компании Microsoft и кроме продуктов ее разработки полностью никем не поддерживается. Поэтому любой пользователь становиться заложником данной компании, вынужденный покупать новые версии ПО, дабы не потерять доступа к своим документам.
Формат .doc не стандартизован даже внутрикомпании Microsoft, имеется несколько несовместимых между собой версий.
Формат .doc избыточен, несет значительное количество ненужной, в том числе и конфиденциальной метаинформации, позволяет распространять макровирусы.

Избыточность этого формата неоднократно играла злые шутки с его пользователями. Так, широко известен скандал, когда в 2003 году в сети Интернет был опубликован доклад премьер-министра Великобритании Тони Блэра по проблеме Ирака в формате .doc, по метаинформации которого журналисты легко определили, что данный докладявляется практически полным плагиатом американских исследователей, что породило серьезный международный скандал. К честикомпании Microsoft следует сказать, что именно там впервые ясно осознали все вышеперечисленные проблемы, что заставило ее достаточно рано приступить к разработке и опубликованию формата файла RTF.

RTF

Rich Text Format (RTF) — проприетарный межплатформенный формат хранения размеченных текстовых документов, предложенный Microsoft. Первая версия стандарта RTF появилась в 1987 году, с тех пор спецификация формата несколько раз изменялась, в настоящее время действует версия 1.9.34] Права на этот формат целиком принадлежат корпорации Microsoft, однако с самой первой версии она была доступна всем желающим. Формат построен на использовании управляющих последовательностей, начинающихся с литеры «\». Так, например, фрагмент кода

\pard\plain \ltrpar\s1\cf0{\*\hyphen2\hyphlead2\hyphtrail2\hyphmax0}\rtlch\af6\afs24\lang255\ltrch\dbch\af4\langfe255\hich\f1\fs20\lang1049\loch\f1\fs20\lang1049 {\rtlch \ltrch\loch\f1\fs20\lang1049\i0\b0 Hello, World} \par \pard\plain \ltrpar\s1\cf0{\*\hyphen2\hyphlead2\hyphtrail2\hyphmax0}\rtlch\af6\afs24\lang255\ltrch\dbch\af4\langfe255\hich\f1\fs20\lang1049\loch\f1\fs20\lang1049 {\rtlch \ltrch\loch\f1\fs20\lang1049\i0\b0 \'c7\'e4\'f0\'e0\'e2\'f1\'f2\'e2\'f3\'e9 \'cc\'e8\'f0} \par }

в текстовом редакторе будет иметь вид

Hello, World Здравствуй Мир

В представленном фрагменте кода хорошо видно, что кодирование в RTF является семибитным. Легко можно прочесть текст на английском языке, однако текст на русском задается с помощью escape-последовательностей с кодом символа в необходимой кодировке. Например, если задана кодировка Windows-1251, то код \'e8 соответствует букве и. Если требуется символ в Юникоде, используется код \u, сразу после которого указывается 16-битное число в десятичной системе счисления, а за ним — символ для представления в программах, не имеющих поддержки Юникода. Таким образом, одно из основных достоинств RTF — возможность чтения кода человеком, выполняется только для английских символов. К другим недостаткам данного формата следует отнести тот факт, что он поддерживает только базовое форматирование и совместимость этого формата с бинарным форматом .doc была всегда далеко не полной. Однако формат получил заметное распространение и сегодня его поддерживают практически всеWYSIWYG — редакторы.
Таким образом, к 2000 году создались все предпосылки для создания международного открытого формата офисного документа:

Тотальное господство на рынке формата .doc создавало серьезные трудности для развития всей IT — отрасли.
Был накоплен большой практический опыт в создании интерфейсовWYSIWYG — редакторов.
XML из экзотического формата данных превратился в обычное средство хранения и представления.
Массовый переход на UNICODE в виде UTF-8 позволил решить проблему с кодировками, в том числе и для восточных языков.

В подобной ситуации появление нового формата данных стало просто вопросом времени

Создано: 14.03.08 15:02

Изменено: 14.03.08 18:26

Продукты