PPT形式についてはあまりない
DOCと同様に、PPTはWCBFF形式（構造化バイナリファイル形式）のアドオンです。これについては、前に書いたMS Wordに関する記事で読むことができます。 テスト中に、古いWCBFFとDOCの実装でいくつかのエラー（さらに、テキストを取得しなければならない「壊れた」ファイルが多数見られた）を発見したことに注意してください。
気が散ります。 PowerPointについての話を続けましょう。 DOCとは異なり、以前のように
WordDocument
と
1Table
「ファイル」ではなく、プレゼンテーション固有の
Current User
と
PowerPoint Document
ます。 プレゼンテーションには、CBFファイルの「ファイルシステム」に両方の「ファイル」が存在する必要があります。 彼らによると、誤った拡張の場合にプレゼンテーションがあると判断できます。
したがって、PPTからのデータの受信を開始するには、小さな「ファイル」レコード（または1つの
CurrentUserAtom
レコードで構成される「ファイル」）
Current User
CurrentUserAtom
Current User
。 このエントリには、このファイルを最後に編集した人に関する技術情報が含まれていますが、これは最も重要ではありません。 このブロックには、以下で説明する最初の
UserEditAtom
へのオフセットに関する情報が含まれています。
次に、PPTレコードの読み取り方法を説明します。 プレゼンテーションのエントリには、特別な見出し
rh
が含まれています。これには、それに関する技術情報が含まれています。 これを行うには、レコードの最初の8バイトを読み取るだけです。 通常、最初の単語には必要な情報が含まれていませんが、次の6バイトが必要です。 オフセット2のWORD（
rh.recType
）は、次にレコードをどうするかを見つけることができるレコードのタイプを識別します。 オフセット4のLong（
recLen
）
recLen
バイトのヘッダーを除くレコードの長さ。 この記録方法は非常に便利で、プレゼンテーションファイルを解析する際の多くのエラーを回避します。
次は？
UserEditAtom
に
UserEditAtom
ます。 このエントリは既に
PowerPoint Document
ます。 後でこの「ファイル」でのみ作業します。 これと関連するエントリを読み取ることで、
PersistDirectory
オフセットの配列のようなすばらしいものを構築する必要があります。これを使用して、PowerPointドキュメントの主要な構造である
DocumentContainer
を探します。 これを行うには、現在の
UserEditAtom
エントリを読み取り、現在の「ライブ」バージョンの
PersistDirectory
へのオフセット
offsetLastEdit
と次の
UserEditAtom
へのオフセット
offsetLastEdit
を
offsetLastEdit
があります。 したがって、DWORD'e
offsetLastEdit
ゼロに遭遇するまでオフセットを受け取り続けます。
すべてのオフセット
offsetPersistDirectory
を受け取った後、この
PersistDirectory
を作成する必要があります。 逆の順序でオフセットを
PersistDirectoryAtom
、
PersistDirectoryAtom
エントリを読み取ります。 これらには、
PersistDirectoryEntry
エントリの配列が含まれます。 それぞれには、最初のエントリの
persistId
番号と現在のレコードの番号
cPersist
れます。 この情報の後に、
PersistDirectory
オブジェクトへのオフセットの配列が
PersistDirectory
ます。 これは、プレゼンテーションのすべてのオブジェクトへのリンクを見つけるための最も重要な配列です。
最後に読んだ
UserEditAtom
戻って、
docPersistIdRef
フィールドを見つけましょう。 これは、
PersistDirectory
最も重要な
DocumentContainer
オブジェクトの
PersistDirectory
です。 読んで 現在のプレゼンテーションに関する情報のキャリッジと小さなカートを保存します。ヘッダーとフッター、スライドのメモ、そして最も重要なのは、スライドに関するあらゆる種類の情報を含む
SlideListWithTextContainer
レコードです。
このメインブロックに格納されるレコードのタイプは、
TextBytesAtom
、
SlidePersistAtom
、
TextBytesAtom
3つだけ
SlidePersistAtom
。 最初の2つでは、すべてが単純です。これは、それぞれスライド上のUnicodeテキストと通常のANSIです。 もう1つは、テキストではなく
SlidePersistAtom
スライドへのリンクを取得する場合です。 それによると、PPTオブジェクトではない
Drawing
オブジェクトを読む必要があります（ sic！ ）。 はい、この場合、MS Drawingオブジェクトはスライド内に埋め込まれ、ネストされたレコードのやや不快な構造になります。
この事実を初めて知ったとき、正直に言って、私は怒っていました。 ドキュメントのページでさらに600。 しかし、判明したように、
recType
はPPTと同じ
recType
持つ同じ
rh
ヘッダー上に構築されます。 これにより、
Drawing
オブジェクト内で、すべての同じ
TextCharsAtom
および
TextBytesAtom
を
TextBytesAtom
検索することで、タスクを簡単にし、少しチートすることができました。
実装
GitHubにコメントを付けてコードを取得できます 。 まだ少し湿っていますが、近い将来、すべての落とし穴を見つけると思います。
PersistDirectory
読み取りがまったく正しくない（？）ため、主なエラーが正確にポップアップします。 誰もが明確化を持っている場合、私は喜んでそれらに耳を傾けます。