ZIP を Markdown にオンラインで無料で変換

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

ZIPをMarkdownに一括変換:アップロード1回でアーカイブまるごと

文書を1つずつ変換するのは、20個になるまでは我慢できます。そこからは20回のアップロード、20回の待ち時間、 20回のコピー&ペーストで、14個目あたりでどれを済ませたのか分からなくなります。このページが取り除くのは、 まさにその問題です。

フォルダをZIPに圧縮して、その1つのアーカイブをアップロードしてください。中の対応文書はすべて一度の処理で 変換され、各ファイルの構造を保ち、隣のファイルとはっきり区切られたMarkdownになって返ってきます。 ファイルアップロードの皮をかぶったバッチ処理です。ほかのツールと同じく無料で、登録不要、上限50MB、 処理後には何も残しません。

アーカイブに実際に起きること

アーカイブは展開され、中のファイルツリーが上から下へたどられ、対応する拡張子を持つファイルはすべて、 単体の専用ページでアップロードした場合とまったく同じ変換を通ります。ZIPの中のPDFは直接アップロードした PDFとまったく同じ扱いです。スプレッドシートは表になり、スライド資料はスライドごとのセクションになります。 その結果が縫い合わされて、1つのMarkdown文書になります。

思われている以上に重要な点が2つあります。第一に、アーカイブ内のフォルダ構造は文脈として 保存されます2024/q3/board-pack.pdfarchive/old/board-pack.pdfが 別の場所から来たことが分かるということで、ファイル名がディレクトリをまたいで重複するとき——そして必ず 重複します——これが決定的に効きます。第二に、アーカイブは平らな山に均されるのではなく、その場の 構造のまま展開されます。誰かがファイルを整理したときに作った階層はそれ自体が情報であり、捨てて しまえば出力について推論するのが難しくなります。

形式が混在したアーカイブは、例外ではなく普通のケースです。PDFが4つ、Word文書が2つ、スプレッドシートと PowerPointの資料が1つずつ入ったZIPは一度に変換され、各ファイルはそれぞれの形式にふさわしいロジックで 処理されます。

変換されるもの、スキップされるもの

単体アップロードで変換できるものは、アーカイブの中でも変換できます。PDF、DOCX、PPTX、XLSXとXLS、HTML、 CSV、JSON、XML、EPUB、RTF、MSG、そして画像です。特定の形式が具体的にどう振る舞うかは、個別ページが 詳しく説明しています。 PDFをMarkdownに変換WordをMarkdownに変換PowerPointをMarkdownに変換ExcelをMarkdownに変換の4つで、 仕事のアーカイブに入っている定番はほぼカバーできます。

素通りされるのは、差し出すテキストを持たないものすべてです。動画、音声、フォント、コンパイル済みバイナリ、 インストーラー、対応リスト外の独自形式は何も寄与しないので、そのまま放置されます。注意すべきは画像で、 ここで引っかかる人が多い。単体でアップロードした画像はきちんと読まれ、スクリーンショットや撮影したページの 文字はテキストになって返ってきます。ところがアーカイブの中では読まれません。バッチ処理はファイルの存在を 記録して先へ進むので、スクリーンショットのZIPは「正常に」変換され、画面に写っていた言葉の代わりに ファイル名の一覧が手に入ります。その言葉こそが目的なら、画像を取り出して 画像をMarkdownに変換に 直接かけてください。

もう1つ確認すべきなのが入れ子のアーカイブ——ZIPの中のZIPです。エクスポートが「アーカイブのアーカイブ」で 届いたなら、自分で1段展開して中身をZIPし直してからアップロードしてください。2分の下ごしらえで、出力は はるかによくなります。

一括変換ならMarkdownが正解になる理由

文書が1つなら、Markdownかフラットなテキストかは判断の分かれる問題です。1つの出力に20の文書となると、 勝負になりません。

理由は境界です。複数のファイルを1つのテキストに連結したとき、人間にとってもモデルにとっても最も難しいのは、 どこで1つの文書が終わり次の文書が始まるのかを知ることです。Markdownの見出しはそれをただで与えてくれます。 各ファイルが自分の名を名乗り、その下のすべてが目に見えてそこに属します。「この中で解約予告期間が最短の 契約書はどれ?」と聞けば、モデルは文書ごとに答えられます。3つの契約書の条項を混ぜ合わせて、自信たっぷりの 間違った答えを1つ返す代わりに。

ファイルごとの構造も生き残ります。スプレッドシートの表は表のまま、スライドは独立したセクションのまま、 レポートの条項番号もそのままです。生のテキストではなくMarkdownへの一括変換を選ぶ理由は これに尽きます。構造こそが、複数文書のコンテキストを「ただ大きい」ではなく「たどれる」ものにします。

例外は一括分析です。埋め込み、検索インデックス、コーパス全体のキーワード調査——平らな散文の山が1つ欲しくて、 構文記号がノイズになる用途です。それなら ZIPをテキストに変換で、ページ上部の 切り替えは選択済みのアーカイブを保持したままそちらへ移れます。

