Azure SDK for JS文档翻译服务处理Word文件异常的解决方案

问题背景

在使用Azure SDK for JS的@azure-rest/ai-translation-document包进行文档翻译时，开发者反馈同步翻译.docx格式的Word文档后，输出的文件会出现损坏无法打开的情况。值得注意的是，同样的文档通过Python SDK处理却能正常输出，且文本文件(.txt)的翻译也未出现异常。

现象分析

通过对比测试发现以下关键现象：

1. 文件大小异常：原始文档2.8MB，JS SDK处理后文件膨胀至5.1MB，而Python SDK输出保持2.8MB左右
2. 文件验证失败：Word软件提示"无法读取内容"
3. 格式特异性：仅.docx文件出现此问题，文本文件处理正常

技术根源

经过Azure SDK团队深入排查，发现问题出在核心库对二进制流响应体的处理机制上。默认的响应体解析方式在处理Word文档这类二进制文件时存在缺陷，导致数据流被错误编码或转换。

解决方案

团队提供了临时解决方案，通过使用asNodeStream()方法绕过默认解析：

const response = await client.path("/document:translate")
  .post(options)
  .asNodeStream();

if (!response.body) {
  throw new Error("未接收到响应体");
}

const chunks = [];
for await (const chunk of response.body) {
  chunks.push(Buffer.isBuffer(chunk) ? chunk : Buffer.from(chunk));
}
const buffer = Buffer.concat(chunks);

fs.writeFileSync("输出文档.docx", buffer);

实现原理

该方法的核心改进点在于：

1. 使用流式接口直接获取原始响应数据
2. 手动将数据块组装为Buffer对象
3. 避免中间处理环节对二进制数据的干扰

最佳实践建议

1. 处理二进制文档时始终使用流式接口
2. 对于大文件可分块写入避免内存问题
3. 定期检查SDK更新，等待官方修复默认解析器

后续规划

Azure SDK团队已将此问题标记为需要长期修复的核心库缺陷，在官方修复发布前建议开发者采用上述解决方案。该问题不影响异步翻译接口的使用，仅涉及同步翻译场景。

通过这个案例我们可以看到，在处理二进制文件时需要特别注意数据流的传输方式，不同的序列化/反序列化方式可能导致文件结构破坏。这也提醒开发者在集成文件处理服务时，需要进行全面的格式兼容性测试。