免费在线将 XML 转换为 文字

免费在线将 XML 文件转换为 文字。上传后立即获得干净、适合 LLM 使用的结果。无需注册，单个文件最大 50 MB，不会存储文件。

XML 转文本：把内容从尖括号里捞出来

搭建文本语料库时总会碰到这样一种文件：一份内容其实很有价值的 XML 导出——期刊摘要、庭审记录、 数字化档案、十年份的博客文章——可你要的那些文字，被埋在某个 2006 年设计出来的 schema 底下。 字都在里面，只是外面裹着三层带命名空间前缀的标签。

本页做的事就是把内容抽出来，只给你文字本身。没有标题，没有表格，没有任何标记。当目的地是 embedding 模型、搜索索引、NLP 脚本，或者任何把标点当噪音处理的流水线时，这正是你想要的。 把 .xml 文件拖到上方即可——免费、免注册、单文件上限 50 MB，什么都不保存。

转出来的到底是什么

提取远不止"删掉 < 和 > 之间的一切"。有几件事必须处理到位， 否则输出会悄悄出错：

  • 实体引用会被解码。XML 里不能出现裸的 & 符号，所以真实文档里到处是 &amp;、&lt;、&quot;，以及像 &#8217; 这样表示弯引号的数字形式。不解码的话，它们会污染词频统计、让检索 匹配不上。解码之后，它们变回各自代表的字符。
  • CDATA 区块会被拆开。<![CDATA[ ... ]]> 是 XML 夹带含标记 内容的手段——RSS 描述里的 HTML、一段 SQL、一块 JavaScript。外壳去掉，内容留下。
  • 纯空白的文本节点会被丢弃。格式化过的 XML 在每对标签之间都有一个只含换行 和空格的文本节点。留着它们，你的输出里六成都是空行。
  • 元素名会彻底消失。和 Markdown 版不同，这里不会把标签名保留成标签。你拿到 的是值，不是 schema。
  • 注释、XML 声明、DTD 和处理指令统统去掉。它们都不是内容。

词语粘连这个坑，以及它为什么重要

大多数简单粗暴的去标签方案——包括论坛上抄来的各种正则——都栽在这个失败模式上。看一段混合 内容，也就是文字和子元素交错在同一个父元素里：

<p>See the <ref>appendix</ref> for details</p>

随手把标签删掉，得到的可能是"See theappendixfor details"——被你删掉的那个标签，本来还兼任 词与词之间的边界。反过来，在每个标签处都插一个换行，一句话就被剁成三行三段。两种结果都没法 用：前者毁掉分词，后者毁掉分句，而且都会悄无声息地污染下游一切默认自己在读散文的环节。

正确的做法是让行内元素留在行内，只在真正的块级边界处换行。如果你在用别的工具做 XML 文件文本提取，这就是第一个该测的点——找一个中间夹着行内标签的段落， 看看那句话是否完好无损。

配置文件的问题

接下来是实话实说的部分，能替你省下摸不着头脑的五分钟。XML 把数据放在两个地方：标签之间， 以及标签内部的属性里。文本提取按定义只拿第一种。而有一大类很常见的 XML，第一种几乎为零。

Android 清单文件、.NET 的 app.config、Ant 构建文件、Spring 的 bean 定义、许多 SVG——这些几乎把所有东西都塞在属性里。拿一个过一遍文本提取器，出来的是零星几个词，甚至一个 空文件，看着像工具坏了。工具没坏，是文件里本来就没有元素文本可提。

遇到这类文件，请改用 XML 转 Markdown 转换器， 它会把属性留在它们所修饰的元素旁边。本页顶部的格式切换按钮可以直接切过去，而且会带着你已选 好的文件，一次点击就行，不用重新上传。经验法则：散文住在元素里，设置住在属性里。 文本提取管的是前一种。

扁平文本明显是正解的场合

