XML 转 Markdown：标签退场，层级留下
XML 有个别的格式都没有的习惯：每个元素的名字都要写两遍。开标签一遍，闭标签一遍。再加上 命名空间前缀、属性，以及为了可读而加的缩进，你会经常拿到一份标签比内容还重的文件。一份 200 个条目的商品目录能铺开几千行，实际信息量却只有一页半。
把 XML 转成 Markdown，留下的是树，扔掉的是排场。元素嵌套变成标题层级，
重复的同级元素变成列表或表格，尖括号消失。把 .xml 文件传到上方，几秒钟就能
拿回来——免费、免注册、上限 50 MB，什么都不保留。
元素树会变成什么
转换会遍历整个文档，逐一翻译每种结构：
- 容器元素变成标题。一个只有子元素、自己没有文本的元素，就是一个小节。它 在树里的深度决定标题级别，于是一个五层深的企业级 schema 转出来就是一份大纲清晰的文档。
- 叶子元素变成带标签的值。
<author>Ursula Le Guin</author>读起来就是 author: Ursula Le Guin。名字只写一遍，没有尖括号。 - 重复的同级元素变成列表或表格——下文单独讲，因为大头的价值就在这儿。
- 混合内容原样保留在行内。指的是文字和子元素交错的情况，比如
<para>See the <ref>appendix</ref> for details</para>。 简陋的转换器会把它拆成碎片，整句话就没了。正确的结果应该是一行可读的文字，引用完好地 嵌在里面。 - 注释、处理指令和 XML 声明去掉。它们都不是内容。
属性：最容易在不知不觉中丢掉的部分
XML 把数据存在两个地方——标签之间，和标签内部。元素文本一目了然。属性却容易被忽视，很多
简陋的提取方案会悄悄把它们丢掉。当属性只是 id="4471" 这类元数据时无伤大雅；当
属性本身就是数据时，那就是灾难。
而这很常见。<price currency="GBP">49.99</price> 丢了币种就毫无意义。
配置类格式更糟——Maven、Ant、Spring、Android 清单文件和 .NET 的 app.config
往往把几乎所有东西都放在属性里，只提取元素文本的话，出来的文档结构上没错，内容上几乎全空。
如果你转了一个配置文件、输出短得可疑，原因就在这里。
在 Markdown 输出里，属性应该留在所属元素的旁边而不是消失——要么作为值旁边的简短限定语， 要么在元素属于重复集合时变成额外的表格列。把输出的第一屏和源文件对一对，再拿去干正事。花 十秒扫一眼，胜过之后和模型鸡同鸭讲。
重复的同级元素变成表格
XML 最理想的形态是一个父元素带着许多结构相同的子元素：RSS 源里的 <item>、
数据库导出里的 <row>、人事系统转储里的 <employee>。每个
子元素都有同样的子字段、同样的顺序。
这种结构会坍缩成一张 Markdown 竖线表格。子元素名变成表头，每条记录变成一行，而标签的重复 ——原始文件里每条记录的每个字段名都要写两遍——现在只在表头出现一次。这是所有 XML 转换里 降幅最大的一项，也是任何记录型数据该选 Markdown 而不是纯文本的理由。
当记录参差不齐时效果会打折——可选元素有的记录有、有的没有，或者某条记录里嵌着别的记录没有 的子块。你会看到空缺，或者嵌套部分被挤到表格下方。如果你的数据本来就是规整的矩形，导出成 CSV 再用 CSV 转 Markdown 转换器 能得到更干净的表格。要是数据源长得像 JSON 而不是标签， JSON 转 Markdown 转换器 从另一个方向解决同一个问题。
命名空间、信封和企业级噪音
现实中的 XML 很少干净。有三样东西把它撑得远超其信息量：
- 命名空间。
xmlns声明和soap:、xsi:、atom:、dc:这类前缀，存在的意义是防止不同词汇表之间撞名。对读者 毫无意义。转换时前缀会被剥掉，<dc:creator>读起来就是 creator。 唯一需要在意的情形，是两个命名空间真的用同一个本地名表示不同的东西——罕见，但合并词汇表 时值得查一下。 - SOAP 信封。Web 服务的响应把你要的部分包在
Envelope和Body里，往往还外加塞满安全令牌和路由数据的头部。转换之后，载荷终于摆在 明面上，而不是埋在四层你得在脑子里跳过的样板底下。 - Schema 引用。
xsi:schemaLocation、DTD 声明和各种校验属性描述 的是文件应该怎么被校验，不是文件说了什么。在这里的所有用途下都是噪音。
RSS 和 Atom 源属于这条谱系里友好的一端。它们规整、扁平，转出来是一份带日期的条目清单—— 把博客一个月的文章递给模型，这是个说得过去的方式。注意：源里的描述通常包着转义在 XML 里的 HTML，到你的输出里会以标记形式出现；想要干净的话，把它过一遍 HTML 转 Markdown 转换器， 或者干脆用 Web2Txt 把网页正经抓一遍。
什么时候该保留原始 XML
直说了吧，毕竟很多卖转换器的页面不肯直说：模型读 XML 读得很好。它啰嗦，但没有歧义，训练 数据里也极其常见。转换是一种选择，不是必需。
保留原始文件的场合：你在让模型写 XPath 表达式、XSLT 样式表、解析器或 schema——凡是要求模型复现精确元素名、命名空间前缀以及属性与元素之分的任务。Markdown 有意 抹平的恰恰是这些细节。这时应该直接贴一段有代表性的真实文件。
转换的场合：需要人来读，想快速摸清一个陌生 schema，或者原始文件基本全是 标签而你的上下文窗口很紧。这些是实打实的收益。其余情况全看个人偏好。
那些你没意识到是 XML 的 XML
不少你以为是二进制的格式，底子其实是打包成 zip 的 XML。把 .docx 改名成
.zip 解开，里面是 document.xml 加一堆关系文件。EPUB 也是同一个
故事：zip 里装着 XHTML 内容文档和一份 XML 包清单。.pptx 如此，.xlsx
也如此。
你当然可以手动解压、把里面的 XML 拿来转。别这么干——内部标记里全是样式片段、修订跟踪和 排版指令，正文会被淹没。请用 Word 转 Markdown或 EPUB 转 Markdown， 它们知道那堆 XML 里哪些是内容、哪些是排版指令。本页服务的是以 XML 身份交到你手上的 XML： 订阅源、导出、API 响应、配置、数据交换。
常见问题
怎么把 XML 转成 Markdown？
把 .xml 传到上方，文档结构就会映射到 Markdown 上——元素层级变成标题级别，重复的同级元素变成列表或表格。免费，单文件 50 MB，免注册。它保留文档的形态，这正是它和压平成纯文本的区别。
元素层级会变成标题级别吗？
对，映射关系就是这样——嵌套越深，标题级别越深。对文档形态的 XML 很好使，比如 DocBook、TEI 或文章导出，那里的嵌套真的对应章节套小节。对数据形态的 XML 就不灵了：嵌套反映的是数据库 schema，你会得到十二级标题来描述一条记录。
命名空间前缀会怎么处理？
输出里会被去掉。一个写着 dc:title 或 tei:head 的标题对人毫无信息量，对模型更少，所以前缀被剥掉，只留本地元素名。如果同一份文档里两个命名空间定义了相同的本地名，它们会合并到一起——罕见，但标题看着像重复时值得查一眼。
拿来转 DocBook 或 DITA 有用吗？
作为第一遍粗转，有用。散文、章节、列表和行内强调都能顺利过来，因为这些格式对它们有显式标记。条件化输出、内容引用、实体包含和交叉引用解析则活不下来——而这些恰恰是当初值得用这种格式的原因，任何通用转换器都解析不了。
大规模 XML 语料该选哪种？
多数情况选文本。如果你要对几千条记录做 embedding，标题语法就是每个块上重复出现的开销，对召回毫无帮助。Markdown 的价值在于有人或模型要通读一份文档、需要知道章节在哪的时候。
改要纯文本，以及全家桶的其余部分
如果你完全不要结构——给 embedding、搜索索引用的文本，或者追求最低 token 数——用 XML 转纯文本，它把内容 从标签之间抽出来，别的什么都不留。本页顶部的格式切换按钮可以在两者之间来回切，并保持文件 已加载，两种输出对比只要一次点击。输出下方的 token 计数器告诉你各自的开销。
如果这份 XML 是项目里的一个文件——配置、构建描述、测试夹具——单独转换等于把数据递给模型 却抽走了周围的代码。 GitHub 仓库转文本转换器和 本地目录转换器能把 XML 和 使用它的代码一起打包，那通常才是更有用的单位。 File2Txt 在一个页面里 处理所有支持的格式， 为 LLM 准备文件的指南讲的是通用原则。
Repo2Txt 由 v12hero 开发和维护，那是一位独立开发者，专做隐私优先的原生应用和 Web 应用。