Solr Cell / ExtractingRequestHandlerは、いくつかの *.docファイルを解析できません

Question

ユーザーによってアップロードされたDOC/DOCX/PDFファイルのコンテンツをインデックス化し、そのためにRrequestHandlerコンポーネント（817165）を抽出するsolr（1.4.1）を使用する必要があります。それが重要な場合、私はそれからインデックス作成を要求しません - コンポーネントは常にドキュメントのテキストコンテンツを返すextractonlyパラメーターで常に呼び出され、すぐにインデックスにそれを追加しません（コンテンツはインデックスに追加されます」標準手順に続くドキュメントのテキストフィールドとして」外側。

ただし、一部のファイルは解析されず、コンポーネントは500の内部サーバーエラーを返し、他の詳細は提供されていません。ユーザーが提出したすべての *.docファイルのうち、約30％が解析できません。

それはsolrロードの問題ではありません - 解析できないファイルは、それらのリストを何度も何度も解析する場合、常に同じです。また、サイズに関するものではありません - それらの多くは、他のものよりも小さいです。どうやら、それは独特のフォーマットに関するものではありません（または少なくともそれは明らかではありません） - 解析に失敗したほとんどすべてのドキュメントには、色付きのフォント、テーブル、画像がありますが、解析されたものの多くは同じものを持っています。

これらのすべてのファイルは、警告やエラーなしで単語で開きます。 Docx Solrが正しく解析し始めると、それらを保存すると、同じコンテンツを使用して同じドキュメント形式でそれらを再節約することはできません。それでも、すべてのコンテンツが削除され、いくつかのLorem Ipsumテキストに置き換えられ、Docとして保存された場合、それらは正しくなります。

コンテンツの置換が役立つように、それはドキュメントで使用されている要素があるものである必要がありますが、説明はありません ティカ形式 ドキュメントのどのケースが失敗するかを示すページ。

アップロードしました サンプルファイル 誰かが試してみるのに十分な興味がある場合に備えて解析できません（Windows Liveが「オンラインドキュメント」に変換するのを防ぐためにアーカイブされています）。

現在、私は古代を使用しています アンチワード solrが失敗する *.docを解析するユーティリティ（そして、アンチワードがそれらを完全に解析します）。それでも、それは明らかに松葉杖であり、他の誰かが同じ問題に直面しているのだろうかと思います - 私はそれをグーグルでグーグルではないので、おそらくそれは私が何か間違っていることです。

または、それが既知の問題である場合、それを解決するためのよりエレガントな方法は何ですか（私は反語に頼るのが好きではありません）。

Answer 1

私があなただったら、私はティカをアップグレードしてみます

私はあなたのサンプルファイルを取得し、Tikaの最新バージョンでそれを試しました。テキストへの抽出は正常に機能します

LOREM IPSUM
Lorem ipsum dolor sit amet
------

Home Phone:           000000000

Work   :   00000000           

（等）

ですから、私はそれが現在修正されたPOI+Tikaの古いバージョンの問題だと思います。

（SolRのカスタムビルドコピーを使用している場合、POMとReビルドのTika依存関係を押し上げるだけで、Mavenはあなたのためにそれを処理します。標準としてのティカ）