Swift使用OData返回的二进制数据创建PDF出现文件损坏怎么办

数据老陈

2026-10-2

故障排查与解决方法

校验原始二进制数据格式
正常PDF文件前4字节固定为0x25 0x50 0x44 0x46（对应ASCII字符%PDF），你可以先打印接收到的gDocumentOutputData前4位做校验，如果不匹配说明OData返回的数据本身不是原生二进制，大概率是被做了Base64编码，需要先解码再生成文件，这是这类问题最常见的诱因。
校验数据长度匹配性
确认gDocBinarySize和OData接口返回的Content-Length数值完全一致，Data(bytes:count:)构造器对长度精度要求极高，多/少1字节都会生成损坏的文件。
优化写入逻辑
写入时增加.atomic参数，避免写入过程中进程中断导致文件不完整，同时确认文件名后缀为.pdf，避免系统隐式格式处理异常。

优化后代码示例

if let dir = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first{
    // 强制添加.pdf后缀避免格式识别错误
    let fileURL = dir.appendingPathComponent(im_filename).appendingPathExtension("pdf")
    print(fileURL)
    do{
        let pdfData = Data(bytes: gDocumentOutputData, count: gDocBinarySize)
        // 可选：PDF头校验
        if pdfData.count >= 4 {
            let header = pdfData.prefix(4)
            if header != Data([0x25, 0x50, 0x44, 0x46]) {
                print("原始数据非标准PDF二进制，若为Base64编码需先解码")
                // 若确认是Base64编码，取消下一行注释做解码
                // guard let decodedData = Data(base64Encoded: pdfData) else { return }
                // 后续使用decodedData写入即可
            }
        }
        // 增加atomic写入选项保障文件完整性
        try pdfData.write(to: fileURL, options: .atomic)
    }catch{
        print("写入失败：\(error.localizedDescription)")
    }
}