readAsDataURL转PDF Blob为base64时类型为octet-stream解决方法

• 接口返回的Blob对象本身的type属性被默认标记为application/octet-stream，本质原因通常是两点：一是后端接口返回PDF数据时未正确设置Content-Type: application/pdf响应头，二是前端请求封装拉取二进制数据时未显式指定responseType: 'blob'，导致运行环境自动将二进制流标记为通用的八进制流类型。
• 你当前通过字符串替换把dataURL里的octet-stream改成pdf的写法存在明显风险：如果PDF二进制内容转base64后刚好包含octet-stream字符串，会出现误替换导致文件损坏，而且这种写法没有从根源修正Blob的MIME类型，后续做下载、预览操作时依然会触发类型错误。

• 前端快速修复方案：在读取Blob前重新生成指定PDF类型的Blob对象，从数据源层面修正MIME类型，完全抛弃字符串替换的写法，参考实现如下：

const getBytesData = () => {
  if (user) {
    getInvoicePDFStringByInvoiceId('129', user.user.token).then((data) => {
      if (data.blob) {
        // 重新构造指定MIME类型的PDF Blob
        const pdfBlob = new Blob([data.blob], { type: 'application/pdf' });
        const reader = new FileReader();
        reader.readAsDataURL(pdfBlob);
        reader.onloadend = () => {
          const base64data = reader.result;
          console.log('Pdf loaded:- ', base64data);
          setPDFLoaded(base64data);
        };
      } else {
        console.log('Error happened from API = ', data.error, data.message);
      }
    });
  }
};

• 根源修复方案：从全链路避免同类问题
  • 检查getInvoicePDFStringByInvoiceId请求方法的封装，拉取二进制文件时必须显式配置responseType: 'blob'，不要让请求工具自动推断响应类型。
  • 协调后端调整接口响应配置，返回PDF文件时明确设置响应头Content-Type: application/pdf，不要用通用二进制流类型application/octet-stream返回明确格式的文件。

注意：字符串替换修改dataURL的MIME标记属于容错率极低的野路子写法，不建议在生产环境使用，极易出现偶发的文件损坏问题。

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