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

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

XMLをMarkdownに変換する：タグは捨てて、階層は残す

XMLには他の形式にない癖があります。すべての要素の名前を2回書くことです。開くときに1回、閉じるときに もう1回。そこに名前空間プレフィックスと属性が乗り、読みやすさのためのインデントが加わると、タグの 分量が中身を上回るファイルが日常的にできあがります。200件の商品カタログが数千行に膨らんで、実際の 情報はページ1枚半ということも珍しくありません。

XMLをMarkdownに変換すると、ツリー構造は残り、儀式的な部分だけが落ちます。要素の ネストは見出しレベルになり、繰り返される兄弟要素は箇条書きか表になり、山かっこは消えます。上から .xml ファイルをアップロードすれば数秒で返ってきます。無料、登録不要、上限50 MB、 保存はしません。

要素ツリーが何に変わるか

変換処理は文書を上から歩きながら、構文ごとに次のように置き換えていきます：

  • コンテナ要素は見出しになります。子要素を持ち、自分自身はテキストを持たない要素は セクションです。ツリー内の深さがそのまま見出しレベルになるので、5階層の業務系スキーマも きちんとアウトライン化された文書として出てきます。
  • 末端要素はラベル付きの値になります。 <author>Ursula Le Guin</author> は author: Ursula Le Guin と読めます。名前は2回ではなく1回、かっこもなしです。
  • 繰り返す兄弟要素は箇条書きか表になります。ここに一番の価値があるので、 後ろで詳しく扱います。
  • 混在内容はインラインのまま保たれます。テキストと子要素が交互に現れるケース、 たとえば <para>詳しくは<ref>付録</ref>を参照</para> です。 素朴なコンバータはこれを断片に割ってしまい、文が失われます。参照を保ったまま、読める1行として 出てくるのが正しい挙動です。
  • コメント、処理命令、XML宣言は消えます。どれも本文ではありません。

属性：気づかないうちに落ちている部分

XMLはデータを2か所に持ちます。タグとタグの間と、タグの中です。要素テキストは目に見えます。属性は 見落としやすく、雑な抽出処理は黙って捨てます。id="4471" のようなメタデータなら それで構いません。中身そのものが入っている場合は事故です。

そして、それはよくあることです。<price currency="JPY">4980</price> は 通貨がなければ意味を持ちません。設定ファイル系はもっと極端で、Maven、Ant、Spring、Androidの マニフェスト、.NETの app.config はほぼすべてを属性に書きます。要素テキストしか見ない 抽出をかけると、構造だけ正しくて中身がほぼ空の文書が返ってきます。設定ファイルを変換して出力が 妙に短いと感じたら、理由はこれです。

Markdown出力では、属性は消えるのではなく、それが属する要素の隣に置かれるべきものです。値の横に短い 修飾として付くか、繰り返し集合の一部なら追加の列として出てきます。重要な用途に回す前に、出力の 最初の1画面をソースと突き合わせてください。10秒ざっと眺めておくほうが、あとでモデルと噛み合わない 会話をするより早く済みます。

繰り返す兄弟要素は表になる

XMLがいちばん得意な形は、親が同じ形の子を大量に抱えている構造です。RSSフィードの <item>、データベースエクスポートの <row>、人事データの <employee>。どの子も同じ下位要素を同じ順序で持っています。

これはMarkdownのパイプ表1つに畳めます。下位要素の名前が列見出しになり、レコードごとに1行が入り、 生ファイルではレコードごとに2回書かれていたフィールド名は、ヘッダに1回出てくるだけになります。 XML変換で得られる圧縮としては最大のもので、レコード状のデータならフラットなテキストではなく Markdownを選ぶ理由がここにあります。

崩れるのはレコードが不揃いなときです。一部の子にしかない省略可能な要素があったり、1つの子だけが 入れ子のブロックを抱えていたりすると、空欄ができるか、入れ子部分が表の下に押し出されます。 データが本当に矩形なら、CSVに書き出して CSVをMarkdownに変換するツール に通したほうがきれいな表になります。元データがタグ状ではなくJSON状なら、 JSONをMarkdownに変換するツール が同じ問題を反対側から扱います。

名前空間、エンベロープ、業務系のノイズ

現実のXMLはめったにきれいではありません。情報量に対してファイルを膨らませる要因は主に3つです：

  • 名前空間。xmlns 宣言と、soap:、xsi:、 atom:、dc: のようなプレフィックスは、語彙どうしの名前衝突を防ぐために あります。読む側にとっては何の意味もありません。変換の際にプレフィックスは外れるので、 <dc:creator> は creator と読めるようになります。 気にすべきなのは、2つの名前空間が本当に同じローカル名を別の意味で使っている場合だけです。 まれですが、語彙を混ぜているなら確認してください。
  • SOAPエンベロープ。Webサービスの応答は、欲しい部分を Envelope と Body で包み、たいていはセキュリティトークンやルーティング情報だらけのヘッダも 付いてきます。変換すると、頭の中で読み飛ばしていた定型の4階層下からペイロードがようやく 表に出てきます。
  • スキーマ参照。xsi:schemaLocation、DTD宣言、検証用の属性は、 そのファイルをどう検証するかを述べているだけで、何が書かれているかは述べていません。 ここでの用途すべてにおいてノイズです。

