本文详解因 AJAX 响应类型配置不当导致 DOCX 文件下载后字节不一致、文件损坏的问题，通过修正服务端 TransmitFile 与客户端 xhrFields.responseType = 'blob' 的协同配置，确保二进制流完整无损传输。
本文详解因 ajax 响应类型配置不当导致 docx 文件下载后字节不一致、文件损坏的问题，通过修正服务端 `transmitfile` 与客户端 `xhrfields.responsetype = 'blob'` 的协同配置，确保二进制流完整无损传输。
在基于 ASP.NET WebForms 的 Web 应用中，通过 AJAX 下载 .docx 等 OpenXML 格式文档时，若服务端使用 Response.BinaryWrite(byte[]) + 客户端 responseType: 'arraybuffer' 的组合，极易引发文件损坏（提示“File is corrupt”）。根本原因在于：AJAX 默认将响应体按文本方式解析（如 UTF-8），导致二进制数据被错误解码和截断——这正是您观察到服务端 4338 字节、客户端 7045 字节的异常现象：多出的字节实为乱码填充，而非真实内容。
✅ 正确实践：服务端与客户端协同保障二进制完整性
1. 服务端：优先使用 TransmitFile()，避免内存加载与编码干扰
context.Response.Clear();
context.Response.ContentType = "application/vnd.openxmlformats-officedocument.wordprocessingml.document";
context.Response.AppendHeader("Content-Disposition", $"attachment; filename={documentFileName}");
// 关键：直接流式传输物理文件，绕过 byte[] 加载与潜在编码转换
context.Response.TransmitFile(documentFilePath);
context.Response.Flush();
context.Response.End();
⚠️ 注意事项：
- TransmitFile() 比 BinaryWrite() 更高效且安全，它由 IIS 直接处理文件流，不经过 .NET 内存缓冲，杜绝了 ReadAllBytes() 可能引入的隐式编码或内存溢出风险；
- 移除手动设置 Content-Length —— TransmitFile() 会自动写入正确长度头；
- 避免 Response.AddHeader() 重复调用，改用 AppendHeader() 更规范。
2. 客户端：强制 xhrFields.responseType = 'blob'，禁用文本解析
$.ajax({
type: "POST",
url: '/exportDataForDocument',
data: JSON.stringify(result),
contentType: "application/json",
// ✅ 核心修复：显式声明 responseType 为 blob，确保浏览器以原始二进制接收
xhrFields: {
responseType: 'blob'
},
success: function(data, textStatus, xhr) {
// 从响应头提取真实文件名（更健壮，避免手动解析）
const contentDisposition = xhr.getResponseHeader('Content-Disposition');
const fileName = contentDisposition
? /filename[^;=\n]*=((['"]).*?\2|[^;\n]*)/.exec(contentDisposition)?.[1]?.replace(/['"]/g, '')
: 'document.docx';
const url = window.URL || window.webkitURL;
const objectUrl = url.createObjectURL(data);
const a = document.createElement('a');
a.href = objectUrl;
a.download = fileName;
a.style.display = 'none';
document.body.appendChild(a);
a.click();
document.body.removeChild(a);
url.revokeObjectURL(objectUrl); // 及时释放内存
},
error: function(xhr, status, error) {
console.error('DOCX download failed:', error, xhr.status, xhr.responseText);
}
});
? 关键点说明：
- xhrFields.responseType: 'blob' 是强制浏览器将响应体作为原始二进制 Blob 处理，完全规避 JSON/XML/Text 解析路径；
- responseType: 'arraybuffer' 在 jQuery 中常因 processData: true 或默认 MIME 推断失效，而 blob 类型更可靠；
- 使用正则安全提取 Content-Disposition 中的文件名，兼容带引号与不带引号格式；
- 调用 revokeObjectURL() 防止内存泄漏。
? 补充验证建议
- 服务端日志：添加 new FileInfo(documentFilePath).Length 日志，确认源文件大小；
- 客户端校验：下载后可在控制台执行 blob.size === expectedSize 验证一致性；
- 替代方案：若需动态生成 DOCX（非静态文件），务必使用 MemoryStream + Response.OutputStream.Write()，并严格设置 Content-Length 和 ContentType，避免 BinaryWrite() 的隐式编码陷阱。
遵循上述方案，即可彻底解决 DOCX 下载损坏问题，确保服务端与客户端字节数严格一致，文档可正常打开编辑。
