我之前在使用Azure Data Factory处理FTP到ADLS的Zip文件复制时，也碰到过一模一样的问题——明明按文档设置了ZipDeflate压缩属性，结果ADLS里还是原封不动的压缩包。下面是我排查和解决的几个关键步骤，你可以逐一验证：

1. 确认压缩属性的配置位置是否正确 #

首先要明确：压缩类型必须配置在输入FTP数据集的JSON属性里，而不是输出ADLS数据集。很多人容易搞反位置，导致解压逻辑不生效。正确的配置示例应该是这样的：

{
    "name": "FTPSourceDataset",
    "properties": {
        "linkedServiceName": {
            "referenceName": "FTPLinkedService",
            "type": "LinkedServiceReference"
        },
        "type": "Binary",
        "typeProperties": {
            "location": {
                "type": "FtpServerLocation",
                "folderPath": "/your/ftp/zip/folder"
            },
            "compression": {
                "type": "ZipDeflate",
                "level": "Optimal"
            }
        }
    }
}

注意这里的数据集类型是Binary，因为我们要处理的是Zip二进制文件，让ADF自动识别并解压内部内容。

2. 检查输出ADLS数据集是否意外开启了压缩 #

如果你的输出ADLS数据集里也配置了压缩属性，哪怕输入已经解压了，输出时又会重新压缩成Zip包。所以务必确保输出数据集的压缩配置是None：

{
    "name": "ADLSOutputDataset",
    "properties": {
        "linkedServiceName": {
            "referenceName": "ADLSLinkedService",
            "type": "LinkedServiceReference"
        },
        "type": "DelimitedText", // 或者根据你内部文件类型调整，比如Binary
        "typeProperties": {
            "location": {
                "type": "AzureDataLakeStoreLocation",
                "folderPath": "/your/adls/target/folder"
            },
            "compression": {
                "type": "None"
            }
        }
    }
}

3. 验证复制活动的输入输出关联是否正确 #

进入复制活动的配置界面，确认源数据集选择的是你配置了ZipDeflate的FTP数据集，目标数据集是正确的ADLS数据集。如果关联错了数据集，解压逻辑自然不会触发。

4. 检查Zip文件本身的有效性 #

有些时候问题出在文件本身：

• 确认FTP上的Zip文件没有损坏，可以手动下载到本地解压测试；
• 检查是否是嵌套压缩（比如Zip里还有Zip），这种情况ADF只会解压外层，内层的Zip会原封不动传到ADLS；
• 确认文件后缀确实是.zip，而不是其他压缩格式（比如7z、rar）改了后缀，ADF的ZipDeflate只识别标准Zip格式。

5. 查看复制活动的运行日志找线索 #

如果以上步骤都没问题，去ADF的监控界面打开复制活动的详细运行日志，查看“源数据读取”和“目标数据写入”阶段的日志信息。如果解压失败，日志里会明确提示错误原因（比如文件损坏、权限不足等），这是定位问题最直接的方式。

按照这个流程排查下来，基本能解决大部分解压失效的问题。我当时就是不小心把压缩属性配到了输出数据集里，改过来就正常了。

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