{{category 開発情報}} {{category 陰郎の書いた記事,nolink}} !!!はじめに 　このドキュメントは、http://www.pyrite.org/doc_format.html の情報を日本語訳したものです。 　 !日本語訳ここから ---- 　 !!!Docフォーマット 　Doc 形式は Palm Computing Platform における大きなテキストドキュメントのためのデファクトスタンダードです。これはソフトウェアやコンテンツを幅広くサポートしますが、ファイル形式に関する仕様はネット上に散在しています。このページでは、Doc互換のソフトウェアを書こうとしている開発者を教化し、プログラマが互換性のない方法でファイル形式を破らないようにするために、Doc形式についてまとめようと思います。 　このドキュメントはまったくの非公式であり、既存のDocファイルやアプリケーションを調査した結果から作成したものです。 　 !!概要 　Doc形式の電子テキストは、通常の PalmPilot データベースであり、デスクトップ上では標準的な .prc/.pdb 形式のファイルとして表現されます。（これらのファイルフォーマットに関する記述はこのドキュメントの範囲外です。）このデータベースは、以下の順で３つのセクションに分割されます。 *ヘッダーレコード *テキストレコード群 *ブックマークレコード群 　PalmPilot ではそれが通常ですが、すべての値は MSB が先頭に配置されることに注意してください。 ※訳注：MSBってなに？　endian のことを言っている？ 　 !!ヘッダーレコード 　Docデータベースの最初のレコードはヘッダーです。現存するDoc生成プログラムは以下に示す16バイトのヘッダーを作成します；　多くの Doc リーダーは、独自の情報を付加するため、データベースがインストールされたときにこのレコードを拡張します。 ヘッダーフォーマット ,フィールド,サイズ,説明 ,version,2 バイト,圧縮形式ならば 0x0002、非圧縮形式ならば 0x0001。 ,spare,2 バイト,不明（０固定）。 ,length,4 バイト,圧縮前の文書全体のサイズ 。 ,records,2 バイト,レコード数。 ,record_size,2 バイト,レコードの最大サイズ（通常4096）。 ,position,4 バイト,ドキュメント内で現在表示中の位置 ,sizes,レコード数 x 2 バイト,レコードサイズの配列 　position フィールドはどの Docリーダーも使用していません。いくつかのソフトは別の場所にこの情報を保存しています。 　AportisDoc (Reader and Mobile Edition) は、最初にドキュメントを開いた際、spare フィールドに 0x0003 をセットし、length フィールドの先頭２バイトに０をセットしています（ドキュメントが64KByte以上だったとしても！）。 　sizes 配列は、２バイトの符号なし整数の配列で、各レコードの非圧縮状態のサイズを順に格納しています。これはドキュメントを最初に開いたときにいくつかのDocリーダー（AportisDoc, TealDoc, Doc, ひょっとしたら他のも）によって作成されます。　 　 !!テキストレコード群 　ヘッダーレコードに後続するのはテキストレコード群です。それぞれのレコードは、record_size バイトを超えない長さのテキストブロックを表現しています。ほとんどの Doc変換ソフトは 4096バイトのブロックを作成します（最後のレコードを除いて）。Doc形式は他のブロックサイズや異なるレコード長を認めていますが、いくつかのDoc対応ソフトウェアは4096バイト固定のレコードしか処理できません。 　Version 1 のデータベースでは、テキストの各ブロックは単純にレコードに格納されます。Version 2 のデータベースでは、テキストの各ブロックは個別に圧縮され、実際のレコードサイズはいくらか小さくなります。── ただし、ブロックサイズは非圧縮状態のテキストブロックのサイズを示していることに注意してください。 　 !!圧縮アルゴリズム 　付記：Doc圧縮形式のオリジナルデザイナーである Pat Beirne 氏自身によるアルゴリズムの説明が http://cr945328-a.flfrd1.on.wave.home.com/Programming/PilotDoc.htm にあります。アルゴリズムの詳細に興味があるのであれば、チェックしてみてください。 ※訳注：リンク先が存在しませんが、これは原文でも同じです。 　（Version 2 データベースの）それぞれのテキストブロックは simple one-pass アルゴリズムを用いて個別に圧縮されています。私は圧縮アルゴリズムの専門家には程遠いので、単純に圧縮データがどのようになっているかを記述し、より詳細な情報に興味のある方にコード（これは txt2pdbdoc や Pyrite のようにいろいろな場所で簡単に利用することができるものです）を示すだけにしておきます。 　圧縮アルゴリズムの出力は、以下に示すような規則に従って展開可能なバイトストリームになっています。 Compression Byte Codes ,N,action ,0x01-0x09,後続のNバイトをそのままコピーする。 ,0x0a-0x7f,そのままコピーする。 ,0x80-0xbf,ブロック内の前方の部分シーケンスをコピーする。 ,0xc0-0xff,スペースを出力し、続いて N と 0x80 の排他的論理和を出力する。 　copy-sequence のバイトコードが出現すると、そのバイトコードと後続バイトをまとめた２バイト値の先頭バイトとして扱われます（結果として 0x8000-0xbfff の範囲の値となります）。次にその値と 0x3fff との論理積をとり、結果として値は 0x0000 - 0x3fff の範囲の値となります。さらにオフセット（上位11ビットを適切にシフトダウン）と長さ（下位３ビット）に分割されます。実際に出力されるデータは、現在位置からオフセット分減じた位置にあり、出力するバイト数は（下位３ビットが示す）長さに３を足したものになります。 ※訳注：要するに 0x80-0xbf の場合は、それまでに出現したシーケンスを 　　　　繰り返すことで圧縮をはかる．．．ということでしょうか？　だ 　　　　とすると、繰り返すことができるのは 11 ビット値で表現できる 　　　　距離内にある、3 ビットで表現できる長さだけということになり 　　　　ますね。しかも、この繰り返しによる圧縮は同一ブロック内だけ 　　　　ということになります。 　 !!ブックマークレコード群 　テキストレコードに後続するのは、オプションとしてのブックマークレコード群です。それぞれのブックマークが１つのレコードに対応し、通常データベース内に存在する順番でDocリーダーにより表示されます。ブックマークレコードのフォーマットはいくぶんシンプルです： ,フィールド,長さ,説明 ,name,16 バイト,ブックマーク名(15文字のNULL終端文字列） ,position,4 バイト,テキスト先頭からのブックマーク位置 　ブックマークの name フィールドは、ブックマーク名が短かったとしても常に16バイト幅であること、および position が示しているのは圧縮前の実際の位置であることに注意してください。 　 !!共通的な慣例 !ブックマークの Autoscan 　ほとんどの Doc 作成プログラムはブックマークレコードを生成しないため、多くの Doc リーダーはドキュメント内の位置をブックマークするほかの方法をサポートしています。Doc リーダーは初めて開く Doc データをスキャンし、行頭にある特定の文字列を探します。それが見つかるたびに、Doc リーダーはブックマークにその行の内容を追加します。慣例として、検索すべき文字列は < と > で囲んでドキュメントの最後の行に記述します。 　 !TealDoc の独自拡張 　現在の TealDoc の拡張は、テキストドキュメントに HTML のようなタグを埋め込むことで実現されます。TealDoc のタグは HTML に似ていますが、TealDoc のパーザはデスクトップブラウザのそれほど頑強ではありません；　経験上、以下のような制限があることが確認されています。 *タグ、属性値、およびキーワードはすべて大文字で書かれなければなりません。 *それぞれのタグは１行ごとに独立していなければなりません; テキストの行の中程にタグを埋め込もうとすると、予期しない結果を引き起こします。 *テキストの属性値はダブルクォートで括られていなければなりません。キーワードと数値はクォートされていてはいけません。 　 !!その他の拡張 　TealDoc のほかに、他の Doc リーダーも標準的な電子テキストデータベースのフォーマットを拡張しています。これらの拡張のうちのいくつかは、いずれより充実したドキュメントが作成されるでしょう；　ひとまずのところ、このセクションでは将来の開発者が互換性の問題を避けることができるよう、いくつかの注記をしておくにとどめます。ここに書かれていることが公式でも完全でもないということに注意してください。もしあなたが Doc ソフトウェアを開発しているのであれば、これらのこまごまとした事柄については自分で調べてみるべきです。 !QED による拡張 　Visionary 2000 による Doc エディタである QED は、ドキュメント（のデータベースヘッダー）にバージョン番号をマークし、同時に appinfo block を追加します。 ※訳注：Visionary 2000 って何でしょう？　ちなみに、上の文、 　　　　ものすごく訳に自信がありません．．． !RichReader による拡張 　Michael Arena によるリッチテキストドキュメントリーダーである RichReader は、ドキュメントへの書式指定用コントロールコード（フォント指定、インデント、etc.）の埋め込みをサポートします。RichReader ドキュメントを他のリーダーで見ると、いわゆる「ゴミ」を含んでいるように表示されます。これは、多くの書式指定コードが表示できない、または拡張された ASCII 文字を使用しているからです。 !LinkDoc による拡張 　Mobile Generation Software による Mobile LinkDoc というリーダーは、拡張ブックマークを追加することで、ドキュメント間のリンクを保存します。 !Doc フォーマットに影響を与えない拡張 　多くの Doc リーダー(実際にはほとんど全部)は、ドキュメントそのものからは分離され、別のデータベースに保存されます。たとえば、カテゴリ情報は通常外部に保存されます。これらのアプリ独自のデータベースについては ── 現時点では ── Doc フォーマット自体には影響しないため、ここに記述されます。 ---- !日本語訳ここまで 　 !!!注意事項 　このページの内容は、冒頭に示した原文を陰郎が（勝手に）訳したものです。しかし、陰郎は英語が得意なわけではありません。日本語訳の妥当性については、十分なものであると願ってはいますが、ほぼ間違いなくそうでもないでしょう。この訳文はあくまで非公式なもの（原文にも非公式と書いてありますがそれとは別の意味で）なので、厳密な内容については原文に当たってください。誤訳、あるいはよりよい訳文が（部分的にでも）見つかった場合はご指摘いただけると幸いです。 　 !!!コメント *今日、たまたまページ冒頭のリンクをクリックしたところ、リンク先が存在しなくなっていました。見つけたら修正します。 - 陰郎 (2007年08月04日 13時47分34秒) *リンク先が存在しなくなっていた「Pat Beirne 氏自身によるアルゴリズムの説明」ですが、次のページがそれに近いのではないかと思います。→　http://linuxmafia.com/pub/palmos/development/pilotdoc-compression.html - 陰郎 (2008年01月12日 00時10分39秒) {{comment multi}}