ZIP を テキスト にオンラインで無料で変換

オンラインで ZIP ファイルを テキスト に無料で変換します。ファイルをアップロードすると、クリーンで LLM 対応の出力が即座に得られます。サインアップなし、ファイルあたり 50 MB、何も保存されません。

ZIPの中身をテキストとして抽出し、検索できる一つのコーパスにまとめる

このツールが効くのは、かなり具体的な場面です。エクスポート、バックアップ、誰かが一式まとめて送ってきたアーカイブ。 中身は形式もばらばらな文書の山で、やりたいのは一本ずつ読むことではありません。全部をまとめて横断検索したい。 ある語が何回出てくるかを数えたい。丸ごと埋め込みモデルに流し込みたい。80本のうち特定の条項に触れている3本を 見つけたい。そういう用途です。

ZIPをアップロードすると、中の読めるものすべてを平坦なプレーンテキスト1本にして返します。見出しもパイプ記法の表も、 記法由来の記号も入りません。grepでき、インデックスでき、チャンクに切れ、そのまま貼れる素の文章だけです。無料、 アカウント不要、アーカイブは50 MBまで、出力を受け取った後には何も残しません。

アーカイブを1つ入れて、コーパスを1つ受け取る

アーカイブを展開し、中のツリーをたどり、対応拡張子のファイルはすべて単体でアップロードしたときと同じロジックで 変換します。それを連続したテキストとしてつなげて返します。アーカイブ内のフォルダパスは引き継がれるので、ある部分が exports/2023/ 由来なのか drafts/ 由来なのかは判別できます。ただし出力自体は平坦で均質、 機械的に処理しやすい形です。

効率の話はわざわざ説明するまでもありません。40本の文書を個別に変換すれば、アップロード40回、クリップボード操作 40回です。ファイルの一括テキスト変換としてまとめれば1回で済みます。しかも出力が1本にまとまるので、 後から継ぎ合わせる工程がありません。23本目を二度貼って24本目を飛ばした、といった心配もなくなります。

一括処理では平坦なテキストがMarkdownに勝つ理由

Markdownが効くのは、出力を人が読むときか、文書の構造そのものが意味を持つときです。アーカイブを丸ごと一度に扱う 用途では、そのどちらも当てはまらないことが多く、記法はただの重荷になります。

  • 埋め込みとRAGのパイプライン。 チャンカーが前提にしているのは素の文章です。パイプ記法の表や 見出し記号はチャンク境界で分断され、ベクトル1本あたりの意味的な信号を薄め、本来コンテンツに使うべき枠を 食います。取り込み側のコードはどのみち最初にMarkdownを剥がすことがほとんどなので、はじめから無い状態で 渡すほうが早いです。
  • 検索インデックスの構築。 何を食わせるにせよ、トークナイザが欲しいのはきれいな語です。記法の 記号はアナライザが捨てるだけのノイズになります。
  • キーワードと頻度の分析。 語の出現数、共起、TF-IDF、単純な正規表現の走査。いずれも装飾のない テキストのほうがきれいに出ますし、表の区切り記号が1トークンとして数えられる事故も起きません。
  • 重複排除と差分。 2つのアーカイブの変換結果を比べて何が変わったかを見るとき、書式が偽の差分を 持ち込まないぶん、はるかに楽になります。
  • トークン効率。 数十本の文書を通せば、構造用の記法は積み重なってコンテキストウィンドウの 無視できない割合を占めます。落とせば、その分だけ元資料を多く入れられます。

逆の条件なら ZIPをMarkdownに変換 の ほうへ切り替えてください。文書と文書の境目をはっきりさせたいとき、表や条項番号が効いてくるとき、あるいは結果を 自分で読むときです。上部の形式トグルで切り替えると選択済みのアーカイブもそのまま引き継がれるので、1回の アップロードから両方を作って、どちらが合うか見比べられます。

解凍せずに中身を確認できる形式と、できない形式

対応形式はツリーのどこにあっても変換されます。PDF、Word、PowerPoint、Excel、HTML、CSV、JSON、XML、EPUB、RTF、 MSG、画像。形式が混在したアーカイブはむしろ標準的なケースです。個々の形式が平坦化されたときにどう振る舞うかは、 PDFをテキストに変換、 Wordをテキストに変換、 CSVをテキストに変換、Outlookのメールなら MSGをテキストに変換 に書いてあります。

飛ばされるのは動画、音声、バイナリ、フォント、そして対応リストに載っていないものです。出力を見て驚く前に 知っておきたいケースが、あといくつかあります。

  • アーカイブの中の画像は読み取られません。 単体でアップロードした画像ファイルなら、写っている 文字を認識して返します。ZIPに入った状態ではそれをしません。一括処理はそのファイルの存在を記録して次へ進む だけなので、スクリーンショットやスキャン画像だけのアーカイブはエラーなく処理され、画像内の文字ではなく ファイル名が返ってきます。文字のほうが目的なら、画像を取り出して 画像をテキストに変換 に1枚ずつ通して ください。
  • スキャンPDFも同じ問題を抱えます。 実体が紙の写真であるPDFには、抽出できる埋め込みテキストが ありません。ビューアで一文を選択できるか試してみて、選択できないならZIPに固める前に文字認識をかけて ください。
  • 入れ子のアーカイブ。 ZIPの中にZIPがある場合は、アップロード前に手で1階層だけ展開しておく 価値があります。

