Форматы файлов Opera

Этот документ описывает новые двоичные форматы файлов, впервые представленные в Opera версии 5, для различных файлов, используемых в управлении кэшем и cookie.

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

Родовой формат обратно НЕ совместим с Opera 3.x и более ранними, но предназначен быть приемлимо совместимым для версии 4.0 и более поздних. Это означает, что, если новые поля будут добавлены более новой версией, старые версии все еще будут в состоянии читать информацию, которую они понимают, игнорируя те поля, которые они не понимают.

Есть некоторые ограничения, но они главным образом они касаются числа старших битов в целых числах, которые используются для индикации длин записи. Форматы теперь используются для сохранения индексного файла кэша (dcache4.url), файла посещенных ссылок (vlink4.dat), файла сохраненных загрузок (download.dat) и файла cookie (cookies4.dat). Форматы описанный в следующей последовательности:

• Generic binary format используется в новых форматах.
• Специальные константы и организация данных используется в форматах файлов кэша, посещенных ссылок и загрузок.
• Специальные константы и организация данных используется в формате cookie.

Форматы для истории окон, новых файлов и файлов общей истории такие же как и уже используемые Opera v3.x и их описание находится вне контекста этого документа.

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

В этом документе используются следующие типы данных:

Общий формат записи имеет такую форму:

struct record
{
// Определенный приложением тэг для идентификации типа содержимого
tag_id_type tag_id;
// длинна payload
payload_length_type length;
// Payload/содержимое записи
bytepayload[length];
};
 

Предупреждение: Число байтов в тэге и длине может измениться, см. ниже.

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

Идентификатор записи. Это значение определяется приложением и может использоваться для индикации значимости полезного содержимого.

Актуальный тип содержимого записи зависит от определений, используемых для актуального файла или супер-записи.

Значения ‘tag_id’, в которых MSB установлен в 1, зарезервированны для записей с неявной длинной. Поле ‘tag_id’ НЕ следует ни за полем ‘length’, ни за буфером ‘payload’. Такие записи используются как ‘Boolean’-флаги: Истинно — если присутствуют, Ложь — если отсутствуют.

В двоичной памяти файла это означает, что MSB целого числа внутренней памяти должен быть сохранен как MSB первого байта в поле тэга. Это помещает ограничение в том, сколько тэгов может использоваться для длинны целого числа данного ‘tag_id’. Когда файл читается в программу, программа должна заботиться о том, чтобы переместить MSB сохраненного в двоичном виде тэга к общей (внутренней) позиции двоичного разряда, такой как MSB собственных целых чисел без знака программы.

Если это технически возможно использовать те же самые id-тэгов (без MSB) для нормальной записи и запись флага (такую как 0×0001 [16-битный тэг] для записи ‘payload’ и ‘0×8001’ для записи флага), это не поощряется.

Это поле является числом байтов в ‘payload’ которое следует непосредственно после поля. Оно может быть нулевым.

Payload — последовательность байтов длины, индицируемое полем ‘length’.

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

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

Одиночные целые числа (подписанные или без знака) могут быть усечены (удаленные нулевые байты), но массивы целых чисел должны всегда использовать фиксированное число байтов, чтобы представить значения и получить число элементов от ‘payload length’. Если число байтов должно было представить изменения значений в будущей версии, должен использоваться новый тэг.

Эти элементы сохраняются не как записи, а непосредственно в двоичном виде:

uint32 file_version_number;
uint32 app_version_number;
// число битов в id тэге, теперь 1
uint16 idtag_length;   
// число байтов в части длины записи, теперь 2
uint16 length_length;  
// массив записей, количество определяется длинной файла
struct record items[]; 

Текущий номер версии формата файла (file_version_number) — 0×00001000, где младшие 12 битов (bitmask 0x00000fff) представляют младший номер версии, остальные — главный номер версии. Изменения в главном номере версии не могут быть использованы если формат файла изменится таким образом, что старые версии программного обеспечения не смогут нормально прочитать файл. Если главный номер версии новее (или старее) чем тот, который приложение может читать, оно не сможет прочитать файл.

Размеры целых чисел абсолютны для данной главной версии, а размер целого числа для номера версии файла зафиксирован в любой версии.

‘app_version_number’ — номер версии приложения и независим от ‘file_version_number’. Он может быть использован приложением для определения необходимых действия, которые нужны для обеспечения прямой или обратной совместимость, которая находится вне диапазона форматов файла. Интерпретация номера версии приложения — определяется приложением.

