しばらく前に、さまざまなデータ形式（PDFまたはDOC）からクリアテキストを取得することについて説明しました。
ある議論では 、PowerPointプレゼンテーションを解析することにより、I核や別のひどいソフトスポット病を獲得することが示唆されました。 まあ、運命の意志で、私はこの「甘い」フォーマットからテキストを取り出さなければなりませんでした。 率直に言って、私
は hemoを
獲得できませんでしたが、プレゼンテーションを解析するためのクラスが出てきました。
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読み取りがまったく正しくない（？）ため、主なエラーが正確にポップアップします。 誰もが明確化を持っている場合、私は喜んでそれらに耳を傾けます。
文学
すべての費用でテキスト