1

TEXT_ONLY2 つのモードのいずれかで PDF ファイルからコンテンツを抽出できる Java アプリが必要なシナリオがありますALL。テキスト モードでは、可視テキスト (人間が PDF を読んでいるかのように「可視」) のみが文字列に読み出されます。all モードでは、すべてのコンテンツ (テキスト、画像など) がファイルから読み取られます。

たとえば、PDF ファイルに 1 ページがあり、そのページに連続したテキストの 3 つの段落があり、2 つの画像をワードラップしている場合、 3 つのTEXT_ONLY段落すべてALLを抽出し、3 つの段落すべてと両方の画像を抽出します。

while(page.hasMoreText())
    textList.add(page.nextTextChunk());

if(allMode)
    while(page.hasMoreImages())
        imageList.add(page.nextImage());

Apache Tika が内部で PDFBox を使用していることは知っていますが、この種の機能が Tika によって隠されている/禁止されているのではないかと心配しています (その場合、おそらく PDFBox から直接これを行う必要があります)。

だから私は尋ねます：これは可能ですか？もしそうなら、どのライブラリを使用するのがより適切ですか？私はこれを完全に間違った方法で行っていますか? ここで考慮していない落とし穴/警告はありますか?

4

1 に答える 1

1

@markStephens が PDF の背景を示すいくつかのリソースを示している理由のいくつかの側面を説明します。

テキストモードでは、可視テキスト (人間が PDF を読んでいるかのように「可視」) のみが文字列に読み出されます。

人間が PDF を読んでいるかのように「見える」という定義は、まだ十分に定義されていません。

  • テキスト 1 pt のサイズは表示されますか? ズームインすると、人間はそれを読むことができます。ただし、標準倍率ではそうではありません。どのサイズが限界でしょうか？

  • (128, 128, 128) の背景に RGB (128, 129, 128) のテキストは表示されますか? 色はどのくらい違いますか？

  • 他のホワイト ノイズ パターンが表示されている背景に、ホワイト ノイズ パターンでテキストが表示されていますか? パターンの違いは？

  • テキストは画面上で部分的にしか見えませんか? はいの場合、1 つの可視ピクセルで十分ですか? そして、目に見えるページ領域が文字のドットに収まる巨大なサイズの文字「I」はどうですか?

  • おそらくファイル内で自動的に実行される JavaScript コードによってさえ、簡単に移動できる何らかの注釈で覆われたテキストについてはどうでしょうか?

  • 印刷時にのみ表示される一部のオプションのコンテンツ グループのテキストについてはどうですか?

*...

利用可能なほとんどの PDF テキスト解析ライブラリは、これらすべての状況を無視してテキストを抽出し、せいぜいクロップ ボックスを尊重するだけだと思います。追加された不可視の OCR されたテキストを含む画像の場合、一般にそのテキストの抽出が必要です。

たとえば、PDF ファイルに 1 ページがあり、そのページに連続したテキストの 3 つの段落があり、2 つの画像をワードラップしている場合、TEXT_ONLY は 3 つの段落すべてを抽出し、ALL は 3 つの段落すべてと両方を抽出します。画像:

PDF は (一般に) 段落については認識せず、ページのどこかに配置されたグリフのいくつかのグループだけを認識します。ヒューリスティックが働いているため、パラグラフの認識は適切に機能するとは保証できないタスクです。さらに、複数列のテキストが不規則に分離されている場合や、間に画像がある場合もあります (2 つの列が画像で分割されているのか、1 つの列が画像で分割されているのか判断が難しくなります)。パラグラフ、セクションなどのテキスト要素は言うまでもなく、テキストフローの認識が無残に失敗します。

PDF が適切にタグ付けされているか、作成された PDF コンテンツ ストリームのパターンがテキスト構造を裏切るツール チェーンによってすべて生成されている場合は、より幸運かもしれません。ただし、後者の場合、ソリューションはそのツール チェーン用にカスタムメイドする必要があります。

しかし、この種の機能がTikaによって隠されている/禁止されているのではないかと心配しています(その場合、おそらくpdfBoxから直接これを行う必要があります)。

そこで、別の興味深い点を指摘します。PDF は、テキスト抽出が禁止されていることをマークできますが、それ以外の場合は誰でも表示できます。技術的には、そのようにマークされた PDF は、そのマークのないドキュメントと同じように 1 回のデコード ステップで処理できます (基本的に、それらは公開されているパスワードで暗号化されます)。

だから私は尋ねます：これは可能ですか？可能であれば、どのライブラリを使用するのがより適切ですか？私はこれを完全に間違った方法で行っていますか? ここで考慮していない落とし穴/警告はありますか?

汎用入力に対して 100% の精度が期待される限り、アーキテクチャを再検討する必要があります。

PDF がすべてであり、可能な限り効果的なソリューションで問題ない場合は、一方で、iText、および PDFBox に名前を付けることができるライブラリが複数ありますが、2 つ以上あります。どちらが最適かは、その他の要因によって異なります。たとえば、一般的なソリューションが必要なのか、すべての PDF が上記のツール チェーンによって作成されているのかなどです。

いずれにせよ、ユースケースに合わせて微調整するために、自分でプログラミングを行う必要があります。

于 2013-02-25T13:40:12.620 に答える