私は、多数の PDF ドキュメントからテキストを抽出するためのシンプルなコンソール アプリケーションまたは PowerShell スクリプトを作成しようとしています。これを行うためのライブラリや CLI ツールはいくつかありますが、どれもドキュメント構造を確実に識別できないことがわかりました。特に、テキスト列の認識が心配です。非常に高価な PDFLib TET ツールでさえ、隣接する 2 つのテキスト列の内容がごちゃ混ぜになることがよくあります。
PDF 形式には列の概念、さらには単語の概念さえ存在しないことがよく指摘されています。SO の同様の質問に対する回答のいくつかで、この点が言及されています。この問題は非常に大きいため、学術的な研究さえ必要になります。このジャーナル記事ノート：
PDF ファイル内のすべてのデータ オブジェクトは、視覚的な方法で、演算子のシーケンスとして表現されます。演算子のシーケンスは、通常、トークン、行、列などの高レベルのテキスト単位に関する情報を伝えません。このような単位間の境界に関する情報は、空白を通じて暗黙的にのみ提供されます。
そのため、私が試したすべての抽出ツール (iTextSharp、PDFLib TET、Python PDFMiner) は、テキスト列の境界を認識できませんでした。これらのツールの中では、PDFLib TET のパフォーマンスが最も優れています。
ただし、非常に軽量でオープン ソースの PDF リーダーである SumatraPDF や、同様の他の多くの PDF リーダーは、列とテキスト領域を完璧に識別できます。これらのアプリケーションの 1 つでドキュメントを開き、ページ上のすべてのテキスト (または CTRL+A でドキュメント全体) を選択してコピーし、テキスト ファイルに貼り付けると、テキストはほぼ完璧に正しい順序でレンダリングされます。フッターとヘッダーのテキストが列の 1 つに混在することが時々あります。
そこで私の質問は、これらのアプリケーションは、一見非常に困難と思われること (PDFLib のような高価なツールでも) をどのようにして実行できるのかということです。
編集 2014 年 3 月 31 日: 参考までに言うと、PDFBox は iTextSharp (特注の Strategy 実装にもかかわらず) よりもテキスト抽出がはるかに優れており、PDFLib TET は PDFBox よりもわずかに優れていますが、かなり高価です。Python PDFMiner は役に立ちません。私が見た中で最高の結果は Google から得られました。PDF (一度に 2 GB) を Google Drive にアップロードし、テキストとしてダウンロードできます。これが私がやっていることです。PDF を 10 ページのファイルに分割し (Google は最初の 10 ページのみを変換します)、ダウンロード後にそれらを再び結合する小さなユーティリティを作成しました。
2014 年 4 月 7 日編集。前回の投稿をキャンセルします。MS Word を使用すると、最も優れた抽出が実現します。また、これは Acrobat Pro で自動化できます ([ツール] > [アクション ウィザード] > [新しいアクションの作成])。Word からテキストへの変換は、.NET OpenXml ライブラリを使用して自動化できます。ここはクラスですこれにより、抽出 (docx から txt) が非常にきれいに実行されます。最初のテストでは、MS Word 変換はドキュメント構造に関してかなり正確であることがわかりましたが、プレーン テキストに変換されると、これはそれほど重要ではありません。
ベストアンサー1
私はかつて、あなたがおっしゃったこととまったく同じことを実行するアルゴリズムを PDF エディター製品用に作成したことがあります。その PDF エディターは、現在でも最も多く使用されている PDF エディターです。あなたがおっしゃったことにはいくつかの理由があると思いますが、重要なのは焦点が絞られていることです。
PDF には (通常) 構造情報がまったく含まれていないというのは正しいです。PDF はページの視覚的表現に関心があり、必ずしもそのページの「意味」には関心がありません。つまり、最も純粋な形式では、行、段落、列などの情報は必要ありません。実際、テキスト自体の情報さえ必要ありません。テキストをコピーして貼り付けると意味不明になってしまう PDF ファイルも数多くあります。
したがって、フォーマットされたテキストを抽出できるようにしたい場合、ページ上のすべてのテキスト部分を調べ、場合によっては線画情報も考慮に入れて、それらをつなぎ合わせる必要があります。通常、これは、空白を調べて、最初に何が行で、何が段落かなどを判断するエンジンを作成することによって行われます。たとえば、表は非常に多様であるため、非常に難しいことで有名です。
代替戦略としては次のようなものが考えられます。
- 利用可能な構造情報のいくつかを見てみましょういくつかのPDF ファイル。一部の PDF/A ファイルとすべての PDF/UA ファイル (アーカイブ用 PDF とユニバーサル アクセシビリティ用 PDF) には、構造を取得するために使用できる構造情報が必要です。他の PDF ファイルにもその情報が含まれている場合があります。
- PDF ドキュメントの作成者を調べ、それらの PDF を適切に処理するための特定のアルゴリズムを用意します。Word のみに関心がある場合、または処理する PDF の 99% が Word 2011 から作成されることがわかっている場合は、その知識を活用する価値があるかもしれません。
では、なぜ一部の製品は他の製品よりもこの点で優れているのでしょうか? おそらく焦点が合っているからでしょう。PDF 仕様は非常に広範囲にわたっており、一部のツールはより低レベルの PDF タスクに重点を置き、一部のツールはより高レベルの PDF タスクに重点を置きます。一部は「オフィス」での使用を指向し、一部は「グラフィック アート」での使用を指向します。焦点に応じて、特定の機能が注目に値するかどうかが決まる場合があります。
さらに、これはひどい答えのように思えるかもしれませんが、これはアルゴリズム的に難しい問題であり、市場の平均的な製品よりもはるかに優れたアルゴリズムを実装するには、天才的な開発者が 1 人必要だと考えています。これは、賢くて、それにいくらか注意を向けるだけの集中力があり、特に、これを書いているターゲット市場が何であるかをよく理解している場合、他の人は平凡な結果になる一方で、あなたは正しく結果を出すことができる領域の 1 つです。
(そして、私がそのコードを書いていた当時は、それを正しく理解していませんでした。私たちは最後までやり遂げて本当に良いものを作るための十分な集中力がなかったのです)