Spec-Zone .ru спецификации, руководства, описания, API

Содержание документации

Спецификация Файла JAR

Содержание

• Введение
•  Каталог META-INF
• Пары значение-имя и Разделы
• Декларация JAR
  • Краткий обзор
  • Явная Спецификация
  • Основные Атрибуты
  • Атрибуты на запись
• Файл JAR со знаком
  • Краткий обзор
  • Файл подписи
    • Проверка допустимости подписи
    • Волшебный Атрибут
  • Цифровые подписи
• Примечания по Файлам Декларации и Подписи
• Индекс JAR
  • Краткий обзор
  • Спецификация Индексного файла
  • Обратная совместимость
• Поставщик услуг
  • Краткий обзор
  • Конфигурационный файл провайдера
  • Пример
•  Детали API
• См. Также

Введение

Во многих случаях файлы JAR не являются только простыми архивами файлов классов java и/или ресурсов. Они используются в качестве стандартных блоков для приложений и расширений. Каталог META-INF, если это существует, используется, чтобы сохранить пакет и данные конфигурации расширения, включая безопасность, управление версиями, расширение и службы.

Каталог META-INF

• MANIFEST.MF

• INDEX.LIST

• x.SF

• x.DSA

• services/

Пары значение-имя и Разделы

Группы пар значение-имя известны как "раздел". Разделы разделяются от других разделов пустыми строками.

Двоичные данные любой формы представляются как base64. Продолжения требуются для двоичных данных, который заставляет длину строки превышать 72 байта. Примерами двоичных данных являются обзоры и подписи.

Реализации должны поддерживать значения заголовка до 65535 байтов.

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

Спецификация:

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

На нетерминальные символы, определенные в вышеупомянутой спецификации, сошлются в следующих спецификациях.

Декларация JAR

Краткий обзор

Основной раздел содержит безопасность и конфигурационную информацию о файле JAR непосредственно, так же как приложение или расширение, из которого этот файл JAR является частью. Это также определяет основные атрибуты, которые применяются к каждой отдельной явной записи. Ни у какого атрибута в этом разделе не может быть своего имени, равного "Name". Этот раздел завершается пустой строкой.

Отдельные разделы определяют различные атрибуты для пакетов или файлов, содержавшихся в этом файле JAR. Не все файлы в файле JAR должны быть перечислены в декларации как записи, но все файлы, которые должны быть подписаны, должны быть перечислены. Сам файл манифеста не должен быть перечислен. Каждый раздел должен запуститься с атрибута с именем как "Name", и значение должно быть относительным путем к файлу, или абсолютным URL, ссылающимся на данные вне архива.

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

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

Явная Спецификация:

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

Основные Атрибуты

• общие основные атрибуты
  • Явная версия: Определяет версию файла манифеста. Значение является законным номером версии, как описано в вышеупомянутой спецификации.
  • Создаваемый-: Определяет версию и поставщика реализации java, сверху которой сгенерирован этот файл манифеста. Этот атрибут сгенерирован инструментом jar.
  • Версия подписи: Определяет версию подписи файла фляги. Значение должно быть допустимой строкой номера версии.
  • Путь к классу: значение этого атрибута определяет относительные URL расширений или библиотек, в которых нуждаются это приложение или расширение. URL разделяются одними или более пробелами. Загрузчик класса приложения или расширения использует значение этого атрибута, чтобы создать его внутренний путь поиска.
• атрибут определил для автономных приложений: Этот атрибут используется автономными приложениями, которые связываются в исполнимые файлы фляги, которые могут быть вызваны средой выполнения Java непосредственно, выполняя "java -jar x.jar".
  • Основной класс: значение этого атрибута определяет относительный путь основного класса приложений, который средство запуска загрузит во время запуска. Значению нельзя было добавить расширение .class к имени класса.
