text_fields PDFテキスト抽出ツール star

PDFのテキストレイヤーとは実際には何なのか

PDFはページの「画像」ではありません — 少なくとも通常は。ワープロソフト、Webページ、あるいは組版ソフトウェアからPDFが作られるとき、ページの内容は一連の描画命令として保存されます。「グリフGをフォントF、サイズSで座標(x, y)に配置する」という命令が、ページ上のすべての文字について繰り返されるのです。それぞれのグリフ配置命令は、フォントの文字エンコーディングテーブルへの参照を持っており、そのおかげでソフトウェアは、描画された形をただの絵ではなく実際のUnicode文字として対応付けることができます。このツールは、MozillaのオープンソースライブラリであるPDF.jsを使ってPDFを読み込み、すべてのページでgetTextContent() APIを呼び出すことで動作します — 重要なのは、この方法がページをピクセルとして描画することなく、この命令のストリームを直接読み取るという点です。そのため、グラフィックアクセラレーションのないデバイスでも動作し、レンダリングに比べてほぼ瞬時に処理が完了します。

これは、紙の文書を写真に撮ったりスキャナーにかけたりしてPDFとして保存した際に得られるスキャンされたPDFとは根本的に異なります — その場合の「ページ」は、単なるページ全体のJPEGやTIFF画像であり、その背後にグリフ命令はまったく存在しません。テキストが何であるかをどのソフトウェアも把握しておらず、ただピクセルを取り込んだだけだからです。スキャンされたページに対してgetTextContent()を呼び出しても、何も、あるいはほぼ何も返ってきません。読み取るべきテキストレイヤーがそもそも存在しないためです — 通常のPDFビューアでスキャンされたページのテキストを選択できないのと同じように、その情報は本当にファイルの中に存在しないのです。スキャンされた文書からテキストを復元するには、まったく別の技術であるOCR(光学文字認識)が必要です。これはピクセルの形を分析して文字を推測する処理であり、本質的に異なる、はるかに誤りの多いプロセスであり、このツールはそれを行いません。あなたのPDFがスキャンされたものである場合は、代わりに専用の画像からテキストへ(OCR)のツールを探してください — 当サイトでは別途そうしたツールを用意する予定です。

抽出したテキストの順序が崩れることがあるのはなぜか

実際にテキストレイヤーを持つPDFであっても、より捉えにくい問題が生じることがあります。getTextContent()は、PDFが生成された際に元々描画された順序でグリフ配置項目を返します — それは必ずしも人間が読む順序とは限りません。単純な単一段組の文書のほとんどは上から下、左から右へと描画され、自然な読み順と一致するため、抽出結果は正しく見えます。しかし、PDFの書き出しソフトウェアはどのような順序で内容を描画してもよく、多くのソフトウェアは視覚的な順序を保持しません。2段組の学術論文、雑誌風のレイアウト、表、あるいはテキストボックスや吹き出しを含むPDFでは、仕様が定義しているのは読む順序ではなく位置であるため、描画順序が読者の視線の動きに対して入り交じったり、完全に逆転したりすることが容易に起こります。このツールはpdf.jsが報告する順序で各ページの項目を連結し、はっきりとした--- Page N ---マーカーでページを区切ります。これにより、どのブロックがどのページから来たのかを正確に把握でき、必要であれば複数段組の結果を手動で並べ替えることができます。

• アップロードは一切行われません: PDFはブラウザ内で動作するpdf.jsを使って完全にクライアント側で解析されます。ファイルがこのサイトのサーバーに届くことはありません。
• パスワードで保護されたPDFは開けません — このツールはPDFの暗号化や権限を回避しようとはしません。
• 抽出された空白は視覚的なレイアウトと異なる場合があります — 特に表は、整形されたグリッドとしてではなく、セルの値がフラットに並んだ列として抽出されることがよくあります。PDFにはHTMLのような「表」というネイティブな概念が存在しないためです。
• 複数ページの文書にはページマーカーが付きます。PDFのページは本来、互いに独立したコンテンツストリームであり、ページ間に本質的な段落の区切りが存在しないため、これにより1つのページの内容がどこで終わり、次のページがどこから始まるかがわかります。