実際にアップロードされているアーカイブ

  • メール添付の詰め合わせ。「レビュー用の資料一式」が9個の添付をまとめたZIPで届く。 まとめて変換し、要約を読み、本当にきちんと開くべき2つを決める。
  • データエクスポート。Google Takeout、Slackワークスペースのエクスポート、Notionの ダンプ、サポートデスクのエクスポートは、どれも入れ子フォルダだらけのアーカイブで届きます。1時間 クリックし続けるはずだったディレクトリツリーが、一度の処理で読めるものになります。
  • 講義資料のパック。1モジュールぶんのスライド、配布資料、読書リストを1回のダウンロードで。 変換してから、モデルの一般知識ではなく実際の教材にもとづく学習ガイドを作らせる。
  • クライアントの引き継ぎとデューデリジェンス資料。データルームのエクスポート、ベンダーの 文書一式、プロジェクトの引き継ぎフォルダ——全体が1ステップで検索できるテキストになり、フォルダパスが 各文書の出どころを教えてくれます。
  • 助成金申請や入札書類。付属書付きの複数文書からなる応募書類で、別々の人が書いた ファイル間の整合性を確認する必要がある場合。
  • 個人のアーカイブ。中身を思い出せない昔のバックアップフォルダ。まず変換、掘るのはその後。

50MBの上限と、その下でやりくりする方法

上限が適用されるのはアップロードするアーカイブ全体であって、中の個々のファイルではありません。これはたいてい 余裕のある枠です。ZIPはテキスト中心の形式をよく圧縮するので、Word文書とスプレッドシートのフォルダは劇的に 縮み、ファイル数の多いアーカイブでも余裕で収まることが多いのです。

上限を吹き飛ばすのはメディアです。動画、音声、高解像度の画像はほとんど圧縮が効かず、出力には何も寄与しない まま容量だけを食い尽くします。アーカイブが上限を超えるなら、それらを抜いてZIPし直してください。使う予定の なかったものしか失いません。本当に大きな文書群は、フォルダ単位で2〜3個のアーカイブに分けて順番に変換して ください。

もう1つ見張るべき枠が、出力の下のトークンカウンターです。50個の文書は問題なく変換できますが、それでも 小さいモデルのコンテキストウィンドウには収まりません。貼り付ける前に数字を知るほうがエラーで知るよりよく、 バッチ全体を送るか、分割して進めるかの判断材料にもなります。

そのZIPの正体がコードプロジェクトなら

よくあることなので、はっきり書いておきます。リポジトリやソースフォルダをZIPしたのなら、このツールは 間違いです。代わりにローカルフォルダ変換を 使ってください。フォルダをマシンから直接読み込み、ファイル構造をチェックボックスのツリーで表示し、出力に 入れるファイルを正確に選ばせてくれます。つまりnode_modules、ビルド成果物、ロックファイルを、 コンテキストウィンドウを食い尽くされる前に外せるということです。中身の見えないアーカイブ変換には できない芸当です。

プロジェクトがすでにどこかにホストされているなら、ZIP化そのものを飛ばしてください。 GitHubリポジトリをテキストに変換が URLから直接ツリーを取得します。

よくある質問

ZIPアーカイブをMarkdownに一括変換するには?

上にアップロードすると、中の対応ファイルがそれぞれMarkdownに変換されて連結され、アーカイブのフォルダパスが見出しとして残ります。無料、1アーカイブ50MB、アカウント不要。結果は1つの.md文書で、どのセクションがどのファイル由来かが見えたままです。

ファイルパスは見出しになりますか?

なります。それこそが、アーカイブでフラットなテキストではなくMarkdownを選ぶ理由です。各ファイルの内容はZIP内のパスを名乗る見出しの下に置かれるので、出力はたどれるままで、特定の文書について聞かれたモデルは文脈から推測する代わりに、その場所を特定できます。

入れ子のアーカイブは処理されますか?

ZIPの中のZIPは、もう1つの対応ファイルとして扱われ、順に展開されます。年間アーカイブの中に月別アーカイブを束ねたエクスポートには便利です。ただし深すぎる入れ子は避けたほうがよいでしょう。出力は長くなり、見出しレベルは6で底を突き、それより深い構造は表現されなくなります。

ファイルはどんな順序で出てきますか?

ディレクトリの走査順です。つまりファイルは重要度ではなくフォルダごとにまとまります。意味のあるレイアウトを持つアーカイブなら、それがまさに正しい順序です。生成された名前を持つ200ファイルの平らなダンプなら順序は事実上ランダムなので、上から読むのではなく出力を検索することになるでしょう。

中のファイル数に制限はありますか?

実際の制約はファイル数ではなくアーカイブ50MBの上限ですが、出力の下のトークンカウンターには目を配ってください。数百の文書は、たいていのモデルのコンテキストウィンドウを何倍も超えます。どこにも貼り付けられないコーパスを作るより、必要な一部だけを変換するほうが得策なことが多いのです。

ツールキットの残り

ページを選ぶのが面倒なら、File2Txtが 対応13形式すべてを1か所で扱います。そして LLM向けにファイルを整える方法のガイドが、 プロンプトの前に変換しておくべき理由をより広い視点から論じています。

Repo2Txtを開発・運営しているのは v12hero、 プライバシー最優先のネイティブアプリとWebアプリを作る独立系デベロッパーです。