ODFと古い（1997-2003）MS Word文書のApache Tika解析を変更しますか？

Question

私は、大規模なファイルのLuceneインデックス作成を行うアプリケーションを開発しています（複数のorg.apache.lucene.document.Documentsにそれらをさまざまな形式で分割します）。最初のアプローチでは、少なくとも「Luceneドキュメント」は1つの「段落」から構成されています。

一般的に、Apache Tikaはこれにはあまり意味がありません。単純にドキュメントを投げるだけで、どのようなフォーマットであってもすべてのテキストを吸い取っているようです。

しかし、私はそれが扱いにくい側面をどのように扱っているかについての詳細な知識を得たいと思っていました。最初の見方では、脚注と文末脚注をどのように処理するかで、 「3つの脚注に沿っため、：

|Tecum optime[footnoteRef:2], deinde etiam[footnoteRef:3] cum mediocri amico[footnoteRef:4]. 
[2: Sed quoniam et advesperascit et mihi ad villam revertendum est, nunc quidem hactenus; 
Quod si ita sit, cur opera philosophiae sit danda nescio.] [3: Si quae forte-possumus. 
Immo videri fortasse.] [4: Huius ego nunc auctoritatem [sequens idem faciam]. Confecta 
res esset. Primum Theophrasti, Strato, physicum se voluit; Ut proverbia non nulla veriora 
sint quam vestra dogmata.]| 

（NB 『ライン|の.doc形式ティカで同じファイルを持つ』の文字がわかりやすくするために私のコードによって追加されている）

は...あなたを与えます複数の「行」：

|Tecum optime| 
|, deinde etiam| 
| cum mediocri amico| 
|.| 
... 

|??| 
| ? Sed quoniam et advesperascit et mihi ad villam revertendum est, nunc quidem 
hactenus; Quod si ita sit, cur opera philosophiae sit danda nescio. | 
|??| 
| ? Si quae forte-possumus. Immo videri fortasse. | 
|??| 
| ? Huius ego nunc auctoritatem [sequens idem faciam]. Confecta res esset. Primum 
Theophrasti, Strato, physicum se voluit; Ut proverbia non nulla veriora sint quam 
vestra dogmata. | 

...元の "段落"を複数の行に分割し、各脚注refを破るだけでなく、すべての脚注を処理の最後までプッシュします。

.docxファイル処理を使用すると、脚注を抽出し、脚注を所属する文に簡単にリンクすることができます。 .docの処理方法は、もちろん私のインデックス作成の目的にはあまり役に立たない。実際、最初の4つの「線」が、同じパラパラに本当に属していると特定できる方法を実際に見ることはできません。

恐らく、.docのような古くなったフォーマットをTikaが処理することはそれほど素晴らしいものではないと予想されます。 Gradleがダウンロードした多くのソースジャーの中から見つけることができると仮定して、ここに含まれる実際のソースコードを見ようとしていますが、コードを調整するのではなく、Tikaの与えられた形式の解析？私は何か検索しましたが、何も見つかりませんでした。

もちろん、別のアプローチとして、.docファイル（と.odtファイル、以下を参照）を.docx形式で「オンザフライ」で高品質の解析を行うことがあります。

PSを解析するLibreOffice .odtファイル（Open Document Format、ODF）は、旧式ではない形式でも同様に問題があります。特に、脚注/文末行を含む行は同様に複数の行に分割されます。

Answer 1

私の所見は興味がある人のために数日後でした。

最初に、Apacheの人々は、あなたがTikaクラスを使っていないと考えているようです。

MS Word 97-2003形式（別名.doc）の処理を調整しようとすると、ここに含まれるメインクラスはHWPFDocument（「恐ろしいワードプロセッシング形式」）です。 TikaにバンドルされているApache POIプロジェクトの一部。

このクラスは通常、.docファイルからInputStreamを保持し、ファイルのさまざまな要素をむしろうまく分割しているように見えます。そのため、脚注などがテキストとは別に保存されているようです。 HWPFDocumentはfinalです。これは、問題の始まりに過ぎません。多くのファイルは、パッケージ内の他のクラス、またはfinalまたはなどのサブパッケージに依存しています（protected）。私は基本的にはorg.apache.poi.hwpfパッケージ全体をクローンして、それを医者にまとめてパッケージ化しなければならないという結論に達しました。私は気にすることができませんでした。

.odt（ODF）ファイルタイプは、最終的に私にとって本当にはるかに重要です。旧式ではなく、非Micro $ oft。ここで重要なクラスはorg.apache.tika.parser.odf.OpenDocumentContentParserであることが判明しました。ここでの問題は、内部クラスprivate finalが含まれていることです（つまり、実際にはサブクラス化するか、何らかの理由でそのインスタンスを使用したくないということです）、OpenDocumentElementMappingContentHandlerと呼ばれ、最終的にはorg.xml.sax.ContentHandlerとなります。たくさんの（よく、たくさんの）ContentHandlerがここに含まれています。その多くは「デコレータ」です。しかし最終的には、このクラスのコード全体をコピーしてOpenDocumentContentParserをコピーしてから、内部クラスを使いこなしてください。 startElementとendElementに、パラメータqNameの値に基づいて、 "UNDEFINED" "NOTE_CITATION"または "NODE BODY"の可能な値の "解析モード"に切り替えるようにしました。このモード設定の根拠は、コールendElementで

super.endElement(namespaceURI, localName, qName); 

をキャンセルすることができます。このsuperコールは、1つの文字列の終わりと次の文字列の始まりをトリガーするように見えます。脚注番号や体が開始されたテキストの表示を配置するには/あなたの出力テキストで終わるあなたはString injectedTextを作成し、

super.characters(injectedText.toCharArray(), 0, injectedText.length()); 

場合、適切な行くことができます。実際何かをする究極のContentHandlerがToTextContentHandlerのインスタンスであるため、これは、のcharacters(...)方法は、ちょうどjava.io.Writerインスタンスへcharsのシーケンス追加（はい、私はそのことを聞いたことがありませんでしたが、次のいずれかの非常にシンプルな） 。

これが役に立ちます。この新しいクラスのクラスをTikaプロジェクトに提出して、彼らがその外観を好きであるかどうかを確認してください。