• атрибуты определили для апплетов: Эти атрибуты используются апплетом, который связывается в файлы JAR, чтобы определить требования, версию и информацию о расположении для расширений, от которых зависит этот апплет. (см. Управление версиями Расширения).
  • Список расширения: Этот атрибут указывает на расширения, которые необходимы апплету. У каждого расширения, перечисленного в этом атрибуте, будет ряд дополнительных атрибутов, что использование апплета, чтобы определить, какой версии и поставщика расширения это требует.
  • <расширение> - Имя расширения: Этот атрибут является уникальным именем расширения. Плагин Java сравнит значение этого атрибута с атрибутом Имени расширения в декларациях установленных расширений, чтобы определить, устанавливается ли расширение.
  • <расширение> - Версия спецификации: Этот атрибут определяет минимальную версию спецификации расширения, которая требуется апплетом. Плагин Java сравнит значение этого атрибута с атрибутом Версии спецификации установленного расширения, чтобы определить, современно ли расширение.
  • <расширение> - Версия реализации: Этот attritute определяет минимальный номер версии реализации расширения, который требуется апплетом. Плагин Java сравнит значение этого атрибута с атрибутом Версии реализации установленного расширения, чтобы видеть, должна ли более свежая реализация быть загружена.
  • <расширение> - Идентификатор поставщика реализации: Этот атрибут может использоваться, чтобы идентифицировать поставщика реализации расширения, если апплет требует реализации от определенного поставщика. Плагин Java сравнит значение этого атрибута с атрибутом Идентификатора поставщика реализации установленного расширения.
  • <расширение> - URL реализации: Этот атрибут определяет URL, который может использоваться, чтобы получить новую версию расширения, если необходимая версия уже не устанавливается.
• атрибут определил для идентификации расширения: Этот атрибут используется расширениями, чтобы определить их уникальные идентификационные данные.
  • Имя расширения: Этот атрибут определяет имя для расширения, содержавшегося в файле Фляги. Имя должно быть уникальным идентификатором, таким как имя основного пакета, включающего расширение.
• атрибуты, определенные для расширения и  информации об управлении версиями и изоляции пакета: Эти атрибуты определяют функции расширения, из которого файл JAR является частью. Значение этих атрибутов применяется ко всем пакетам в файле JAR, но может быть переопределено атрибутами на запись.
  • Заголовок реализации: значение является строкой, которая определяет заголовок реализации расширения.
  • Версия реализации: значение является строкой, которая определяет версию реализации расширения.
  • Поставщик реализации: значение является строкой, которая определяет организацию, которая поддерживает реализацию расширения.
  • Идентификатор поставщика реализации: значение является строковым идентификатором, который уникально определяет организацию, которая поддерживает реализацию расширения.
  • URL реализации: Этот атрибут определяет URL, от которого реализация расширения может быть загружена с.
  • Заголовок спецификации: значение является строкой, которая определяет заголовок спецификации расширения.
  • Версия спецификации: значение является строкой, которая определяет версию спецификации расширения.
  • Поставщик спецификации: значение является строкой, которая определяет организацию, которая поддерживает спецификацию расширения.
  • Изолированный: Этот атрибут определяет, изолируется ли этот файл JAR или нет. Значение может быть или "истиной" или "ложью", регистр игнорируется. Если это устанавливается в "истину", то все пакеты в файле JAR принимаются значение по умолчанию, чтобы быть изолированными, если они не определяются иначе индивидуально.

Атрибуты на запись

Manifest-Version: 1.0
Created-By: 1.2 (Sun Microsystems Inc.)
Sealed: true
Name: foo/bar/
Sealed: false

Это означает, что все пакеты, заархивированные в a.jar, изолируются, за исключением того, что пакет foo.bar не.

Атрибуты на запись попадают в следующие группы:

• атрибуты определили для содержания файла:
  • Тип контента: Этот атрибут может использоваться, чтобы определить тип MIME и подтип данных для определенной записи файла в файле JAR. Значение должно быть строкой в форме типа/подтипа. Например "image/bmp" является типом изображения с подтипом bmp (представляющий битовый массив). Это указало бы на запись файла как на изображение с данными, хранившими как битовый массив. RFC 1521 и 1522 обсуждает и определяет определение типов MIME.
• атрибуты, определенные для информации об управлении версиями и изоляции пакета: Они - тот же самый набор атрибутов, определенных выше как основные атрибуты, который определяет информацию об управлении версиями и изоляции пакета расширения. Когда использующийся атрибуты согласно записи, эти атрибуты перезаписывают основные атрибуты, но только применитесь к отдельному файлу, определенному явной записью.
• атрибут определил для бобовых объектов:
  • Боб Java: Определяет, является ли определенная запись файла фляги Бобовым объектом Java или нет. Значение должно быть или "истиной" или "ложью", регистр игнорируется.
