PDFをテキストに変換する：書式そのものが邪魔になるとき
2つのPDFにdiffをかけてみてください。できません。中身はバイナリですし、同じソースから再エクスポートした
「同一」の文書ですら、タイムスタンプやオブジェクトの並び順のせいでバイト単位では一致しません。ところが両方から
テキストを抜き出して差分を取れば、契約書のリビジョン11とリビジョン14のあいだでどの3文が変わったのか、2秒で分かります。
PDFからプレーンテキストへという選択の理由は、要するにこれに尽きます。「Markdownの劣化版」ではなく、
目的が違う別の道具です。テキストは、分類器に食わせるもの、検索エンジンにインデックスするもの、ベクトルストアに
埋め込むもの、grepに流すもの、単語数を数えるもの、そして#や|を
「無視してよい飾り」ではなく「パース対象の文字」として扱う相手に渡すものです。上の変換ツールにファイルを
ドロップすれば数秒で手に入ります。無料、登録不要、1ファイル50MBまで、こちら側には何も保存しません。
マークアップを捨てて得られるもの
プレーンテキストの抽出結果は、読み順に並んだ言葉だけです。構文用の記号も、エスケープ規則も、アスタリスクが 強調なのかただの記号なのかという曖昧さもありません。意外なほど多くの処理パイプラインにとって、これは妥協ではなく 最初からの要件です。
- 埋め込みとセマンティック検索。文書をチャンクに分け、それぞれをベクトル化し、類似度で引く。 Markdownのパイプや井桁は意味には何も寄与しないのに、埋め込みベクトルの中では確実に場所を取ります。つまり 希釈です。素のまま整った散文のチャンクのほうが、検索の当たりは良くなります。
- 分類器とトピックモデル。Bag-of-words、TF-IDF、n-gram解析の類は、先に取り除かないかぎり
###を平気で1つのトークンとして数えます。そもそも混ぜないのが一番早い対処です。 - 全文検索のインデックス。Elasticsearch、SQLite FTS、Postgresの
tsvector—— どれもカラムに入れたい形は素のテキストです。Markdownを渡せば、サニタイズの工程が1つ増えるだけです。 - バージョン間の差分。行単位のdiffは散文には効きますが、表には効きません。Markdownの表は セルを1つ書き換えただけで整形が崩れ、その行がまるごと書き直されてしまうからです。
- トークンの節約。コンテキストウィンドウがきついモデルに長文を貼り付けるなら、パイプ記号の 1文字1文字が「払ったのに何も得ていないトークン」です。
そして失うもの——先に知っておいてください
平坦化は、意図的に破壊的な処理です。失うもののうち、2つはとりわけ重く効きます。
表は潰れます。財務諸表の表は、空白で区切られた数字の羅列になります。値そのものは全部残って いますが、それぞれがどの列に属していたかは残りません。どれだけプロンプトを工夫しても復元できない情報です。 表こそが文書の本体なのであれば、 PDFをMarkdownに変換を選んでください。 パイプ表なら行と列がそのまま保たれます。
階層は消えます。節の見出しと、その下の1文が、区別のつかない隣り合った2行になります。 モデルに「第4節を要約して」と頼めば、どこから第4節が始まるのかを言い回しだけから推測させることになります。 仕様書、規格、番号付き条項のある契約書——長くて構造のある文書ほど、その推測が答えを狂わせる原因になります。
ページ上部の形式切り替えはテキストとMarkdownを行き来しますが、すでに選んだファイルはそのまま引き継がれます。 両方に変換して見比べるのに必要なのはクリック1回で、アップロードのやり直しではありません。
PDFをテキストに変換すると顔を出すクセ
PDFはページ記述言語です。座標つきのグリフを並べて保存しているだけで、抽出とはそこから文を組み立て直す作業です。 必然的にいくつかの副作用が出ます。知っておくと、30分ほど首をかしげる時間を節約できます。
- 文の途中で強制改行が入る。PDFには「幅に応じて流し込まれる段落」という概念がありません。
見た目の1行ごとに独立したテキストの塊です。だから1段落が短い6行になって出てきます。
grepや 正規表現を使うときの最大の落とし穴がこれで、たまたま改行をまたいでいた語句を検索すると、 そこに確かに書いてあるのにヒット0件になります。 - ハイフネーションは残る。欧文では行末で「manage-」/「ment」と分割された単語がたいてい 分割されたままです。日本語にはハイフンこそ入りませんが、単語の途中で改行が入る点は同じで、 手がかりのハイフンすらないぶんこちらのほうが厄介です。語数カウントやキーワード抽出の前に 置換で潰しておく価値があります。
- 柱とノンブルが混ざり込む。会社名や「14/88ページ」が、数千文字ごとに本文の真ん中へ 割り込んできます。読むぶんには無害、チャンク分割にはやや邪魔、そしてパターンさえ見抜けば 1行の正規表現で落とせます。
- 段組みの順序が入れ替わることがある。2段組みの学術論文レイアウトはたいてい正しく 1次元化されますが、フローティングのサイドバー、引用の抜き出し、脚注ブロックあたりが段落の途中に 紛れ込むことはあります。
- 合字と変わったグリフ。きちんと組版されたPDFでは「fi」「fl」が1つのグリフになっている ことがよくあります。ほとんどは問題なく抽出できます。ただし、まともなUnicodeマッピングを持たない サブセットフォントで作られたPDFは、文字化けのような文字列として出てくることがあります。まれですが、 起きたときの原因はファイル側であって変換ツール側ではありません。
スキャンされたPDFには、抽出すべきテキストがそもそもない
スキャンPDFとは、紙の写真をPDFで包んだものです。中身はピクセルだけで、文字認識はPDFの内側までは踏み込みません。 画像だけのファイルは空のまま返ってきます。（同じページをJPGやPNGでアップロードすれば普通に読めます。 画像からテキストへをご覧ください。 邪魔をしているのはPDFという包装のほうです。）判定は2秒で済みます。ファイルを開いて、カーソルで1文を 選択してみてください。文字がハイライトされれば問題なし。ページ全体に長方形がかぶるだけならスキャンです。
スキャンの場合は先にOCRをかけてください。Acrobat、macOSのプレビュー、最近のPDFリーダーのほとんどに 「テキストを認識」に相当するコマンドがあります。かけてから戻ってきて変換すれば、出力品質の差は一目瞭然です。
これで片づく実際の仕事
- RAG用コーパスの構築。数百本の規程PDFをテキストにし、段落境界で分割し、ベクトル化する。 テキストは、どのチャンク分割ライブラリもデフォルトで前提にしている形式です。
- 赤入れの確認。契約書の2バージョンを抽出し、単語単位のdiffをかけて、要約メールを信じる 代わりに実際の変更点を読む。
- コンプライアンスとキーワードの一括点検。抽出済みレポートのフォルダを、定義語、取引先名、 あるいは本来あってはならない表現でgrepする。即座に、オフラインで、シェル以外の道具は要りません。
- 可読性と文体の分析。文長の分布、専門用語の密度、読解レベルの指標——どれも、流れの中に 書式用トークンが混ざっていない素の散文を求めます。
- 音声合成に流す。Markdownをそのまま渡せば、スクリーンリーダーやTTSエンジンは 「シャープ シャープ はじめに」と元気よく読み上げてくれます。
- トークン量の即時確認。出力の下にあるカウンターが、どこかに貼り付ける前にその文書の コストを教えてくれます。切り詰めエラーで初めて知るより、はるかに有用です。
よくある質問
PDFファイルを無料でテキストに変換するには？
ページ上部の変換ツールにファイルをドロップすれば、抽出されたテキストがすぐ下に表示されます。アカウントもメールアドレスも不要で、出力に透かしも入りません。上限は1ファイル50MB、テキストを受け取った時点で何も残りません。そのままコピーしても、.txtとしてダウンロードしてもかまいません。
PDFのテキスト変換結果が文字化けするのはなぜ？
ほぼ必ずフォント側の問題で、変換ツールのせいではありません。Unicodeマッピングを同梱していないサブセットフォントで作られたPDFは、グリフのインデックスだけを保存していて、それがどの文字に対応するのかを持っていません。そのため抽出するとインデックスが意味のない文字列として出てきます。お使いのPDFリーダーでもテキストを選択できないようなら、原因はファイルそのものです。元の文書から書き出し直してください。
スキャンしたPDFの文字起こしはできますか？
直接はできません。スキャンはPDFで包まれた写真であり、中に文字が1つも入っていないので、結果は空で返ります。回避方法は2つ。Acrobatやプレビュー（macOS）で先に「テキストを認識」を実行してからここで変換するか、ページをPNGとして書き出して画像からテキストへを使うかです。後者はピクセルに対して実際にOCRをかけます。
抽出したテキストが文の途中で改行されているのはなぜ？
PDFには流し込み可能な段落という概念がなく、見た目の1行がそれぞれ独立したテキストの塊として保存されているからです。結果として1段落が短い6行になって出てきます。とくに痛いのがgrepと正規表現で、改行をまたいだ語句は検索結果0件になります。検索の前に、文末の句読点で終わっていない行を連結しておいてください。
PDFはtxtとMarkdownのどちらに変換すべき？
渡す先が素の語を解析するならテキストです。埋め込み、検索インデックス、分類器、diffがこれにあたります。文書の形そのものが意味を持つならMarkdownです。パイプ表が生き残り、見出しも印がついたまま残ります。判断の分かれ目は表です。財務諸表をテキストに平坦化した瞬間、どの数字がどの列のものだったかは永久に失われます。
PDFはサーバーにアップロードされますか？
ファイルは変換サービスに送られ、処理され、破棄されます。保存もログ記録もインデックス化もせず、レスポンスを返した後には何も残しません。ファイルが本当に端末から出ない形で変換したい場合は、ローカルフォルダ変換がブラウザ内でファイルを読み込みます。
ツールキットの残り
PDFは対応13形式のうちの1つにすぎません。File2Txt なら1回のアップロードで全形式を扱えますし、目的が決まっているなら Wordをテキストに（DOCXファイル向け）、 HTMLをテキストに（保存したWebページ向け）、 EPUBをテキストに（電子書籍向け）、 画像をテキストに（スクリーンショット向け）へ直接どうぞ。 扱う対象がコードなら、 GitHubリポジトリをテキストに、 GitLabプロジェクト、 ローカルフォルダを変換できます。公開中のWebページなら、 Web2TxtがURLから直接取得します。 LLM向けに文書を整える方法のガイド では、ここまでの話の一般論をまとめています。
Repo2Txtを開発・運営しているのは v12hero、 プライバシー最優先のネイティブアプリとWebアプリを作る独立系デベロッパーです。