Schemas openxmlformats org что это

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

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

Сегодняшним постом я хочу начать еще одну серию. В ней я планирую немного поговорить о том, что представляют собой файлы 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:

Что представляют собой контейнеры в 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

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

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

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

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

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

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

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

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

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

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

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

Вот, по большому счету и все, что касается модели пакета в 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

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

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

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

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

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

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

Источник

Свойства документа и области сведений о документах

Дата последнего изменения: 7 июля 2010 г.

Применимо к: SharePoint Server 2010

В этой статье
Основные свойства документа
Зависящие от приложения
Настраиваемые свойства документа
Свойства документа типа контента

Свойства документа, вводимые пользователем в области сведений о документах, сохраняются в специальных разделах файлов форматов Open XML. Для документов, хранящихся в Microsoft SharePoint Foundation, значения этих свойств при обновлении их в документе повышаются до уровня библиотеки документов в виде значений столбцов. Аналогичным образом, при обновлении значений столбцов типа контента в пользовательском интерфейсе SharePoint Foundation новые значения понижаются до уровня документа в виде свойств документа.

Дополнительные сведения о работе с Open XML см. в описании сценариев Open XML (Возможно, на английском языке).

Основные свойства документа

Основные свойства документа являются общими для всех приложений Office 2010. К ним относятся название, тема и категория документа. Эти свойства хранятся в части основных свойств файла в документе форматов Open XML. В этой части содержится элемент coreProperties.

В SharePoint Foundation представлены следующие сопоставления столбцов и основных свойств документа:

Автор (сопоставляется с основным свойством документа «Создатель»)

Комментарии (сопоставляется с основным свойством документа «Описание»)

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

В следующем примере показана часть основных свойств файла для документа форматов Open XML.

Зависящие от приложения

Зависящие от приложения свойства документа являются уникальными для документа на уровне приложения. К ним относятся число страниц, число строк текста и версия приложения. Эти свойства содержатся в части расширенных свойств файла в форматах Open XML.

По умолчанию в SharePoint Foundation не включаются столбцы, сопоставленные с расширенными свойствами документа. В общем случае значения таких свойств определяются автоматически на основе контента документа (например, на основе числа страниц или строк в документе).

В следующем примере показаны расширенные свойства документа Microsoft Word. В этом примере документ Microsoft Word содержит одну страницу с тремя абзацами текста общим объемом в 45 слов.

Настраиваемые свойства документа

Определяемые пользователем свойства, которые содержатся в части настраиваемых свойств файла в форматах Open XML. Для документов, хранящихся в библиотеке SharePoint Foundation, эта часть содержит настраиваемое свойство, определяющее идентификатор типа контента, назначенного документу, как показано в следующем примере.

Свойство идентификатора типа контента никогда не повышается из документа до уровня библиотеки документов, в которой он располагается.

В документах Office 2010, сохраненных в двоичном формат (например, DOC), все настраиваемые свойства, в том числе и свойства, сопоставляемые со столбцами SharePoint Foundation, хранятся в одном месте. Привязка столбцов SharePoint Foundation к свойствам в документах Office 2010, сохраненных в двоичном формате, не поддерживается. При сохранении двоичного файла в форматах Open XML в SharePoint FoundationSharePoint Foundation предпринимает попытку рационализировать свойства, присутствующие в документе. Если документ содержит настраиваемое свойство с тем же именем и типом данных, что и столбец в библиотеке документов SharePoint Foundation, в которой он сохраняется, в SharePoint Foundation эти два свойства считаются одинаковыми, в результате чего свойство документа в форматах Open XML перемещается соответствующим образом. Однако такая рационализация свойств документа не выполняется для файлов, изначально сохраненных в форматах Open XML.

Свойства документа типа контента

Свойства документа, определенные в назначенном документу типе контента, которые содержатся в разделе customXml файла форматов Open XML. В частности, эти свойства содержатся в узле documentManagement элемента хранилища данных свойств.

Примечание

Каждый элемент хранилища данных в разделе customXml содержится в части itemN.xml, где N — это произвольный номер. В связи с этим при работе с элементами хранилища данных их следует идентифицировать по корневому элементу пространства имен, а не по имени части.

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

На следующем рисунке показан порядок назначения и хранения свойств документа как в документе, так и в библиотеке документов. В этом примере тип контента для документа содержит столбец «Название», который сопоставляется основному свойству документа «Название». Кроме того, этот тип контента также содержит два столбца свойств A и B. Значения этих свойств сохраняются в документе в разделе customXml элемента хранилища данных свойств. При изменении значений в области сведений о документах обновляются значения в самом документе. Обновленные значения повышаются до уровня библиотеки документов при его сохранении в библиотеке. Аналогичным образом, при изменении значения столбца в библиотеке документов обновленное значение понижается до уровня документа в виде соответствующего свойства документа при следующей его загрузке.

Источник

Коротко об 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?FamilyId=941B3470-3AE9-4AEE-8F43-C6BB74CD1466&displaylang=en), после установки которого чтение и сохранение документов формата OpenXML может осуществляться и прежними версиями Office.

Отметим, что формат 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:

Источник

• ← Как называется документ в программе эксель
• Анатомичность матраса что это →

Примечание