HTMLをMarkdownに変換する必要に迫られたことはありませんか？
Webスクレイピングで取得したコンテンツを整形したり、ドキュメント管理システムでフォーマット変換を行ったり。
こうした場面は意外と多いものです。
最近、Redditでhtml-to-markdown v2のリリースが発表されました。
この新バージョンは従来のPython実装をRustで書き直したものです。
そして、驚異的なパフォーマンス向上を実現しています。
本記事では、このライブラリの特徴と、なぜ注目に値するのかを解説していきます。
Python実装の限界とRustへの移行
html-to-markdownは、元々markdownifyというPythonライブラリのフォークとして始まりました。
開発者は型ヒントが必要だったため、フォークを作成したそうです。
しかし、開発を進めるうちに全面的な書き直しを行うことになります。
従来のv1では、BeautifulSoupを使用したPython実装でした。
多くのPythonエンジニアにとって馴染み深いアプローチです。
ただし、この実装には課題がありました。
大量のドキュメントを処理する際のパフォーマンスとメモリ使用量です。
そこで開発者は思い切った決断をしました。
コアロジックをRustで書き直したのです。
そして、Pythonバインディングを提供する形にしました。
パフォーマンスの劇的な向上
数字を見てみましょう。
v2では、実際のWikipediaドキュメントを使ったベンチマークが公開されています。
Apple M4上での結果がこちらです。
| ドキュメント種類 | サイズ | レイテンシ | スループット |
|---|---|---|---|
| タイムライン記事 | 129KB | 0.62ms | 208MB/秒 |
| 国のリスト記事 | 360KB | 2.02ms | 178MB/秒 |
| Python Wiki記事 | 656KB | 4.56ms | 144MB/秒 |
v1の平均スループットは約2.5MB/秒でした。
それと比較すると、60倍から80倍の性能向上です。
これは単なる最適化の範囲を超えています。
アーキテクチャの根本的な変更がもたらした成果といえるでしょう。
CommonMark準拠と実用的な機能
パフォーマンスだけではありません。
v2はCommonMark 0.31.2の仕様テストに準拠しています。
デフォルトの動作がCommonMark標準に沿っているため、予測可能な出力が得られます。
インライン画像の抽出機能も追加されました。
convert_with_inline_images関数を使えば、Data URIやインラインSVGを自動的に抽出できます。
サイズ制限やクォータ制御も可能です。
したがって、安全に画像を扱えるでしょう。
hOCR 1.2仕様への対応も見逃せません。
hOCRは、OCRソフトウェアが出力するHTML形式のデータフォーマットです。
テキストの位置情報や信頼度、構造情報などが含まれています。
このライブラリは、hOCR形式のHTMLをMarkdownに変換できます。
OCRで読み取った文書を扱うエンジニアにとって、これは大きな前進です。
特に重要なのは、hOCR内のテーブル構造を正確に再構築できる点でしょう。
OCRで読み取った表データは構造が複雑になりがちです。
しかし、このライブラリなら適切にMarkdownのテーブルとして出力できます。
また、YAMLフロントマターでOCRのメタデータを保持します。
つまり、スキャンした文書から抽出された構造化情報を失わずに、扱いやすいMarkdown形式に変換できるのです。
メモリ管理にも配慮されています。
数メガバイトのドキュメントを繰り返し処理しても、RSS（常駐セットサイズ）は200MB以下に抑えられるそうです。
既存ライブラリとの位置づけ
他のライブラリと比較してみましょう。
markdownifyは、html-to-markdownの前身です。
APIの互換性が維持されているため、移行は比較的スムーズでしょう。
v2ではhtml_to_markdown.v1_compatモジュールが用意されています。
ただし、性能面では比較になりません。
html2textも人気のある選択肢です。
クイックスクリプトには十分でしょう。
しかし、CommonMark準拠ではありません。
複雑なテーブルやOCRレイアウトの処理では課題が残ります。
長時間稼働するプロセスでは、メモリ割り当てが問題になることもあるでしょう。
Pandocは非常に柔軟で強力です。
しかし、純粋なHTML→Markdown変換だけなら、やや重量級といえます。
Pythonから使う場合、サブプロセスを介する必要があるのも欠点です。
html-to-markdown v2はスリムなRustコアを持ちます。
そして、直接バインディングで呼び出せます。
誰が使うべきか
このライブラリは、以下のような用途に適しています。
大量のドキュメント処理
バッチジョブでBeautifulSoupベースの変換器が遅すぎて困っていませんか？
検討する価値があります。
OCR出力の処理
hOCR対応が必要なら、このライブラリが力になります。
マルチプラットフォーム対応
Python、Rust、CLIの各環境で同じMarkdown出力が必要なプロジェクトに向いています。
一貫性が重要な場面で力を発揮するでしょう。
厳密なメモリ管理
並列処理と厳密なメモリ管理が求められるドキュメント理解スタックで使えます。
kreuzbergエコシステムの一部としても採用されています。
実装上の注意点
投稿へのコメントでは、WebAssemblyへのコンパイルを求める声もありました。
開発者は検討中のようです。
実現すれば、より幅広いデバイスで使えるようになるでしょう。
まとめ
html-to-markdown v2は、HTMLからMarkdownへの変換における大きな前進です。
Rustによる書き直しで、パフォーマンスは従来の60倍から80倍に向上しました。
CommonMark準拠、インライン画像抽出、hOCR対応といった実用的な機能も充実しています。
既存のmarkdownify APIとの互換性を保ちながら、現代的な要求に応える設計になっているのです。
大量のドキュメント処理やOCR出力の扱いに課題を感じているなら、試してみる価値があるでしょう。
GitHubリポジトリで詳細を確認できます。
テキスト処理の効率化は、開発生産性に直結します。
適切なツールを選ぶことで、より本質的な問題に時間を使えるようになるのです。