Поля ‘idtag_length’ и ‘length_length’ дают количество байт, использованных в записи для “id”-тэгов, как определено полем ‘tag_id_type’, а поля ‘payload length’ — как определено полем ‘payload_length_type’, соответственно.

Подробнее, значения этих полей определяют ‘tag_id_type’ и ‘payload_length_type’ как следующие типы целых чисел:

Внутреннее представление приложением этих форматов не определено, но рекомендуется — uint32. Как приложение будет обрабатывать значения ‘idtag_length’ или ‘length_length’ больше 4, или значения, большие чем его внутренний unsigned integer размер, не определено, но приложение должно применить правила, определенные для таких ситуаций в руководстве по прямой совместимости.

Настоящая версия Opera 4.x использует idtag_length=1 (uint8) и length_length=2 (uint16).

После заголовка следуют только записи. Организация записей и их интерпретация определяется приложением.

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

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

Этот раздел описывает тэги и форматы записей, используемых для файлов посещенных ссылок (vlink4.dat), индексных файлов дискового кэша (dcache4.url) и файлов сохраненных загрузок (download.dat). Настоящий ‘app_version_number’ таких файлов — 0×00020000 (старшая версия 2, младшая 0).

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

Каждый файл состоит из записей ТОЛЬКО этих типов, за исключением индексного файла дискового кэша кроме них содержащий еще одну запись с id 0×40, которая содержит 5 строк символов, используемых для поиска следующего свободного номера файла кэша (oprXXXXX).

Каждая запись снова является последовательностью записей в том же самом формате в двоичном представлении как и записи в файле.

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

Предупреждение: “(0×0001 | MSB_VALUE)” означает, что старший значащий бит в локальном целом числе без знака должен быть установлен. Если используется 32-битное значение, то это означает, что значение тэга — 0×80000001.

Все методы по умолчанию являются GET, в настоящее время невозможно кэшировать POST-запросы.

Этот раздел описывает тэги и форматы записей, используемых для сохранения cookies (cookies4.dat). Настоящее значение ‘app_version_number’ этих типов файлов — 0×00002000 (старшая версия — 2, младшая — 0).

Файлы cookie организуются в виде древа компонентов доменных имен, каждый компонент тогда хранит дерево компонентов пути, и каждый компонент пути может содержать множество cookies.

Предупреждение: Компоненты — последовательность записей, заканчивающаяся записью флажка, не одиночная запись.

Компоненты домена используются для организации cookies для каждого сервера и домена, для которых cookies или возможность фильтрации cookie определены.

Компоненты домена начинаются с записи домена (domain record), которая содержит имя домена (domain name) и некоторые флаги для этого специфичного домена. Затем следуют компоненты пути (path component) хранения cookies и компоненты пути (path component) к поддиректории (и cookies), следуют прерыватель компонента пути ([Path component terminator]) и некоторое количество компонентов поддомена ([other domains]) пока они не будут прерваны записью флага окончания домена (end of domain flag)

Например: cookies для домена www.opera.com will будут сохранены в виде:

["com" record]
  ["opera" record]
["www" record
  [cookies]
  [Path components]
  [Path component terminator]
  [other domains]
[end of domain flag ("www")]
  [end of domain flag ("opera")]
[end of domain flag ("com")]

Все имена компонентов домена приводятся без точек, кроме IP-адресов, которые могут быть сохранены только с полным IP-адресом как взятый в кавычки параметр, например “10.11.12.13”, сохраняются на верхнем уровне и не могут содержать другие поддомены.

Запись домена (Domain Record) использует тэг “0×01“ и содержит последовательность этих полей:

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

Компонент домена заканчивается записью флага (0×0004 | MSB_VALUE).

Компоненты пути организуют cookies определенные для данной директории в данном домене, также любые поддиректории этй директории, для которых определены cookies.

Кроме компонентов пути, начинающихся непосредственно после записи компонента домена, эти компоненты пути всегда начинается с записи пути (path record) и затем продолжается тем же самым количеством записей cookie и компонентов пути к поддиректории.

Запись пути (path record) использует id записи “0×0002“ и запись имеет такую запись поля:

Компонент пути заканчивается записью флага (0×0005 | MSB_VALUE).

Значения cookie сохраняются в записях типа “0×0003” и имеют следующие записи полей:

Оригинал статьи: Opera File Formats

Copyright Opera Software ASA. Все права зарезервированы

OperaFan.net, 2007. Ermir, неофициальный перевод.