17 Пакеты
правитьВ этом разделе описан формат пакета, который может быть необязательно использован в OpenDocument. Он содержит следующие подразделы:
- введение;
- структура zip-файла;
- шифрование;
- изображение предварительного просмотра;
- файл декларации.
17.1 Введение
правитьПоскольку XML не имеет никакой собственной поддержки двоичных объектов типа изображений, [OLE]-объектов, или других медиа-типов, а также несжатые XML-файлы могут стать очень большими, OpenDocument использует пакетный файл, чтобы хранить содержимое XML-документа вместе со своими связанными двоичными данными, и произвольно сжимает содержимое XML. Пакет — это стандартный zip-файл, структура которого рассмотрена ниже.
Информация о файлах, содержащихся в пакете, сохраняется в XML-файле, называемом файлом декларации. Файл декларации всегда сохраняется в каталоге META-INF с именем файла META-INF/manifest.xml. В декларации записываются следующие основные информационные части:
- список всех файлов в пакете;
- медиа-тип каждого файла в пакете;
- если файл, сохраненный в пакете, зашифрован, в декларации сохраняется информация, необходимая для его расшифровки.
17.2 Структура zip-файла
правитьZip-файл начинается с последовательности файлов, каждый из которых может быть сжат или сохранен в необработанном формате. Каждый файл, непосредственно перед своими данными, имеет локальный заголовок, который содержит наибольшее количество информации о файле, включая временные метки, метод сжатия и имя файла. Содержание сжатого файла следует непосредственно далее и заканчивается необязательным дескриптором данных. Дескриптор данных содержит CRC (циклический избыточный код) и размер сжатого файла, которые часто не доступны при записи локального заголовка файла. Дескриптор данных может быть пропущен, если эти детали уже были включены в заголовок.
В приведенном формате каждый файл в архиве располагается последовательно и сопровождается центральным каталогом в конце zip-архива. Центральный каталог — это непрерывное множество элементов каталога, каждый из которых содержит всю информацию в локальном заголовке файла, плюс дополнения, типа комментариев и атрибутов файла. Очень важно, что центральный каталог содержит указатели на позицию каждого файла в архиве, которые делают навигацию по zip-файлу быстрой и простой.
Для получения более подробной информации о формате zip-файла см. [ZIP].
17.3 Шифрование
правитьПроцесс шифрования состоит из нескольких стадий.
- Создание 20-байтового SHA1 результирующего дайджеста пароля, введенного пользователем, и его передача компоненту пакета.
- Компонент пакета инициализирует генератор случайных чисел с текущим временем.
- Генератор случайных чисел используется, чтобы генерировать случайный 8-байтовый вектор инициализации и 16-байтовый шум для каждого файла.
- Шум используется вместе с 20-байтовым SHA1 результирующим дайджестом пароля для получения уникального для каждого файла 128-битного ключа. Алгоритмом получения ключа является алгоритм PBKDF2, использующий HMAC-SHA-1 (см. [RFC2898]) с количеством итераций, равным 1024.
- Полученный ключ используется вместе с вектором инициализации для шифрования файла, с использованием алгоритма Blowfish в режиме CFB (cipher-feedback).
Каждый зашифрованный файл сжимается перед шифрованием. Для разрешения проверки содержимого файла пакета необходимо, чтобы зашифрованные файлы были помечены как 'STORED', а не 'DEFLATED'. Так как элементы, помеченные как 'STORED', должны иметь размер, равный сжатому размеру, необходимо хранить их несжатый размер в декларации. Сжатый размер сохраняется как в локальном заголовке файла, так и в записи центрального каталога zip-файла.
17.4 Поток типа MIME
правитьЕсли для документа, который использует пакеты, существует тип MIME, то в пакете следует размещать поток, названный «mimetype». Этот поток следует размещать первым потоком zip-файла пакета, он не должен быть сжатым и не должен использовать дополнительную область в своем заголовке (см. [ZIP]).
Цель состоит в том, чтобы позволить упакованным файлам быть идентифицированными через механизм «магических чисел», похожий на Unix-утилиту file/magic. Если zip-файл в начале содержит поток, который распакован, и не имеет никаких дополнительных данных в заголовке, то имя потока и его содержимое можно найти в фиксированных позициях. Более подробно:
- строка 'PK' в нулевой позиции всех zip-файлов;
- строка 'mimetype' в 30-ой позиции всех таких файлов пакета;
- тип MIME непосредственно в 38-й позиции такого пакета.
17.5 Использование унифицированных идентификаторов ресурса (IRI) в пакетах
правитьОтносительные унифицированные идентификаторы ресурса (IRI) используются в пределах файла, содержащегося в пакете, чтобы сослаться на другие файлы пакета, но могут также применяться для обращения к файлам в пределах файловой системы.
Для IRI, которые используются в пределах пакета, существуют следующие ограничения:
- можно сослаться только на файлы в пределах того же самого пакета;
- IRI, которые ссылаются на файл пакета, должны быть относительными и не должны содержать пути, которые находятся за пределами пакета, это означает, что не должно быть ссылок на файлы пакета с абсолютными IRI;
- на файл пакета нельзя ссылаться снаружи пакета, например из файловой системы или из другого пакета.
Ссылка относительного пути (как описано в § 6.5 [RFC3987]), которая встречается в файле из пакета, должна быть разрешена точно так же, как если бы целый пакет был бы разархивирован в каталог с текущим местоположением. Чтобы получить (разархивированный) файл, который содержит ссылку относительного пути, должны использоваться базовые IRI для разрешения ссылок относительного пути.
Все другие типы ссылок IRI, а именно, начинающиеся с протокола (например http
:), разделителя (т. е. //) или абсолютного пути (т. е. /) не нуждаются в какой-либо специальной обработке. Это означает, что абсолютные пути не являются ссылками файлов внутри пакета, а содержатся в пределах иерархии, в которой находится пакет, например файловая система. Ссылки IRI в пакете могут выходить за пределы пакета, но как только они вышли за пределы пакета, они никогда не смогут вернуться в него или в другой пакет.
17.6 Изображение предварительного просмотра
правитьПо умолчанию, когда файл сохраняется, должно быть сформировано изображение эскиза документа. Оно должно отображать первую страницу документа, первый лист, и т. д. Для обеспечения возможности всестороннего использования эскизов они должны быть сформированы без каких-либо эффектов, окружающих рамок, или обрамления. Такие эффекты могут наложиться на эффекты, добавленные к эскизам различными проводниками файловой системы или, в некоторых случаях, вообще могут быть не желательны для использования.
Эскиз должен быть сохранен как «thumbnail.png» в отдельной папке по имени «Thumbnails».
Папка «Thumbnails» не должна получить медиа-тип в файле manifest.xml, так как она, фактически, не является частью документа.
Зашифрованные файлы предназначены для того, чтобы неавторизованные пользователи не смогли их прочесть, именно поэтому эскиз для таких файлов не генерируется. Вместо того чтобы сохранять эскиз первой страницы, для зашифрованного файла сохраняется отображение, которое не зависит от содержания документа и делает очевидным тот факт, что соответствующий файл зашифрован.
Чтобы соответствовать стандарту управления эскизами (TMS) на www.freedesktop.org, эскизы должны быть сохранены как 24-битное построчное изображение PNG с полной альфа-прозрачностью. Необходимый для эскизов размер — 128x128 пикселей.
17.7 Файл декларации
правитьЭлементы и атрибуты в файле декларации находятся в пространстве имен: urn:oasis:names:tc:opendocument:xmlns:manifest:1.0
.
17.7.1 Схема Relax-NG
правитьВ данной спецификации представлена нормативная XML-схема для файлов декларации OpenDocument. Она может быть получена из данного документа спецификации связыванием всех фрагментов схемы, содержащихся в этих разделах. Все фрагменты схемы имеют нумерацию строк и серый цвет фона.
Язык схемы, используемый в пределах этой спецификации, — Relax-NG (см. [RNG]).
Префикс для нормативной схемы Relax-NG декларации: