問題タブ [apache-tika]

私が見つけることができるすべてのドキュメントは、ファイルのコンテンツ全体しか抽出できないことを示唆しているようです。しかし、ページを個別に抽出する必要があります。そのために独自のパーサーを作成する必要がありますか? 私が見逃している明らかな方法はありますか？

Solr 3.1、Apache Tika 0.9、および Solrnet 0.3.1 を使用して、.doc および .pdf ファイルのようなドキュメントにインデックスを付けています。

このコードを使用して、ローカルでドキュメントのインデックス作成と抽出に成功しました

しかし、同じコードを使用してリモートからドキュメントを抽出またはインデックス化するという問題に直面しています。エラーが発生しました:

メッセージ

メッセージ

説明

ディレクトリ内のすべての pdf/doc ファイルをスキャンしようとしています。これは正常に機能し、すべてのドキュメントをスキャンできます。

次にやろうとしているのは、検索結果でファイルのファイル名を受け取ることです。ただし、ファイル名は表示されません。いくつかのことを試しましたが、ドキュメントはこれを行う方法についてあまり役に立ちません。

solr ディストリビューションにある solr 構成を使用しています: apache-solr-3.1.0/example/example-DIH/solr/tika/conf

これは私のdataConfigです：

これを正しく構成する方法と、特定のドキュメントを見つけることができる他の場所に興味があります。

カスタム検索エンジンを備えた jsp Web アプリケーションがあります。

検索エンジンは、基本的に SQL Server データベースの「ドキュメント」テーブルの上に構築されています。

たとえば、各ドキュメント レコードには次の 3 つのフィールドがあります。

• ドキュメント ID
• '説明' (テキスト フィールド)
• 「添付ファイル」、ファイル システム内の pdf ファイルのパス。

検索エンジンは実際に説明フィールドのキーワードを検索し、結果リストを HTML ページに返します。今、PDFファイルのコンテンツでもキーワードを検索したいです。

Lucene、Tika、Solr について調査していますが、これらのフレームワークを目的に使用する方法がわかりません。

考えられる解決策の 1 つは、Tika を使用して PDF コンテンツを抽出し、新しいドキュメント テーブル フィールドに格納して、このフィールドに SQL クエリを記述できるようにすることです。

より良い代替手段はありますか？Solr/Lucene のインデックス作成機能を、SQL ベースの検索エンジンの完全な代替としてではなく、統合として使用できますか?

ありがとう

ファイルからメタデータを抽出する新しい Tika パーサーを作成できるようにしたいと考えています。すでに Tika を使用しており、メタデータの抽出は一貫して行われます。

Tika のこの問題/機能強化のリクエストに遭遇したと思います。

ファイルまたはメモリ バッファをパーサーに渡すことを許可する

入力時にファイルへのパスを受け入れ、見つかったメタデータを出力するコンソール c++ 実行可能ファイルがあり、各行は名前と値のペアで構成されています。
C++ コードは、データにアクセスするときにファイル パスを必要とするライブラリに依存しています。この実行可能ファイルを Java で書き直すことはできません。これをTikaに差し込むのはかなり簡単だと思いました。ただし、Tika パーサーは Java である必要があり、オーバーライドする必要がある Tika パーサー メソッドは、開いている入力ストリームを受け取ります。

void parse(InputStream ストリーム、ContentHandler ハンドラ、メタデータ メタデータ、ParseContext コンテキスト)

したがって、私の唯一の解決策は、入力ストリームを取得して一時ファイルに書き込み、書き込まれたファイルを処理してから最終的にファイルをクリーンアップすることだと思います。一時ファイルをいじって、何か問題が発生して削除されなかった場合に一時ファイルのクリーンアップについて心配する必要がある可能性があるのは嫌いです。

このようなものをきれいに処理する方法について、賢いアイデアを持っている人はいますか?

誰か私がそれを整理するのを手伝ってくれませんか?

このようにできます

ただし、Tika を直接使用しない場合は、次のようになります。

と対話しないため、設定する方法はありませんWriteOutContentHandler。ところで-1、デフォルトではに設定されています。つまり、制限はありません。ただし、結果の制限は 100000 文字です。

curl ベースのリクエストを使用してインデックスを作成しようとしています

リクエストは

リクエストを送信すると、このエラーが発生します。

どうにかしてそれを行う方法を説明することができた人を喜ばせることができます:-)

追加する必要がある言語の n-gram ファイルを取得する必要がありますか?

を作成しtika.language.override.properties、他の lang コードを追加して、classPath に lang-code.ngp n-gram ファイルを追加することは問題ですか? その場合、どこで入手できますか? また、これだけの問題である場合、Tika がより多くの言語をサポートしていないのはなぜですか?

現在、言語検出でサポートされている言語は次のとおりです。

tika は従来の n-gram 表記を使用します

この言語検出アプリケーションは現在これらの言語をサポートしていますが、n-gram ファイルが少し異なります

JSON表記で

Java ベースのApache Tikaフレームワークの C/C++ 代替を探しています。具体的には、ファイルのメタデータと構造化テキストの抽出をすべて 1 つのフレームワークで検索しています。いくつかのオンライン検索と閲覧の後、私が持っている最も近いものは、GNU libextractorと、ドキュメントを解析してテキスト データ (pdftoext、xls2csv ..etc) を抽出する個々のファイル フィルターの束です。

Apache の Tika に匹敵する優れたライブラリをお勧めできますか?

ありがとう

ユーザーがアップロードした 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 を解析します (アンチワードはそれらを完全に解析します)。それでも、それは明らかに松葉杖であり、他の誰かが同じ問題に直面しているのだろうか.

または、それが既知の問題である場合、それを解決するためのよりエレガントな方法は何ですか (アンチワードに頼るのは好きではありません)。