在ADFv2中使用复制活动解压Zip文件时保留Content-Type

核心原因 #

ADF默认解压Zip时，不会读取原文件的Content-Type元数据，统一将解压后文件的Content-Type设为application/octet-stream；当前UI未暴露保留元数据的配置项，手动修改JSON后配置被移除是因为活动的JSON schema校验会过滤未在UI中开放的属性。

纯ADF内可行解决方案 #

方案1：二进制复制模式+自定义元数据映射 #

1. 将源（Zip文件）和目标（Blob存储）数据集的格式均设置为Binary。
2. 在复制活动的映射标签页中，添加自定义元数据映射：
   • 源列选择ItemName（解压后的文件名）
   • 目标元数据键设为Content-Type
   • 使用表达式生成器根据文件后缀匹配对应MIME类型，示例表达式：

     @switch(split(item().name, '.')[sub(length(split(item().name, '.')),1)],
     'html', 'text/html',
     'css', 'text/css',
     'js', 'application/javascript',
     'png', 'image/png',
     'jpg', 'image/jpeg',
     'application/octet-stream')
     

   可根据实际需要的文件类型扩展switch分支。
3. 保存并运行管道，解压后的文件会自动设置对应Content-Type。

方案2：绕过UI限制启用保留元数据功能 #

若需使用ADF原生的保留元数据功能，需通过JSON导入方式绕过UI校验：

1. 导出管道的JSON定义到本地文件。
2. 在复制活动的sink配置节点中添加preserveMetadata属性，示例片段：

   "sink": {
       "type": "AzureBlobStorageSink",
       "preserveMetadata": [
           "Content-Type"
       ],
       "storeSettings": {
           "type": "AzureBlobStorageWriteSettings",
           "copyBehavior": "PreserveHierarchy"
       }
   }
   

3. 确保源数据集格式为Binary，且源存储设置开启recursive（若Zip内包含层级目录）。
4. 将修改后的JSON重新导入ADF（而非在UI中直接编辑保存），导入操作可绕过UI的schema校验限制。

验证步骤 #

• 管道运行完成后，进入目标Blob存储查看文件属性，确认Content-Type已正确匹配对应类型。
• 测试静态托管站点的index.html，确认可直接在浏览器打开而非触发下载。

内容的提问来源于stack exchange，提问作者Mathis Witte