ユーザーがアップロードした doc/docx/pdf ファイルのコンテンツにインデックスを付け、そのために Solr (1.4.1) ExtractingRequestHandler コンポーネント (817165) を使用する必要があります。それが重要な場合は、インデックス作成を要求しません。コンポーネントは常にドキュメントのテキスト コンテンツのみを返す extractOnly パラメーターを使用して呼び出され、それ自体をすぐにインデックスに追加することはありません (その後、コンテンツはインデックスに追加されます。" outside」を標準的な手順に従ってドキュメントのテキスト フィールドとして入力します)。
ただし、一部のファイルは解析されず、コンポーネントは 500 Internal Server Error を返し、その他の詳細は提供されません。ユーザーが送信したすべての *.doc ファイルのうち、約 30% が解析に失敗しています。
Solr の読み込みの問題ではありません。解析できないファイルは、同じリストを何度も解析すると常に同じです。サイズの問題でもありません - それらの多くは、正常に解析された他のものよりも小さいです。どうやら、それは独特のフォーマットに関するものではありません (または、少なくともそれは明白ではありません) - 解析に失敗したほとんどすべてのドキュメントには、色付きのフォント、表、および画像がありますが、正常に解析されたドキュメントの多くも同じです。
これらのファイルはすべて Word で開かれ、警告やエラーは発生しません。それらを docx として保存すると、Solr はそれらを正しく解析し始めますが、同じ内容の同じ doc 形式でそれらを再保存しても役に立ちません。それでも、すべてのコンテンツが削除され、いくつかの lorem ipsum テキストに置き換えられ、ドキュメントとして保存された場合、それらは正しくなります。
コンテンツの置換が役立つため、ドキュメントで使用されるいくつかの要素を含むものである必要がありますが、Tika Formatsページには、ドキュメントの解析が失敗した場合の説明はありません。
サンプル ファイルをアップロードしましたが、これを試してみたいという好奇心があれば、解析に失敗します (このファイルは、Windows Live が "オンライン ドキュメント" に変換するのを防ぐためにアーカイブされています)。
現在、回避策として、古いアンチワードユーティリティを使用して、Solr が失敗する *.doc を解析します (アンチワードはそれらを完全に解析します)。それでも、それは明らかに松葉杖であり、他の誰かが同じ問題に直面しているのだろうか.
または、それが既知の問題である場合、それを解決するためのよりエレガントな方法は何ですか (アンチワードに頼るのは好きではありません)。