XML 是海量精心整理的文本的原生格式，很大程度上是因为各种机构在 JSON 出现之前就把它定成了 标准。这份遗产正是这个转换器的用武之地：

  • 构建语料库。学术摘要转储、TEI 编码的文学文本、议会与司法记录、博物馆和 图书馆目录。全是优质散文，全裹在厚重的 schema 里。你要的是散文。
  • embedding 与向量检索。把原始 XML 块直接向量化，向量里有一部分实实在在 描述的是标记而不是语义——两份主题毫不相干的文档，可能只因为共用一个 schema 就在向量空间 里挨在一起。剥掉标签，向量才是关于内容的。
  • 切块。定长切块器会把原始 XML 从元素中间切开，产生带着孤立标签的碎片。 扁平文本按句子和段落边界切分，这才是切块器的设计前提。
  • 搜索索引与文本分析。词频、情感打分、主题建模、实体抽取——每条记录上重复 出现的结构性 token 会把这些全部带偏。
  • token 经济账。即便在结构化格式里，XML 的冗长也算突出，因为每个元素名都 要写两遍。把一份嵌套很深的导出剥掉标签，能去掉大量从未承载过信息的 token。输出下方的 计数器会精确告诉你省了多少。

什么时候不该剥标签

模型读原始 XML 毫无困难——啰嗦归啰嗦，但它没有歧义，训练数据里也多得是。转换是一个有理由 才做的决定，不是规矩。

  • 要针对这份文档写代码。XPath 查询、XSLT 样式表、SAX 或 DOM 解析器、 schema——这些全都需要精确的元素名、命名空间前缀，以及属性与元素的区分。文本提取删掉的 恰恰就是这些。这种时候直接贴一段真实文件。
  • 层级本身就是答案。如果问题是某个东西挂在哪个父节点下——某项设置属于哪个 环境、某个条款在哪一节——扁平化会把答案毁掉。那是 Markdown 的活儿。
  • 属性密集的文档，如上所述。

常见问题

怎么把 XML 文件转成文本？

把 .xml 拖进上方的转换器，标签之间的内容就会以纯散文的形式返回——没有尖括号，没有命名空间前缀，没有属性。可下载为 .txt。免费、免注册、单文件 50 MB，什么都不保留。

它会解码 &amp; 和 &lt; 这类实体吗？

会，而且这件事比听上去重要。XML 里不能出现裸的 & 符号，所以真实文档里密密麻麻全是 &amp;、&lt;、&quot; 和数字字符引用。简陋的去标签正则会把这些原样留在输出里。正规解析会把它们还原成所代表的字符。

为什么不干脆用一条正则删掉尖括号之间的所有东西？

因为 CDATA 区块和属性值里都有长得像标记但不是标记的字符。正则会毫不客气地吃掉 <![CDATA[...]]> 块里嵌着的 HTML，也分不清一个真正的标签和引号包着的属性文本里出现的 <。解析能把这些处理对；模式匹配则悄悄出错。

属性值会出现在结果里吗？

你拿到的是元素文本；属性是关于元素的元数据，不算元素的内容。通常这是对的——你要的是摘要，不是 schema 版本号。会踩坑的是那些把真正内容存在属性里的格式，所以如果输出薄得可疑，打开源文件看看你要的那些字是不是住在 <tag attr="..."> 里面。

RSS 订阅源和 sitemap 能用吗？

能——两者都是 XML，都能转。RSS 源转出来是可读的标题、描述和日期，是从博客存档快速攒语料的捷径。sitemap 转出来是一串 URL，与其当散文读，不如接着管道送去别处更有用。

相关工具

顺带说说你会间接遇到的 XML：.docx 和 .epub 的内里就是打包成 zip 的 XML。你可以解包后把内部标记喂到这里——但别这么干，那里面浸满了样式片段和修订元数据，正文全被 淹没。请用 Word 转文本或 EPUB 转文本，它们知道 哪些部分是内容。若标记是 HTML 而非 XML，有 HTML 转文本；另一大 结构化数据格式则有 JSON 转文本。 懒得挑页面的话，File2Txt 接受所有支持的格式。

而当 XML 躺在代码仓库里——POM 文件、构建描述、测试夹具——单独转换它就等于剥掉了上下文。 GitHub 仓库转文本转换器、 GitLab 转换器和 本地目录转换器能把 XML 和 读取它的代码合成一份输出，这几乎总是更有用。 为 LLM 准备文件的指南讲的是通用的那一套。

Repo2Txt 由 v12hero 开发和维护，那是一位独立开发者，专做隐私优先的原生应用和 Web 应用。