Top-office11.ru

IT и мир ПК
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Application vnd openxmlformats officedocument wordprocessingml

Файлы MS Office «изнутри». Open Packaging Conventions. Базовые принципы. Компоненты и связи

Сегодняшним постом я хочу начать еще одну серию. В ней я планирую немного поговорить о том, что представляют собой файлы MS Office “изнутри”, а также об инструментах (утилитах и библиотеках) для их создания, изучения, изменения, …

Прежде чем перейти к содержательной части некоторый предваряющий disclaimer (традиционно ):

Я в основном буду касаться современных офисных форматов, тех что появились в редакции Office 2007. Их еще называют XML-based форматами, в противовес старым бинарным (и это закрепилось в расширении файлов: docx, pptx, xlsx, … – в противовес doc, ppt, xls, …), ну или просто Open XML

Некоторая часть статей (по крайней мере в самом начале) будет основана на материалах Open XML Developer Workshop (контент и видео), который вел Doug Mahugh. Если вам не хочется ждать моих статей рекомендую обратиться к этим материалам

Еще одним хорошим подспорьем для изучающих Open XML будет книга Воутер Ван Вугт. OpenXML. Кратко и доступно. Ранее она в электронном виде была доступна в блоге евангелиста Microsoft Владимира Габриеля, но теперь – увы. Так что, если вам интересно и не хочется тратить время на поиск, можете взять здесь.

Вроде бы все. Можно приступать.

Что такое Open Packaging Conventions?

В двух словах, это формат контейнеров, поддерживающих хранение как структурированных (XML), так и неструктурированных компонентов (картинки, видео, бинарные компоненты, …) в одном файле.

Краткая но довольно информативная статья об OPC есть на wikipedia.

Что можно сказать в общем об этом стандарте/формате? Я бы выделил такие моменты:

● Формальное описание является частью ECMA-376. Office Open XML File Formats, более конкретно – второй частью Part 2 — Open Packaging Conventions.

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

Например, вот несколько форматов, основанных на OPC от самого Microsoft:

o .docx, pptx, xlsx, .vsdx – форматы Word, Power Point, Excel и Visio

o .xps (.oxps) – формат “электронной бумаги” или формат c фиксированной разметкой, предназначенный для передачи документов без искажения форматирования (в чем-то аналог PDF).

o .vsix – формат расширений Visual Studio, начиная с версии 2010

o .cspkg – формат пакетов для Windows Azure Cloud Services

o .appx – формат пакетов приложений Windows Store (для Windows 8)

Что представляют собой контейнеры в OPC?

Тут нужно сделать одну существенную оговорку: сам стандарт разбивает описание контейнеров на 2 части: абстрактную модель (которая описывает из каких элементов состоят контейнеры, но ни слова не говорит о том как это должно храниться физически) и физический формат пакета, т.е. конкретную реализацию.

Т.е. в чистой теории, контейнер в OPC может храниться единый файл, а может, например, как набор отдельных ресурсов на Web-сервере. Но (!) на текущий момент определена только 1 реализация – в виде единого файла ZIP-архива.

Структура контейнеров в OPC

Вообще говоря, концептуальная схема пакетов в Open Packaging Conventions очень проста, она включает в себя всего два элемента:

компоненты (parts), которые собственно и содержат хранящийся контент (любой: xml, image, video, …)

отношения (relationships), которые определяют

o предназначение (смысл/семантику) каждой части

o отношения между частями, а также между частями и пакетом целиком

Компоненты

Как уже было сказано выше компонент в OPC это и есть основная единица хранения контента. Каждый компонент характеризуется 2-я составляющими: именем и типом содержимого.

Имя компонента состоит из набора сегментов, начинающихся с прямого слэша (“/”), вот несколько примеров:

В спецификации приведены более формальные правила построения имен, из которых я укажу только основные (на мой взгляд):

● все имена должны начинаться с прямого слэша (“/”) и не должны им заканчиваться