• атрибуты определили для того, чтобы подписаться: Эти атрибуты используются для подписания и проверки целей. Больше деталей здесь.
  • x-Digest-y: имя этого атрибута определяет имя алгоритма обзора, используемого, чтобы вычислить значение обзора для соответствующей записи файла фляги. Значение этого атрибута хранит фактическое значение обзора. Префикс 'x' определяет имя алгоритма, и дополнительный суффикс 'y' указывает, к которому языку значение обзора должно быть проверено против.
  • Волшебство: Это - дополнительный атрибут, который может использоваться приложениями, чтобы указать, как верификатор должен вычислить значение обзора, содержавшееся в явной записи. Значение этого атрибута является рядом запятой разделенные зависящие от контекста строки. Подробное описание здесь.

Файл JAR со знаком

Краткий обзор

• META-INF/MANIFEST.MF
• META-INF/*.SF
• META-INF/*.DSA
• META-INF/*.RSA
• META-INF/SIG-*

Подмножества файла JAR могут быть подписаны при использовании java.security API. Файл JAR со знаком является точно тем же самым как исходным файлом JAR, за исключением того, что его декларация обновляется, и два дополнительных файла добавляются к META-INF каталог: файл подписи и файл сигнатурного блока. Когда jarsigner не используется, программа подписания должна создать и файл подписи и файл сигнатурного блока.

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

Файл подписи

• x-Digest-Manifest-Main-Attributes (где x является стандартным именем a java.security.MessageDigest алгоритм): значение этого атрибута является значением обзора основных атрибутов декларации.
• x-Digest-Manifest (где x является стандартным именем a java.security.MessageDigest алгоритм): значение этого атрибута является значением обзора всей декларации.

Пути или URL, появляющиеся в файле манифеста, но не в файле подписи, не используются в вычислении.

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

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

2. Если x-Digest-Manifest атрибут существует в файле подписи, проверьте значение против обзора, вычисленного по всей декларации. Если больше чем один x-Digest-Manifest атрибут существует в файле подписи, проверьте, что по крайней мере один из них соответствует расчетное значение обзора.

3. Если x-Digest-Manifest атрибут не существует в файле подписи или ни одном из значений обзора, вычисленных в предыдущем соответствии шага, затем менее оптимизированная проверка выполняется:

   1. Если x-Digest-Manifest-Main-Attributes запись существует в файле подписи, проверьте значение против обзора, вычисленного по основным атрибутам в файле манифеста. Если это вычисление перестало работать, то проверка файла JAR перестала работать. Это решение можно помнить для эффективности. Если x-Digest-Manifest-Main-Attributes запись не существует в файле подписи, его небытие не влияет на проверку файла JAR, и явные основные атрибуты не проверяются.

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

   Одна причина значение обзора файла манифеста, который сохранен в x-Digest-Manifest атрибут, возможно, не равняется значению обзора текущего файла манифеста, то, что один или более файлов были добавлены к файлу JAR (использующий инструмент фляги) после того, как подпись (и таким образом файл подписи) была сгенерирована. Когда инструмент фляги используется, чтобы добавить файлы, файл манифеста изменяется (разделы добавляются к этому для новых файлов), но файл подписи не. Проверку все еще считают успешной, если ни один из файлов, которые были в файле JAR, когда подпись была сгенерирована, не был изменен с тех пор, который имеет место, равняются ли значения обзора в разделах незаголовка файла подписи значениям обзора соответствующих разделов в файле манифеста.

4. Для каждой записи в декларации проверьте значение обзора в файле манифеста против обзора, вычисленного по фактическим данным, на которые ссылаются на "Имя:" атрибут, который определяет или путь файла прямого доступа или URL. Если какое-либо из значений обзора не соответствует, то проверка файла JAR перестала работать.

Файл манифеста в качестве примера:

Manifest-Version: 1.0
Created-By: 1.7.0 (Sun Microsystems Inc.)

Name: common/class1.class
SHA-256-Digest: (base64 representation of SHA-256 digest)

Name: common/class2.class
SHA1-Digest: (base64 representation of SHA1 digest)
SHA-256-Digest: (base64 representation of SHA-256 digest)

Signature-Version: 1.0
SHA-256-Digest-Manifest: (base64 representation of SHA-256 digest)
SHA-256-Digest-Manifest-Main-Attributes: (base64 representation of SHA-256 digest)

Name: common/class1.class
SHA-256-Digest: (base64 representation of SHA-256 digest)

Name: common/class2.class
SHA-256-Digest: (base64 representation of SHA-256 digest)

Волшебный Атрибут

Волшебный атрибут является дополнительным, но требуется, что синтаксический анализатор понимает значение ключа Magic записи, если это проверяет что подпись записи.

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

Вот два примера потенциального использования Волшебного атрибута в файле манифеста:

        Name: http://www.example-scripts.com/index#script1
        SHA-256-Digest: (base64 representation of SHA-256 hash)
        Magic: JavaScript, Dynamic

        Name: http://www.example-tourist.com/guide.html
        SHA-256-Digest: (base64 representation of SHA-256 hash)
        SHA-256-Digest-French: (base64 representation of SHA-256 hash)
        SHA-256-Digest-German: (base64 representation of SHA-256 hash)
        Magic: Multilingual

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

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

Цифровые подписи

У файлов цифровой подписи есть те же самые имена файлов как.SF файлы, но различные расширения. Расширение изменяется в зависимости от типа цифровой подписи.

• .RSA (Подпись PKCS7, SHA 256 + RSA)
• .DSA (Подпись PKCS7, DSA)

Для тех форматов, которые не поддерживают внешние данные со знаком, файл должен состоять из копии со знаком .SF файл. Таким образом некоторые данные могут быть дублированы, и верификатор должен сравнить эти два файла.

Форматы, которые поддерживают внешние данные любая ссылка .SF файл, или выполняют вычисления на этом с неявной ссылкой.

Каждый .SF у файла могут быть многократные цифровые подписи, но те подписи должны быть сгенерированы тем же самым юридическим лицом.

Расширения файла могут быть 1 - 3 alphanum символами. Игнорируются нераспознанные расширения.

Примечания по Файлам Декларации и Подписи

• Перед парсингом:
  • Если последний знак файла является символом EOF (кодируйте 26), EOF обрабатывается как пробел. Две новых строки добавляются (один для редакторов, которые не помещают новую строку в конце последней строки, и тот так, чтобы у грамматики не было к особому случаю последней записи, у которой, возможно, нет пустой строки после этого).
• Атрибуты:
  • Во всех случаях для всех разделов игнорируются атрибуты, которые не понимаются.
  • Названия атрибута являются нечувствительными к регистру. Программы, которые генерируют декларацию и файлы подписи, должны использовать случаи, показанные в этой спецификации как бы то ни было.
  • Названия атрибута не могут быть повторены в пределах раздела.
• Версии:
  • Явная версия и Версия подписи должны быть первыми, и в точно, что случай (так, чтобы они могли быть распознаны легко как волшебство, представляет в виде строки). Кроме этого, порядок атрибутов в пределах основного раздела не является существенным.
• Упорядочивание:
  • Порядок отдельных явных записей не является существенным.
  • Порядок отдельных записей подписи не является существенным, за исключением того, что обзоры, которые подписываются, находятся в том порядке.
• Длина строки:
  • Никакая строка не может быть более длинной чем 72 байта (не символы) в ее UTF8-закодированной форме. Если значение сделало бы начальную строку дольше чем это, это должно продолжаться на дополнительных строках (каждый запуск с одиночного пробела).
• Ошибки:
  • Если файл не может быть проанализирован согласно этой спецификации, предупреждение должно быть выведено, и ни одной из подписей нельзя доверять.
• Ограничения:
  • Поскольку имена заголовка не могут продолжаться, максимальная длина имени заголовка составляет 70 байтов (должно быть двоеточие и ПРОСТРАНСТВО после имени).
  • NUL, CR, и LF не могут быть встроены в значения заголовка, и NUL, CR, LF и ":" не может быть встроен в имена заголовка.
  • Реализации должны поддерживать 65535 байтов (не символ) значения заголовка, и 65535 заголовков на файл. Они могли бы исчерпать память, но там не должны быть трудно кодированы пределы ниже этих значений.
• Подписывающие лица:
  • Технически возможно, что различные объекты могут использовать различные алгоритмы подписания, чтобы совместно использовать единственный файл подписи. Это нарушает стандарт, и дополнительная подпись может быть проигнорирована.
• Алгоритмы:
  • Никакой алгоритм обзора или алгоритм подписи не получают мандат по этому стандарту. Однако, по крайней мере один из MD5 и алгоритма обзора SHA1 должен поддерживаться.

Индекс JAR

Краткий обзор

Существующий инструмент jar улучшается, чтобы быть в состоянии исследовать список файлов фляги и генерировать информацию о каталоге, относительно которой классы и ресурсы находятся в который файл фляги. Эта информация каталога хранится в простом текстовом файле под названием INDEX.LIST в каталоге META-INF корневого файла фляги. Когда classloader загружает корневой файл фляги, он читает файл INDEX.LIST и использует это, чтобы создать хэш-таблицу из отображений от файла и имен пакета к спискам имен файлов фляги. Чтобы найти класс или ресурс, загрузчик класса запрашивает хеш-таблицу, чтобы найти надлежащий файл фляги и затем загружает это в случае необходимости.

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

Чтобы предотвратить добавление слишком большого количества издержек пространства к приложению и ускорить конструкцию хэш-таблицы в памяти, файл INDEX.LIST сохраняется как можно меньше. Для классов с ненулевыми именами пакета отображения записываются на уровне пакета. Обычно одно имя пакета отображается на один файл фляги, но если определенный пакет охватит больше чем один файл фляги, то отображенное значение этого пакета будет списком файлов фляги. Для файлов ресурсов с непустыми префиксами каталога отображения также записываются на уровне каталога. Только для классов с нулевым именем пакета, и файлов ресурсов, которые находятся в корневом каталоге, будет отображение быть записанным на отдельном уровне файла.

Спецификация Индексного файла

Кодирование UTF-8 используется, чтобы поддерживать не символы ASCII в файле или имена пакета в индексном файле.
 

Спецификация

Обратная совместимость

Поставщик услуг

Краткий обзор

Файлы в каталоге META-INF/services являются конфигурационными файлами поставщика услуг. Служба является известным набором интерфейсов и (обычно краткий обзор) классы. Поставщик услуг является определенной реализацией службы. Классы в провайдере обычно реализуют интерфейсы и разделяют на подклассы классы, определенные в службе непосредственно. Поставщики услуг могут быть установлены в реализации платформы Java в форме расширений, то есть, файлы фляги, помещенные в любой из обычных каталогов расширения. Провайдеры могут также быть сделаны доступными, добавляя их к апплету или пути класса приложений или некоторыми другими специфичными для платформы средствами.

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

Конфигурационный файл провайдера

Поставщик услуг идентифицирует себя, помещая конфигурационный файл провайдера в каталог META-INF/services ресурса. Имя файла должно состоять из полностью определенного имени класса реферативной службы. Файл должен содержать разделенный от новой строки список уникальных конкретных имен классов провайдера. Пространство и символы вкладки, так же как пустые строки, игнорируются. Символ комментария '#' (0x23); на каждой строке игнорируются все символы после первого символа комментария. Файл должен быть закодирован в UTF-8.

Пример

• public abstract CharEncoder getEncoder(String encodingName);
• public abstract CharDecoder getDecoder(String encodingName);

Каждый метод возвращает соответствующий объект или нуль, если это не может преобразовать данное кодирование. Типичные провайдеры CharCodec будут поддерживать больше чем одно кодирование.

Если sun.io. StandardCodec является провайдером службы CharCodec тогда, ее файл фляги содержал бы файл META-INF/services/java.io.spi.CharCodec. Этот файл содержал бы одну строку:

sun.io.StandardCodec    # Standard codecs for the platform

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

   CharEncoder getEncoder(String encodingName) {
       Iterator ps = Service.providers(CharCodec.class);
       while (ps.hasNext()) {
           CharCodec cc = (CharCodec)ps.next();
           CharEncoder ce = cc.getEncoder(encodingName);
           if (ce != null)
               return ce;
       }
       return null;
   }

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

Детали API

См. Также

---

Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.

Свяжитесь с Нами