Opera File Formats(私家訳)

はじめに

この文書は，Opera5 でキャッシュやクッキーの管理に使われている新しいバイナリ形式のファイルフォーマットについて記述する．

新しいファイルフォーマットは，連続するタグ付きのレコードで構成される．それぞれのレコードは数値や文字列や任意のバイナリデータといったいくつかの種類のデータを保持する．

このファイルフォーマットは Opera3.x 以前のものと互換性がないが，Opera4以降のものとは適度な互換性を持つことを目的として作られている．つまり，将来のバージョンで何か新しい項目がファイルフォーマットに追加された場合においても，古いバージョンのOperaは理解できるところだけを理解しながら，将来のバージョンのファイルを読めるということである．

主にレコードの長さを表す整数値の上位ビットに関して，いくつか制限がある．現在，このフォーマットは，ディスクキャッシュのインデックスファイル ( dcache4.url )，訪問済みリンクのファイル( vlink4.dat )，ダウンロードレスキューファイル ( download.dat )および，クッキー管理ファイル ( cookies4.dat) に用いられている．このファイルフォーマットについて次のように説明していく．

• 新しいフォーマットでの共通バイナリフォーマットについて
• キャッシュ，訪問済みリンク，ダウンロードレスキューファイルで用いられる値やデータ構造について
• クッキーの管理ファイルで用いられる値や構造について

ウィンドウの履歴，ニュースの購読ファイル，履歴管理ファイルは Opera3 での形式と同じなのでこの文書の範囲外である．

共通データフォーマット

struct record
{
// アプリケーション毎に異なる，レコードの中身を表すタグ
tag_id_type tag_id;
// ペイロードの長さ
payload_length_type length;
// レコードの本体
bytepayload[length];
};

ファイルのフォーマット

レコードの形を取らずに直接格納されるものもある

uint32 file_version_number;
uint32 app_version_number;
// id tag のバイト長, 現在は 1
uint16 idtag_length;
// レコードの lenght のバイト長, 現在は 2
uint16 length_length;
// record の配列, 配列の大きさはファイル長から計算される．
struct record items[]; 

現在のファイルフォーマットのバージョン(file_version_number)は 0x00001000である．このうち下位12ビット (0x00000fff) はマイナーバージョンを表し，残りのビットがメジャーバージョンを表す．古いバージョンのソフトで正常に読み込めなくなるほどのフォーマットの変更をしたときにはマイナーバージョンの変更をしてはいけない．また，ソフトウェアは対応できないメジャーバージョンのファイルを読んではいけない．

ファイルフォーマットのすべてののバージョンにおいて，整数値のサイズはメジャーバージョンに対して固定である．

app_version_number はファイルバージョンとは独立に，アプリケーションごとに決められた値である．個々のアプリケーションにおいて互換性を維持するために使われるかもしれないが，この文書の範囲外である．アプリケーションバージョンの値の解釈はそれぞれのアプリに依存する．

“idtag_length” は レコードのタグを表す tag_id が何バイトの値かを規定する． “length_length” は レコードのペイロードの長さを表す payload_length_type が何バイトの値かを規定する．

tag_id_type と payload_length_type の値と それぞれの規定する型は以下のとおりである．

バイナリのファイルを処理するソフトウェアでの内部表現の型を定義しないが uint32 を用いることをお勧めする．idtag_length や length_length が 4 以上のときや，その処理系で扱えるサイズ以上のとき，どう扱うべきかは定義しない．しかし，上位互換性のためのルールに則って実装すべきである．

Opera 4.x では idtag_length=1 (tag_id_type = uint8) and length_length=2 (payload_length_type=uint16)としている．

ヘッダのあとには レコード だけが続く．レコードの構成や値の意味づけはそれぞれのファイルによる．

上位互換性

long int を扱えないような古いタイプのソフトウェアでは，タグの値がオーバーフローを起こすようなときには回避しつつファイルの処理を試みるべきである．しかしながら， レコードの長さが扱える長さを超えているのならば，処理を続けてはならない．

すべてのソフトウェアは，理解できない tag の値を無視するべきである．

キャッシュファイルなどのフォーマット

本節では 訪問済みリンクのファイル( vlink4.dat )，キャッシュのインデックスファイル( dcache4.dat )，およびダウンロードレスキューファイル( download.dat )における レコードの tag や 形式について詳述する．これらのファイルに対する app_version_number は 0x0002 0000である．メジャーが 2,マイナーが 0ということである．

これらのファイルは，同一のタグ集合のタグのついたレコードのシーケンスを含むレコードを使う．それぞれのファイルがファイルごとに使うタグの値は以下の表のとおり． ( These files use records (of different tag values) which contain a sequence of records with tags from the same set of tag ids. The different files use these tags for their records:

それぞれのファイルはここに定義したタグのみを使うが，キャッシュのインデックスのファイルは例外で 0x40という値のタグも使う．そのタグのついたレコードには 次に使えるキャッシュファイルの5文字( oprXXXXX の XXXXX 部分 )が入っている．

(Each record is again a sequence of records with the same binary representation format as the records in the file.)

クッキー管理ファイルのフォーマット

本節ではクッキー管理ファイル (cookies4.dat)ににおける レコードの tag や 形式について詳述する．このファイルに対する app_version_number は 0x0002 0000である．メジャーが 2,マイナーが 0ということである．

クッキー管理ファイルはドメイン名によるノードの木構造から成る．それぞれのドメイン名のノードは，path のノードの木構造を持つ．そして，それぞれの pathのノードはクッキーをいくつか持つ．

NOTE: ノードは連続するレコードの形で表される．終端にはflag レコードがある．ひとつのレコードにすべてがぶら下がっているわけではない．

[“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”)]