ADF不支持原生XML数据集，因其设计聚焦高吞吐结构化格式，而XML的嵌套、命名空间等特性难以统一建模；必须用Binary数据集间接处理，并在外接计算资源中解析。
XML 数据集在 Azure Data Factory（ADF）中不能直接作为源或目标使用——ADF 原生不支持
格式的数据集类型，所有 XML 文件必须通过通用格式（如
或
）间接处理，再配合自定义逻辑解析。
为什么 ADF 没有原生 XML 数据集
ADF 的数据集设计聚焦于高吞吐、可并行的结构化/半结构化格式（如
、
、
），而 XML 的嵌套深度、命名空间、混合内容、DTD/XSD 依赖等特性难以统一建模为 schema-on-read 流水线。官方明确将 XML 归类为「需自定义处理」场景，不提供
类型数据集选项。
用 Binary 数据集读取 XML 文件的实操要点
这是最常用且稳定的方式：把 XML 当作二进制流拉取，在后续活动（如 Databricks、Azure Function 或自定义 .NET 活动）中解析。
使用
或
，确保有读权限
数据集类型选
，不是
或
（后者会报错“Unsupported dataset type”）
在
数据集配置中，
可用通配符（如
），但
必须明确，不支持递归扫描（除非用
动态拼接）
若 XML 文件较大（>100 MB），避免在 Lookup 活动中直接读取——会触发内存溢出；改用
输出到临时 Blob，再交由下游解析
用 DelimitedText 数据集“伪装”简单 XML 的风险
仅当 XML 极其扁平（无嵌套、无属性、单根节点、每行一个标签）时，有人尝试设
为
或
，但这属于 hack 行为，极易断裂：
C知道
CSDN推出的一款AI技术问答工具
下载
任意含
的文本内容（如注释
）会导致列错位
XML 命名空间（
）和属性（
）完全无法识别
ADF 不校验 XML 合法性，解析失败会静默丢弃整行，而非报错
不推荐用于生产，调试成本远高于直接用
+ 显式解析
真正解析 XML 的推荐路径
ADF 本身不解析 XML，必须外接计算资源。常见组合：
Databricks Notebook（Python/Scala）：用
（需
包），支持 schema inference 和 namespace 处理
Azure Function（C#）：接收
数据集输出的 blob URL，用
或
解析后写入 SQL/ADLS
自定义 .NET 活动：上传已编译的 EXE，通过
的
传入文件路径和解析规则
关键点：所有解析逻辑必须独立于 ADF 数据集定义；
数据集只负责“搬运”，不承担“理解”职责。
最容易被忽略的是命名空间处理——90% 的 XML 解析失败源于未声明
前缀绑定，而不是语法错误。无论用 Spark 还是 .NET，都得显式调用
或
，ADF 自身对此零抽象。
XMLBinaryDelimitedTextParquetJsonAvroXmlLinked ServiceAzureBlobStorageAzureDataLakeStorageBinaryJsonXmlBinaryfileName*.xmlfolderPath@pipeline().parametersCopy ActivitycolumnDelimiter<><xmlns:ns="..."Binaryspark.read.format("xml")databricks-spark-xmlBinaryXDocument.Load()XmlSerializerActivityextendedPropertiesBinaryxmlnsSetPrefixXmlNamespaceManager