平坦なコーパスが効いてくる場面

  • 大量の文書レビュー。 開示資料一式やデータルームのエクスポートで、最初の問いが「この文書を 読み上げて」ではなく「知りたい件に触れているのはどれか」であるようなケース。
  • ナレッジベースの構築。 社内ハンドブック、規程、業務手順書を一度に変換し、アシスタントが回答の 根拠にする正データとして検索システムに投入する。
  • サポート問い合わせのエクスポート。 数か月分のやりとりを平坦なテキストにして、傾向分析にかけたり、 繰り返し出てくる不満をモデルにクラスタリングさせたりする。
  • 研究用コーパス。 論文、レポート、データセットの入ったフォルダを1本のテキストにまとめ、1件ずつ 読むのではなく文書横断で分析する。
  • 移行時のコンテンツ棚卸し。 ドキュメント一式を新しい基盤へ移す前にアーカイブごと変換し、切れた 参照、古い製品名、重複ページを検索で洗い出す。
  • ワークスペースのエクスポート。 Slack、Notion、Takeoutのダウンロードは構造が雑で、入れ子の フォルダだらけです。平坦にして初めて扱えるようになります。

サイズ、順序、そして無理のない分割

50 MBの上限はアップロードするアーカイブ全体にかかり、中の個々のファイルにはかかりません。テキスト主体の文書は よく圧縮されるので、かなりの本数が収まります。逆にメディアはほとんど圧縮されず、何の役にも立たないまま枠を 食い潰します。ZIPに固める前に動画と大きな画像は外してください。

コーパスを区切りながら扱うつもりなら、フォルダ単位で分けてそれぞれ別のZIPにしてください。顧客ごと、四半期ごと、 案件ごとといった単位です。1回の出力が実際に貼れるサイズに収まり、関連する資料もまとまったままになります。判断の 基準になるのは出力の下に出るトークン数です。そのバッチがモデルのコンテキストウィンドウに収まるのか、分割が要るのかを、 痛い目を見る前に教えてくれます。

アーカイブの中身が文書ではなくソースコードのプロジェクトなら、代わりに ローカルディレクトリ変換 を使ってください。 フォルダをチェックボックスのツリーで見せるので、変換前に依存パッケージ、ビルド成果物、ロックファイルを外せます。 アーカイブのアップロードでは効かない種類の制御です。すでにホスティングされているコードならもっと簡単で、 GitHubをテキストに変換 はURLだけで動きます。

よくある質問

ZIPファイルの中身をテキストに変換するには？

上のフォームにアーカイブをアップロードしてください。展開して中のツリーをたどり、対応拡張子のファイルをすべて変換して、平坦なプレーンテキスト1本につなげます。無料、登録不要、アーカイブ1つあたり50 MB、保存は一切しません。アーカイブ内のフォルダパスは引き継がれるので、どの部分がどこ由来かが分かります。

解凍せずに変換されるのは、どのファイル形式ですか？

このサイトが単体アップロードで扱うのと同じ13形式です。PDF、Word、PowerPoint、Excel、HTML、CSV、JSON、XML、画像、EPUB、RTF、Outlookのメール、そして入れ子のアーカイブ。それ以外はバイナリのノイズとして吐き出すのではなく飛ばすので、文書に動画や実行ファイルが混ざった一式でもきれいな出力になります。

パスワード付きのアーカイブでも動きますか？

動きません。暗号化されたZIPはパスワードで復号するまで読めるエントリが1つもなく、そのパスワードを入力する場所もありません。手元でパスワードを使って展開してから暗号化なしで再圧縮するか、展開したディレクトリを ローカルフォルダ変換 に渡してください。

アーカイブが50 MBを超えています。どうすればいいですか？

フォルダ単位で分割して何回かに分けて変換するか、いっそアーカイブをやめてください。手元で展開して ローカルフォルダ変換 を使えば、アップロードの工程がないままツリー全体をたどり、どのファイルを含めるかをチェックで選べます。大量の文書をまとめて扱うなら、そもそもこちらのほうが向いています。

ZIPに固めたコードリポジトリにも向いていますか？

あまり向いていません。ソースコードなら GitHub変換 とローカルフォルダのツールがそのために作られています。ディレクトリツリーを表示し、node_modules やロックファイルのチェックを外せて、選びながらトークン数を数えます。このページが想定しているのは、刈り込むツリーが存在しない文書のアーカイブです。

ツールキットの残り

ページを選ぶのが面倒なら、File2Txt が 対応形式すべてを1ページで受け付けます。ここまでの理屈をまとめて読みたい場合は、 ファイルをLLM向けに 整えるためのガイド があります。

Repo2Txtを開発・運用しているのは v12hero、 プライバシー重視のネイティブアプリとWebアプリを作る個人開発者です。