EPUBをテキストに変換する：本棚一冊分を計算できるデータにする
書籍は、人類が手にしている長文の中でもっとも編集が行き届いた素材です。プロが書き、プロが校正し、 数万語にわたって文体が一貫していて、ナビゲーションメニューもCookieバナーもコメント欄も混ざりません。 埋め込み、文体分析、検索、口調を判定する分類器の学習など、言語を扱う処理の原料としてこれに勝るものは なかなかありません。
問題は、それがzipされたXHTMLファイルの束の中にあることです。EPUBから本文を抽出すると 中身が取り出せます。切れ目のない一続きの文章で、タグもマークアップ記号もなく、トークナイザーに 無視の仕方を教えなければならないものは何も残りません。上からアップロードすれば数秒で返ってきます。 無料、登録不要、50 MBまで、保存は一切しません。
EPUBから本文を抽出するならフラットなテキストが向く
ここでのプレーンテキストは妥協案ではありません。書籍を大量に処理する用途のほとんどでは、 ツール側が最初から想定している形式です：
- 埋め込みと意味検索。文章をチャンクに割り、それぞれを埋め込み、類似度で引く。 Markdownの井桁やアスタリスクはトークンの位置を占めるだけで意味には寄与せず、ベクトルを薄めます。 きれいな段落のほうが検索精度は上がりますし、世の中のチャンク分割ライブラリはどれも既定で テキストを受け取ります。
- 読みやすさ指標と文体計量。平均文長、語彙の豊富さ、異なり語数比、句読点のリズム。 いずれも語と文のレベルの指標で、書式のトークンはそのすべてを歪めます。
- 蔵書全体を横断する検索インデックス。Postgresの
tsvector、SQLiteの FTS5、Elasticsearch、あるいはgrepをかけるだけのフォルダ。どれもフィールドに 生のテキストを求めます。50冊も変換すれば、かなり速い個人用検索エンジンになります。 - コーパス言語学とNLPパイプライン。コンコーダンス、共起分析、固有表現抽出、 トピックモデル。spaCyもNLTKも受け取るのは文字列であって、マークアップではありません。
- 音声合成とアクセシビリティ。Markdownを渡された読み上げエンジンは、 「井桁井桁 第4章」と元気に読み上げます。
- 版どうしの差分。同じ書名の2つの刷をテキストに抽出し、語単位の差分にかける。 第2版が実際に何を変えたのかを知る方法はこれです。
平坦化して失うもの
章の境界です。これが実際のコストで、しかも他の文書形式より書籍のほうが痛みます。本は 「いま自分はどこを読んでいるのか」が問題になる程度には長いからです。
元のEPUBでは、章ごとに独立したXHTMLファイルがあり、見出しタグが付き、ナビゲーション文書に項目が 載っています。平坦化すると、章タイトルは長い文章の上に置かれた短い一行になり、それが他と違うことを 示す印は何もなくなります。「第7章を要約して」と頼めば、モデルは第7章がどこから始まるかを文面だけ から判断することになります。たいていはうまくいきます。ときどき一段落ずれたところから読み始めて、 黙って違う場所を要約します。
引用ブロックが地の文と見分けられなくなるのも同じ話で、引用元の資料と著者自身の論が隣り合う ノンフィクションでは効いてきます。そこが今回の作業にとって重要なら、 EPUBをMarkdownに変換 を選んでください。見出しのツリーが残るので、章単位できれいに切り出せます。このページ上部の形式 トグルで両者を行き来でき、選択したファイルもそのまま運ばれるので、2回アップロードせずに両方を 作って比べられます。
後始末が必要になる組版由来のクセ
出版社はきちんと組版します。読む分にはありがたく、計算処理にはやや厄介です。抽出した書籍テキストに はいくつか決まって現れるものがあり、その大半は一度の置換で片付きます：
- 約物が組版用の文字になっています。書籍は活字用の引用符を使い、直線の
"や'は出てきません。トークナイザーはたいてい吸収しますが、 素朴な正規表現や文字列一致はそうはいきません。本文が三点リーダーで埋まっているのに...で検索して一件も当たらない、といったことが起こります。 - ダッシュと三点リーダー。日本語書籍では ―― や …… のように2つ重ねるのが慣例で、 前後に空白がないため、文分割器が2文をつなげたり、おかしな位置で切ったりすることがあります。
- ソフトハイフン、ノーブレークスペース、全角スペース。画面上は見えないのに バイト列には存在し、どの数字とも一致しない文字数の原因になります。
- 合字と外字。欧文の「fi」「fl」が1つのグリフになっていることがあります。通常は 問題なく抽出できますが、変わった埋め込みフォントだと妙な文字が混じります。日本語書籍では、 規格外の漢字が画像として埋め込まれている場合があり、そこは抽出結果から丸ごと抜け落ちます。
- 前付けと後付け。扉、奥付、献辞、謝辞、著者紹介、索引の残骸。変換するどの本にも 現れる定型文なので、コーパス全体では不自然に高頻度な語彙になります。頻度分析をするなら 削ってください。
どれもコンバータが雑なせいではありません。ファイルに実際にそう入っているだけで、探すべきものを 知っていることが対策のほとんどです。
DRMの壁と、変換できる本の入手先
大手ストアで買った本はたいてい暗号化されています。コンテナ内のXHTMLがスクランブルされ、
encryption.xml がその旨を宣言しているので、どのコンバータも、もちろんこれも、
一語も読めません。アップロードするとエラーか空の出力が返ります。10分悩む前に知っておく価値が
あります。
一方で、設計上DRMのない供給元はいくらでもあります。Project Gutenbergのパブリックドメイン目録は 膨大で、コーパス作りには理想的です。Standard Ebooksはパブリックドメイン作品を丁寧に組版し直して いて、マークアップが際立ってきれいです。技術書の出版社の多く、プレプリント寄りの出版、 クリエイティブ・コモンズの作品、そして自分で書き出したファイルは問題なく変換できます。自分が 持っている本を自分の勉強のために変換するのは通常の利用です。著作権のある本の抽出テキストを 再配布するのはそうではありません。以上です。
蔵書まるごとを対象にするとき
1冊の変換は2秒の作業です。面白いのは40冊変換して、その結果をデータセットとして扱うほうです。 これをうまく回すための勘所をいくつか：
- まとめてzipにする。ZIPをテキストに変換 はアーカイブを受け取り、中の対応ファイルを一度に全部変換します。40回アップロードするより 確実に早いです。50 MBの上限には注意してください。EPUBは小さいものの、図版の多い本はそうでも ありません。
- チャンクに割る前に正規化する。引用符を直線に揃え、ソフトハイフンを除き、連続する 空行をまとめる。取り込み時に一度やっておけば、以降の工程がすべて楽になります。
- 固定文字数ではなく段落境界で割る。書籍にはきちんとした段落があり、それは自然な 意味の単位です。1,000文字で機械的に割ると文が真っ二つになり、断片の埋め込みができあがります。
- ファイル名をメタデータとして残す。すべてが一続きのテキストになった時点で、 書名と著者名だけが出所の手がかりです。チャンクごとに保存しておかないと、いい一節を引き当てても どの本のものか分からなくなります。
- トークン数を確認する。出力の下のカウンタが、その本の実際の数値を出します。 パイプラインを設計するのと当て推量するのとの差はここです。
同じ本ならPDFよりEPUBのほうが素材として上
同じ書名が両方の形式で手に入るなら、EPUBのほうが少ない手間できれいなテキストが得られます。PDFは 固定レイアウトで、見た目の1行ごとにグリフの並びが独立しています。そのため段落は短い行に割れて 届き、行末で分割された語は分割されたまま残り、柱とノンブルが数百語ごとに本文へ紛れ込みます。 PDFをテキストに変換 はそのすべてを処理しますが、あとから手で掃除することにはなります。
EPUBはリフロー型です。ページという概念がないのでページ周りの飾りもなく、段落はマークアップ上でも 本当に段落なので、正規表現で横断的に検索できる連続した行として出てきます。フレーズ検索、文分割、 埋め込みのいずれかが絡むなら、この差だけでも乗り換える価値があります。
よくある質問
EPUBをテキストに変換するには？
上のコンバータに .epub をドロップすれば、本文がプレーンテキストとして返ってきて .txt でダウンロードできます。無料、登録不要、1ファイル50 MBまで。EPUBは圧縮されたHTMLで、長編でも数MBを超えることはめったにないので、リフロー型の電子書籍には十分すぎる上限です。
KindleやApple Booksで買った本でも使えますか？
DRMのないものに限ります。購入した本はたいてい暗号化され、購入したアカウントに紐づいているので、暗号化されたファイルにはどのコンバータも到達できる読めるテキストがありません。Project GutenbergやStandard Ebooksのパブリックドメイン作品、暗号化なしで販売している出版社の技術書、自分で書き出したファイルは普通に変換できます。
出力で章は分かれたまま残りますか？
章の境界は流れの中の区切りとしては残りますが、章タイトルは見出しであることを示す印のない普通の行として出てきます。テキストへ平坦化する以上そうなります。あとから章単位でたどったりチャンクに割ったりしたいなら、EPUBをMarkdownに変換が見出しレベルを保ちます。
脚注や巻末注はどうなりますか？
出力には入りますが、参照記号のあった位置ではなく、元の節の末尾にまとめて現れるのが普通です。学術書では注の本文が章と章のあいだにずらりと並ぶことになります。読み飛ばすのは簡単ですが、埋め込み用にチャンクを作っていて「なぜこのチャンクは引用ばかりなのか」と悩まないためには知っておく価値があります。
この方法で本を丸ごとLLMに渡せますか？
変換自体は一度で終わりますが、貼る前にトークン数を確認してください。300ページの小説でおよそ120,000トークンです。200Kのコンテキストウィンドウには収まりますが、チャットの1メッセージが受け付ける量は明らかに超えています。出力の下のカウンタが、痛い目を見る前に数字を教えてくれます。
残りのツール
EPUBは対応13形式のうちの1つです。 File2Txt なら1回の アップロードで全部を扱えます。原稿なら Wordをテキストに変換、 古いリッチテキスト文書なら RTFをテキストに変換、 保存した記事なら HTMLをテキストに変換。 自前の構造化データは CSVをテキストに変換か JSONをテキストに変換を通します。
文書以外では、 GitHubリポジトリをテキストに変換したり、 GitLabプロジェクトや ローカルフォルダを変換したり、 Web2Txt で公開中のページをテキストとして取得したりできます。全体像を知りたい場合は、もう少し長い LLM向けに文書を準備するガイド があります。
Repo2Txt を作って運用しているのは v12hero、 プライバシー重視のネイティブアプリとWebアプリを手がける個人開発者です。