● имя недолжно содержать пустых сегментов (т.е. /images//image1.jpg – неправильное имя)

«, «:«, «@»

● ни одно имя компонента не должно строиться как имя уже существующего компонента + новый сегмент. Т.е. если есть компонент с именем /abc/abc, то компонент с именем /abc/abc/a существовать не может, зато вполне может существовать компонент с именем /abc/abcde

● имена могут записываться Unicode-символами или использовать кодирование в виде /a/%D1%86.xml

Тип содержимого компонента задается в соответствии с RFC 2616 (раздел Media Types) т.е. в виде / :

Связи

Любой компонент в пакете (а также сам пакет) может ссылаться на другие компоненты или некоторые ресурсы за пределами пакета. Для представления этих ссылок введен специальный механизм связей. По большому счету, связи позволяют решить 2 задачи:

● получить список связанных с компонентом ресурсов, без необходимости анализировать его содержимое (которое может быть очень большим, иметь разную структуру, быть зашифрованным или вообще не поддерживать хранение ссылок)

● поменять набор связей компонента, не меняя его содержимого (которое может быть, например, зашифровано или защищено цифровой подписью)

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

Информация о связях для каждого компонента (а также самого пакета), хранится в специальных компонентах связей (relationships parts) тип содержимого которых application/vnd.openxmlformats-package.relationships+xml

Имена компонентов связи строятся из имени исходных компонент, к которым:

● добавляется предпоследний сегмент с именем _rels

● дописывается “расширение” .rels

Связи самого пакета хранятся в специальном компоненте с именем /_rels/.rels

Например, если в пакете у нас есть компонент с именем /document/mainPart.xml и два связанных компонента с картинками (пусть их мена будут /images/image1.png и /images/image2.jpeg), то пакет для них будет иметь следующую структуру:

Содержимое компонента связи представляет собой XML следующего формата:

Как уже наверняка понятно из приведенного фрагмента, каждый тэг определяет одну связь. Его атрибуты:

Id

Идентификатор связи. На него ссылаются из содержимого компонент, когда необходимо использовать конкретную связь.

Type

Тип связи. По сути дела тип указывает семантику связи. Например, две разных связи могут указывать на 2 компонента типа image/jpeg, но одно изображение будет картинкой в тексте документа, а второе – миниатюрой (thumbnail) всей страницы целиком.
В качестве типа может использоваться любой валидный URI

TargetMode

(Необязательный) Принимает одно из возможных значений:

· Internal (значение по умолчанию) – указывает, что связь ссылается на компонент пакета

· External – связь указывает на ресурс за пределами пакета

Target

Адрес ресурса или компонента на который ссылается связь

Важный момент: для обращения к компонентам и внешним ресурсам можно использовать как абсолютные адреса (для компонент это будет их полное имя), так и относительные. В последнем случае полное имя компоненты рассматривается как путь в файловой системе, каждый сегмент, кроме последнего – имя “папки”, а последний – имя “файла”. Вот несколько примеров такой адресации:

Имя исходного компонента

Относительный адрес

Результирующий адрес

Вот, по большому счету и все, что касается модели пакета в OPC. Осталось сказать несколько слов о физической реализации пакетов

Пакеты на основе ZIP-архивов

Как уже было сказано выше, в спецификации OPC определена только одна реализация пакетов – на основе ZIP архивов. Она достаточно проста, поэтому я приведу её обзорно:

● все компоненты, как обычные, так и компоненты связей, хранятся в виде одного или нескольких файлов внутри архива (при этом логически они все равно адресуются как единое целое)

● для хранения типа контента каждого компонента в архиве создается специальный файл с именем [Content_Types].xml

Внутри файла [Content_Types].xml хранится XML следующего вида:

Собственно, общая схема, я думаю, понятна и так: для описания типов используется два подхода:

● указание типа по расширению (тэг )

● явное указание типа для конкретного компонента (тэг )

Как заглянуть внутрь OPC-пакета?

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

Вот несколько способов как это можно сделать:

Прямой (“рукопашный”) способ. Т.к. физическая реализация OPC есть ни что иное, как обычный ZIP-архив, то самый простой способ его изучить – распаковать и работать как с обычной папкой (ну или воспользоваться любимым архиватором).

Читать еще:  Для изменения этих параметров требуется разрешение администратора

o Плюс подхода – будете глубже понимать устройство.

▪ Сложно отслеживать связи между компонентами (а именно они образуют структуру, а вовсе не “папки” архива)

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

Open XML Package Editor Power Tool for Visual Studio 2010. Расширение для Visual Studio. Умеет открывать файлы в формате OPC, показывать и редактировать их логическую структуру (добавлять/удалять/редактировать компоненты и связи). Для редактирования содержимого компонент используется редакторы самой VS, что очень удобно для экспериментов (XML редактор в VS явно не самый плохой, особенно если в наличии есть хорошие XSD-описания).

▪ Так и не нашел способа создать пакет с 0 (но это редко нужно, да и обходится созданием пакета вручную).

▪ Требует Visual Studio.

▪ Работает только в 2010 версии VS. Увы, для более новых версий студии пакет так и не обновился, хотя почти наверняка он заработает без доработок в любой последующей. А доработать установщик пакета руками не получается, т.к. это не обычный vsix

Standalone приложение от Воутера Ван Вугта Open XML Package Explorer. По возможностям оно близко к предыдущему расширению для VS, но не требует ничего для установки, кроме .Net 3.0. У него даже есть встроенный редактор XML, правда уступающий редактору от VS. К сожалению, приложение давно не обновлялось имеет ряд неприятных ошибок… но пользоваться можно.

Пара слов в заключение

Как видите, стандарт OPC в своей основе довольно прост и функционален. Однако остались еще ряд нераскрытых тем. В частности мы не рассмотрели ряд возможностей, заложенных в формат OPC:

● базовые метаданные пакета (core properties)

● иконки пакета (thumbnails)

● цифровые подписи (digital signatures)

Ну и, конечно, мы еще ни слова не проговорили об API для работы с OPC пакетами.

Как я разбирал docx с помощью XSLT

Задача обработки документов в формате docx, а также таблиц xlsx и презентаций pptx является весьма нетривиальной. В этой статье расскажу как научиться парсить, создавать и обрабатывать такие документы используя только XSLT и ZIP архиватор.

Зачем?

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

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

Поэтому в этой статье будем использовать только самые базовые инструменты для работы с docx документом.

Структура docx

Для начала разоберёмся с тем, что собой представляет docx документ. docx это zip архив который физически содержит 2 типа файлов:

  • xml файлы с расширениями xml и rels
  • медиа файлы (изображения и т.п.)

А логически — 3 вида элементов:

  • Типы (Content Types) — список типов медиа файлов (например png) встречающихся в документе и типов частей документов (например документ, верхний колонтитул).
  • Части (Parts) — отдельные части документа, для нашего документа это document.xml, сюда входят как xml документы так и медиа файлы.
  • Связи (Relationships) идентифицируют части документа для ссылок (например связь между разделом документа и колонтитулом), а также тут определены внешние части (например гиперссылки).

Они подробно описаны в стандарте ECMA-376: Office Open XML File Formats, основная часть которого — PDF документ на 5000 страниц, и ещё 2000 страниц бонусного контента.

Минимальный docx

Простейший docx после распаковки выглядит следующим образом

Давайте посмотрим из чего он состоит.

[Content_Types].xml

Находится в корне документа и перечисляет MIME типы содержимого документа:

_rels/.rels

Главный список связей документа. В данном случае определена всего одна связь — сопоставление с идентификатором rId1 и файлом word/document.xml — основным телом документа.

word/document.xml

  • — сам документ
  • — тело документа
  • — параграф
  • — run (фрагмент) текста
  • — сам текст
  • — описание страницы

Если открыть этот документ в текстовом редакторе, то увидим документ из одного слова Test .

word/_rels/document.xml.rels

Здесь содержится список связей части word/document.xml . Название файла связей создаётся из названия части документа к которой он относится и добавления к нему расширения rels . Папка с файлом связей называется _rels и находится на том же уровне, что и часть к которой он относится. Так как связей в word/document.xml никаких нет то и в файле пусто:

Даже если связей нет, этот файл должен существовать.

docx и Microsoft Word

docx созданный с помощью Microsoft Word, да в принципе и с помощью любого другого редактора имеет несколько дополнительных файлов.

Вот что в них содержится:

  • docProps/core.xml — основные метаданные документа согласно Open Packaging Conventions и Dublin Core [1], [2].
  • docProps/app.xml — общая информация о документе: количество страниц, слов, символов, название приложения в котором был создан документ и т.п.
  • word/settings.xml — настройки относящиеся к текущему документу.
  • word/styles.xml — стили применимые к документу. Отделяют данные от представления.
  • word/webSettings.xml — настройки отображения HTML частей документа и настройки того, как конвертировать документ в HTML.
  • word/fontTable.xml — список шрифтов используемых в документе.
  • word/theme1.xml — тема (состоит из цветовой схемы, шрифтов и форматирования).

В сложных документах частей может быть гораздо больше.

Реверс-инжиниринг docx

Итак, первоначальная задача — узнать как какой-либо фрагмент документа хранится в xml, чтобы потом создавать (или парсить) подобные документы самостоятельно. Для этого нам понадобятся:

  • Архиватор zip
  • Библиотека для форматирования XML (Word выдаёт XML без отступов, одной строкой)
  • Средство для просмотра diff между файлами, я буду использовать git и TortoiseGit

Инструменты

Также понадобятся скрипты для автоматического (раз)архивирования и форматирования XML.
Использование под Windows:

  • unpack file dir — распаковывает документ file в папку dir и форматирует xml
  • pack dir file — запаковывает папку dir в документ file

Использование под Linux аналогично, только ./unpack.sh вместо unpack , а pack становится ./pack.sh .

Использование

Поиск изменений происходит следующим образом:

  1. Создаём пустой docx файл в редакторе.
  2. Распаковываем его с помощью unpack в новую папку.
  3. Коммитим новую папку.
  4. Добавляем в файл из п. 1. изучаемый элемент (гиперссылку, таблицу и т.д.).
  5. Распаковываем изменённый файл в уже существующую папку.
  6. Изучаем diff, убирая ненужные изменения (перестановки связей, порядок пространств имён и т.п.).
  7. Запаковываем папку и проверяем что получившийся файл открывается.
  8. Коммитим изменённую папку.

Пример 1. Выделение текста жирным

Посмотрим на практике, как найти тег который определяет форматирование текста жирным шрифтом.

  1. Создаём документ bold.docx с обычным (не жирным) текстом Test.
  2. Распаковываем его: unpack bold.docx bold .
  3. Коммитим результат.
  4. Выделяем текст Test жирным.
  5. Распаковываем unpack bold.docx bold .
  6. Изначально diff выглядел следующим образом:


Рассмотрим его подробно:

docProps/app.xml

Изменение времени нам не нужно.

docProps/core.xml

Изменение версии документа и даты модификации нас также не интересует.

word/document.xml

Изменения в w:rsidR не интересны — это внутренняя информация для Microsoft Word. Ключевое изменение тут

в параграфе с Test. Видимо элемент и делает текст жирным. Оставляем это изменение и отменяем остальные.

word/settings.xml

Также не содержит ничего относящегося к жирному тексту. Отменяем.

7 Запаковываем папку с 1м изменением (добавлением ) и проверяем что документ открывается и показывает то, что ожидалось.
8 Коммитим изменение.

Пример 2. Нижний колонтитул

Теперь разберём пример посложнее — добавление нижнего колонтитула.
Вот первоначальный коммит. Добавляем нижний колонтитул с текстом 123 и распаковываем документ. Такой diff получается первоначально:

Сразу же исключаем изменения в docProps/app.xml и docProps/core.xml — там тоже самое, что и в первом примере.

[Content_Types].xml

footer явно выглядит как то, что нам нужно, но что делать с footnotes и endnotes? Являются ли они обязательными при добавлении нижнего колонтитула или их создали заодно? Ответить на этот вопрос не всегда просто, вот основные пути:

  • Посмотреть, связаны ли изменения друг с другом
  • Экспериментировать
  • Ну а если совсем не понятно что происходит:


Идём пока что дальше.

word/_rels/document.xml.rels

Изначально diff выглядит вот так:

Видно, что часть изменений связана с тем, что Word изменил порядок связей, уберём их:

Опять появляются footer, footnotes, endnotes. Все они связаны с основным документом, перейдём к нему:

Читать еще:  В качестве исключительно основных административных наказаний назначаются

word/document.xml

Редкий случай когда есть только нужные изменения. Видна явная ссылка на footer из sectPr. А так как ссылок в документе на footnotes и endnotes нет, то можно предположить что они нам не понадобятся.

word/settings.xml

А вот и появились ссылки на footnotes, endnotes добавляющие их в документ.

word/styles.xml

Изменения в стилях нас интересуют только если мы ищем как поменять стиль. В данном случае это изменение можно убрать.

word/footer1.xml

Посмотрим теперь собственно на сам нижний колонтитул (часть пространств имён опущена для читабельности, но в документе они должны быть):

Тут виден текст 123. Единственное, что надо исправить — убрать ссылку на .

В результате анализа всех изменений делаем следующие предположения:

  • footnotes и endnotes не нужны
  • В [Content_Types].xml надо добавить footer
  • В word/_rels/document.xml.rels надо добавить ссылку на footer
  • В word/document.xml в тег надо добавить

Уменьшаем diff до этого набора изменений:

Затем запаковываем документ и открываем его.
Если всё сделано правильно, то документ откроется и в нём будет нижний колонтитул с текстом 123. А вот и итоговый коммит.

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

Практика

Найдя интересующее нас изменение, логично перейти к следующему этапу, это может быть что-либо из:

  • Создания docx
  • Парсинг docx
  • Преобразования docx

Тут нам потребуются знания XSLT и XPath.

Давайте напишем достаточно простое преобразование — замену или добавление нижнего колонтитула в существующий документ. Писать я буду на языке Caché ObjectScript, но даже если вы его не знаете — не беда. В основном будем вызовать XSLT и архиватор. Ничего более. Итак, приступим.

Алгоритм

Алгоритм выглядит следующим образом:

  1. Распаковываем документ.
  2. Добавляем наш нижний колонтитул.
  3. Прописываем ссылку на него в [Content_Types].xml и word/_rels/document.xml.rels .
  4. В word/document.xml в тег добавляем тег или заменяем в нём ссылку на наш нижний колонтитул.
  5. Запаковываем документ.

Распаковка

В Caché ObjectScript есть возможность выполнять команды ОС с помощью функции $zf(-1, oscommand). Вызовем unzip для распаковки документа с помощью обёртки над $zf(-1):

Создаём файл нижнего колонтитула

На вход поступает текст нижнего колонтитула, запишем его в файл in.xml:

В XSLT (файл — footer.xsl) будем создавать нижний колонтитул с текстом из тега xml (часть пространств имён опущена, вот полный список):

В результате получится файл нижнего колонтитула footer0.xml :

Добавляем ссылку на колонтитул в список связей основного документа

Сссылки с идентификатором rId0 как правило не существует. Впрочем можно использовать XPath для получения идентификатора которого точно не существует.
Добавляем ссылку на footer0.xml c идентификатором rId0 в word/_rels/document.xml.rels :

Прописываем ссылки в документе

Далее надо в каждый тег добавить тег или заменить в нём ссылку на наш нижний колонтитул. Оказалось, что у каждого тега может быть 3 тега — для первой страницы, четных страниц и всего остального:

Добавляем колонтитул в [Content_Types].xml

Добавляем в [Content_Types].xml информацию о том, что /word/footer0.xml имеет тип application/vnd.openxmlformats-officedocument.wordprocessingml.footer+xml :

В результате

Весь код опубликован. Работает он так:

  • in.docx — исходный документ
  • out.docx — выходящий документ
  • TEST — текст, который добавляется в нижний колонтитул

Выводы

Используя только XSLT и ZIP можно успешно работать с документами docx, таблицами xlsx и презентациями pptx.

Коротко об OpenXML

Одна из любимых задач бизнес-пользователей

Вот уже более десятка лет разработчики бизнес-приложений регулярно сталкиваются с задачей генерации документов в форматах, поддерживаемых наиболее популярными офисными приложениями. Подобные задачи ставятся заказчиками проектов по разработке или внедрению информационных систем из-за того, что офисные приложения (в нашей стране это в первую очередь различные версии Microsoft Office), как правило, в той или иной мере знакомы всем бизнес-пользователям, а это существенно упрощает и удешевляет их обучение, обязательно проводимое в процессе внедрения новых решений, а также сопровождение самого решения.

Какие технологии обычно используются разработчиками для генерации подобных документов? Последние десять лет наиболее распространенным способом генерации документов формата Microsoft Office являлась технология COM (Component Object Model) — одна из базовых технологий Windows. Ее применение основано на том, что приложения Microsoft Office, равно как и многие приложения и службы самой операционной системы Windows, реализуют свои прикладные программные интерфейсы в виде COM-интерфейсов, доступных внешним приложениям. Практически все, что может сделать пользователь любого приложения семейства Microsoft Office с помощью меню, клавиатуры и панели инструментов, может быть реализовано в автоматическом режиме, то есть путем манипуляции соответствующим офисным приложением из бизнес-приложения, генерирующего соответствующие документы.

Читатели, интересующиеся деталями применения технологии COM для генерации офисных документов, могут обратиться к публикациям в нашем издании примерно семилетней давности (см., например, цикл статей «Автоматизация приложений Microsoft Office в примерах» в КомпьютерПресс № 11 и 12’2000) — эти материалы по-прежнему доступны на нашем сайте www.compress.ru. В данной же публикации мы не будем вдаваться в многократно обсуждавшиеся технические подробности, а вместо этого обратим внимание на один из недостатков этого подхода, который в конце 90-х годов казался несущественным, но сегодня должен обязательно учитываться.

Представим себе информационную систему, в которой генерация документов формата Microsoft Office должна осуществляться централизованно, а сами документы должны быть предназначены для применения большим количеством пользователей. Подобные требования могут предъявляться к средству генерации, например, еженедельных отчетов для менеджмента на основе корпоративной базы данных либо нормативной документации наподобие должностных инструкций на основании данных, регулярно обновляемых в том или ином средстве управления бизнес-процессами. Наиболее удобно при решении подобных задач осуществлять генерацию документов автоматически по расписанию, без участия пользователя, причем не на рабочей станции, а на сервере. Применение технологии COM в этом случае налагает серьезные ограничения на серверную операционную систему (это обязательно должна быть одна из версий Windows) и вынуждает иметь на сервере установленные офисные приложения. Очевидно, что генерация документов без наличия собственно офисных приложений была бы более удобной, ведь в этом случае серверное приложение не обязано работать под управлением той же платформы, что и офисные приложения. А это, в свою очередь, означает, что для создания подобных решений нужно, чтобы формат данных офисных приложений был документирован.

Форматы некоторых офисных приложений Microsoft были документированы вплоть до 2000 года, однако начиная с Office 2000 компания Microsoft перестала предоставлять доступ к спецификациям этих форматов, потому единственным способом корректной генерации документов Microsoft Office с этого момента и до выхода Office 2007 было применение все той же технологии COM. Однако после выхода Office 2007 данная ситуация изменилась — теперь формат офисных приложений Microsoft стал открытым и документированным. А это означает, что решения, генерирующие офисные документы, можно создавать в отсутствие самих офисных приложений — более того, создавать их на любой платформе.

Что такое OpenXML

Как было отмечено выше, идея открытого формата офисных документов отнюдь не нова. Однако именно в последнее время наметилась тенденция массового перехода офисных приложений к открытым форматам. Так, известный офисный пакет OpenOffice.org поддерживает открытый формат ODF (Open Document Format), спецификация которого является общедоступной, а кроме того, сегодня доступен и инструментарий разработки приложений, работающих с документами в формате ODF, — ODF Toolkit.

Формат OpenXML полностью поддерживает функциональность всех версий Microsoft Office — он позволяет сохранять все особенности документов, созданных с помощью Microsoft Office 2007 и предшествующих версий.

То, что существует техническая возможность создавать и сохранять документы формата OpenXML с помощью приложений, отличных от Microsoft Office 2007, интересно в первую очередь разработчикам бизнес-приложений и системным интеграторам. Что касается пользователей, их должна больше заинтересовать уже реализованная возможность его применения — например чтение и сохранение файлов формата OpenXML может быть осуществлено в рамках трех предыдущих версий Microsoft Office (начиная с Office 2000). Так, при попытке открыть документ этого формата с помощью Office 2003 пользователю будет предложено загрузить соответствующий конвертор (он доступен по адресу: http://www.microsoft.com/downloads/details.aspx?Family >

Отметим, что формат OpenXML поддерживается не только офисными приложениями Microsoft — недавно компания Novell объявила о том, что версия OpenOffice, поставляемая ею на рынок, тоже будет поддерживать указанный формат.

Стандарты OpenXML

Формат OpenXML является отраслевым стандартом — в декабре организация ECMA стандартизовала спецификацию OpenXML.

Данный стандарт включает ряд более детальных стандартов. Главным из них является стандарт OPC (Open Packaging Convention), описывающий структуру файла, наличие различных типов данных в документе, взаимосвязь его составных частей, а также, при необходимости, цифровую подпись. Помимо OPC, структура документов OpenXML использует такие стандарты, как WordprocessingML, описывающий разметку текстовых документов, SpreadSheetML, определяющий структуру электронных таблиц, PresentationML, задающий структуру презентаций, DravingML, указывающий структуру графиков, диаграмм и некоторых графических объектов, а также стандарты, описывающие формулы, выражения и метаданные документа.

Читать еще:  Microsoft office standard 2020 ключик активации

Отметим, что формат OpenXML предполагает различные способы интеграции данных документа с данными других приложений — он позволяет не просто применять схему форматирования, соответствующую функциональности современных версий офисных пакетов, но и определять свои схемы, позволяющие обмениваться данными с бизнес-приложениями.

Внутри документов OpenXML

СС точки зрения пользователя, документ в формате OpenXML представляет собой ZIP-архив. В этом можно убедиться, создав документ в Microsoft Word 2007, Microsoft Excel 2007 или Microsoft PowerPoint 2007 и заменив его расширение на *.zip. Этот архив содержит XML-данные, бинарные части, а также XML-описания их взаимосвязей.

Рассмотрим пример простейшего документа Word, cодержащего обычный текст, гиперссылку и графическое изображение (рис. 1).

Рис. 1. Пример документа Microsoft Word 2007

Данный документ имеет расширение *.docx (документ Microsoft Word 2007, не содержащий макросов). Заменив его расширение на *.zip и открыв его с помощью любого архиватора, поддерживающего метод упаковки ZIP, мы увидим структуру, изображенную на рис. 2.

Рис. 2. Структура документа Microsoft Word 2007

В корневой папке архива находится описание типов данных, содержащихся в документе, — внимательное изучение этого описания позволяет понять, что в документе имеется, к примеру, графическое изображение в формате GIF:

Коротко об OpenXML

Одна из любимых задач бизнес-пользователей

Вот уже более десятка лет разработчики бизнес-приложений регулярно сталкиваются с задачей генерации документов в форматах, поддерживаемых наиболее популярными офисными приложениями. Подобные задачи ставятся заказчиками проектов по разработке или внедрению информационных систем из-за того, что офисные приложения (в нашей стране это в первую очередь различные версии Microsoft Office), как правило, в той или иной мере знакомы всем бизнес-пользователям, а это существенно упрощает и удешевляет их обучение, обязательно проводимое в процессе внедрения новых решений, а также сопровождение самого решения.

Какие технологии обычно используются разработчиками для генерации подобных документов? Последние десять лет наиболее распространенным способом генерации документов формата Microsoft Office являлась технология COM (Component Object Model) — одна из базовых технологий Windows. Ее применение основано на том, что приложения Microsoft Office, равно как и многие приложения и службы самой операционной системы Windows, реализуют свои прикладные программные интерфейсы в виде COM-интерфейсов, доступных внешним приложениям. Практически все, что может сделать пользователь любого приложения семейства Microsoft Office с помощью меню, клавиатуры и панели инструментов, может быть реализовано в автоматическом режиме, то есть путем манипуляции соответствующим офисным приложением из бизнес-приложения, генерирующего соответствующие документы.

Читатели, интересующиеся деталями применения технологии COM для генерации офисных документов, могут обратиться к публикациям в нашем издании примерно семилетней давности (см., например, цикл статей «Автоматизация приложений Microsoft Office в примерах» в КомпьютерПресс № 11 и 12’2000) — эти материалы по-прежнему доступны на нашем сайте www.compress.ru. В данной же публикации мы не будем вдаваться в многократно обсуждавшиеся технические подробности, а вместо этого обратим внимание на один из недостатков этого подхода, который в конце 90-х годов казался несущественным, но сегодня должен обязательно учитываться.

Представим себе информационную систему, в которой генерация документов формата Microsoft Office должна осуществляться централизованно, а сами документы должны быть предназначены для применения большим количеством пользователей. Подобные требования могут предъявляться к средству генерации, например, еженедельных отчетов для менеджмента на основе корпоративной базы данных либо нормативной документации наподобие должностных инструкций на основании данных, регулярно обновляемых в том или ином средстве управления бизнес-процессами. Наиболее удобно при решении подобных задач осуществлять генерацию документов автоматически по расписанию, без участия пользователя, причем не на рабочей станции, а на сервере. Применение технологии COM в этом случае налагает серьезные ограничения на серверную операционную систему (это обязательно должна быть одна из версий Windows) и вынуждает иметь на сервере установленные офисные приложения. Очевидно, что генерация документов без наличия собственно офисных приложений была бы более удобной, ведь в этом случае серверное приложение не обязано работать под управлением той же платформы, что и офисные приложения. А это, в свою очередь, означает, что для создания подобных решений нужно, чтобы формат данных офисных приложений был документирован.

Форматы некоторых офисных приложений Microsoft были документированы вплоть до 2000 года, однако начиная с Office 2000 компания Microsoft перестала предоставлять доступ к спецификациям этих форматов, потому единственным способом корректной генерации документов Microsoft Office с этого момента и до выхода Office 2007 было применение все той же технологии COM. Однако после выхода Office 2007 данная ситуация изменилась — теперь формат офисных приложений Microsoft стал открытым и документированным. А это означает, что решения, генерирующие офисные документы, можно создавать в отсутствие самих офисных приложений — более того, создавать их на любой платформе.

Что такое OpenXML

Как было отмечено выше, идея открытого формата офисных документов отнюдь не нова. Однако именно в последнее время наметилась тенденция массового перехода офисных приложений к открытым форматам. Так, известный офисный пакет OpenOffice.org поддерживает открытый формат ODF (Open Document Format), спецификация которого является общедоступной, а кроме того, сегодня доступен и инструментарий разработки приложений, работающих с документами в формате ODF, — ODF Toolkit.

Формат OpenXML полностью поддерживает функциональность всех версий Microsoft Office — он позволяет сохранять все особенности документов, созданных с помощью Microsoft Office 2007 и предшествующих версий.

То, что существует техническая возможность создавать и сохранять документы формата OpenXML с помощью приложений, отличных от Microsoft Office 2007, интересно в первую очередь разработчикам бизнес-приложений и системным интеграторам. Что касается пользователей, их должна больше заинтересовать уже реализованная возможность его применения — например чтение и сохранение файлов формата OpenXML может быть осуществлено в рамках трех предыдущих версий Microsoft Office (начиная с Office 2000). Так, при попытке открыть документ этого формата с помощью Office 2003 пользователю будет предложено загрузить соответствующий конвертор (он доступен по адресу: http://www.microsoft.com/downloads/details.aspx?Family >

Отметим, что формат OpenXML поддерживается не только офисными приложениями Microsoft — недавно компания Novell объявила о том, что версия OpenOffice, поставляемая ею на рынок, тоже будет поддерживать указанный формат.

Стандарты OpenXML

Формат OpenXML является отраслевым стандартом — в декабре организация ECMA стандартизовала спецификацию OpenXML.

Данный стандарт включает ряд более детальных стандартов. Главным из них является стандарт OPC (Open Packaging Convention), описывающий структуру файла, наличие различных типов данных в документе, взаимосвязь его составных частей, а также, при необходимости, цифровую подпись. Помимо OPC, структура документов OpenXML использует такие стандарты, как WordprocessingML, описывающий разметку текстовых документов, SpreadSheetML, определяющий структуру электронных таблиц, PresentationML, задающий структуру презентаций, DravingML, указывающий структуру графиков, диаграмм и некоторых графических объектов, а также стандарты, описывающие формулы, выражения и метаданные документа.

Отметим, что формат OpenXML предполагает различные способы интеграции данных документа с данными других приложений — он позволяет не просто применять схему форматирования, соответствующую функциональности современных версий офисных пакетов, но и определять свои схемы, позволяющие обмениваться данными с бизнес-приложениями.

Внутри документов OpenXML

СС точки зрения пользователя, документ в формате OpenXML представляет собой ZIP-архив. В этом можно убедиться, создав документ в Microsoft Word 2007, Microsoft Excel 2007 или Microsoft PowerPoint 2007 и заменив его расширение на *.zip. Этот архив содержит XML-данные, бинарные части, а также XML-описания их взаимосвязей.

Рассмотрим пример простейшего документа Word, cодержащего обычный текст, гиперссылку и графическое изображение (рис. 1).

Рис. 1. Пример документа Microsoft Word 2007

Данный документ имеет расширение *.docx (документ Microsoft Word 2007, не содержащий макросов). Заменив его расширение на *.zip и открыв его с помощью любого архиватора, поддерживающего метод упаковки ZIP, мы увидим структуру, изображенную на рис. 2.

Рис. 2. Структура документа Microsoft Word 2007

В корневой папке архива находится описание типов данных, содержащихся в документе, — внимательное изучение этого описания позволяет понять, что в документе имеется, к примеру, графическое изображение в формате GIF:

Ссылка на основную публикацию
Adblock
detector
×
×