RSSとAtomのフィードは、この中では扱いやすいほうです。形が揃っていて浅く、日付付きエントリの きれいな一覧に変換できるので、ブログ1か月分をモデルに渡す手段としては妥当です。ただしフィードの description には、XMLの中でエスケープされたHTMLが入っているのが普通で、それは出力にマークアップの まま現れます。きれいにしたければ HTMLをMarkdownに変換するツール に通すか、Web2Txt でページ自体を取得してください。

生のXMLのまま渡したほうがいい場合

コンバータを売り込むページはたいてい言いませんが、はっきり書いておきます。モデルはXMLを普通に 読めます。冗長ではあっても曖昧さがなく、学習データにも極めて多く含まれています。変換は選択であって、 必須の手続きではありません。

そのまま渡すのは、XPath式、XSLTスタイルシート、パーサ、スキーマを書いてもらうとき です。正確な要素名、名前空間プレフィックス、属性と要素の区別をモデルが再現しなければならない場面 では、Markdownがまさにその情報をならしてしまいます。代表的な断片を実ファイルからそのまま貼って ください。

変換するのは、人が読む必要があるとき、見慣れないスキーマを手早く把握したいとき、 生ファイルがほぼタグでコンテキストに余裕がないときです。この3つは確実に効きます。それ以外は 好みの問題です。

XMLだと気づかれていないXML

バイナリだと思われている形式のかなりの数が、中身はzipされたXMLです。.docx を .zip にリネームして展開すれば、document.xml と関連ファイルの山が 出てきます。EPUBも同じで、XHTMLのコンテンツ文書とXMLのパッケージマニフェストがzipに入っています。 .pptx も .xlsx も同様です。

展開して中のXMLを手で変換することもできますが、やめてください。内部のマークアップはスタイルの ラン、変更履歴、レイアウト指示で埋め尽くされていて、本文がのみ込まれます。 WordをMarkdownに変換か EPUBをMarkdownに変換を 使ってください。そのXMLのどこが本文でどこが書式指示かを知っています。このページが対象にするのは、 最初からXMLとして渡されたXMLです。フィード、エクスポート、APIレスポンス、設定、データ交換。

よくある質問

XMLをMarkdownに変換するには？

上から .xml をアップロードすれば、文書構造がMarkdownに写されます。要素の階層は見出しレベルに、繰り返される兄弟要素は箇条書きか表になります。無料、1ファイル50 MBまで、登録不要。文書の形を保つ点が、テキストに平坦化する場合との違いです。

要素の階層は見出しレベルになりますか？

その対応でマッピングします。ネストが深い要素ほど深い見出しになります。DocBookやTEI、記事のエクスポートのように、ネストが本当に節の入れ子を表している文書型のXMLではうまく機能します。ネストがデータベーススキーマを反映しているデータ型のXMLでは相性が悪く、1レコードを説明するために見出しが12階層並ぶことになります。

名前空間プレフィックスはどうなりますか？

出力からは落とします。dc:title や tei:head という見出しは人に何も伝えず、モデルにはさらに伝えないので、プレフィックスは外してローカル名だけを使います。同じ文書内の2つの名前空間が同じローカル名を定義している場合は1つに畳まれます。まれですが、見出しが重複して見えるときは確認する価値があります。

DocBookやDITAの変換にも使えますか？

一次変換としては使えます。本文、節、箇条書き、インラインの強調は明示的にマークされているのでよく残ります。条件付きプロファイリング、コンテンツ参照、実体の取り込み、相互参照の解決は残りません。まさにその形式を採用する理由だった部分ですが、汎用のコンバータに解決できるものではありません。

大量のXMLコーパスにはどちらを選ぶべきですか？

多くの場合はテキストです。数千件のレコードにまたがる埋め込みを作るなら、見出し記法は検索性能に寄与しないままチャンクごとに繰り返されるオーバーヘッドです。Markdownが効くのは、人かモデルが1つの文書を読み通し、どこにどの節があるかを把握する必要があるときです。

プレーンテキストという選択肢と、残りのツール

構造がまったく要らない場合、つまり埋め込み用のテキスト、検索インデックス、あるいはトークン数を 最小にしたい場合は、XMLをプレーンテキストに変換 を使ってください。タグの間から中身を引き出し、それ以外は何も残しません。このページ上部の形式トグルで 両者を行き来でき、ファイルは読み込まれたままなので、両方の出力を比べるのはワンクリックです。 それぞれのコストは出力の下のトークンカウンタでわかります。

そのXMLがプロジェクト内の1ファイル、たとえば設定やビルド定義、フィクスチャであるなら、単体で 変換したものをモデルに渡しても、データだけあって周りのコードがない状態になります。 GitHubリポジトリをテキストに変換するツールや ローカルディレクトリコンバータなら、 XMLとそれを利用する側をまとめて取り込めます。たいていはそちらのほうが扱いやすい単位です。 File2Txt は対応形式すべてを 1か所で処理しますし、 LLM向けに ファイルを準備するガイドでは全般的な考え方を扱っています。

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