当从 API 获取 PDF 二进制流时，若错误地使用 response.text() 解析原始字节，会导致字符编码损坏（如将多字节 PDF 字节误作 UTF-16 处理），最终生成空白 PDF。正确做法是直接通过 response.arrayBuffer() 获取原始二进制数据，再构造 Uint8Array。
当从 api 获取 pdf 二进制流时，若错误地使用 `response.text()` 解析原始字节，会导致字符编码损坏（如将多字节 pdf 字节误作 utf-16 处理），最终生成空白 pdf。正确做法是直接通过 `response.arraybuffer()` 获取原始二进制数据，再构造 `uint8array`。
在前端处理 PDF 文件流（尤其是来自 REST API 的二进制响应）时，一个常见误区是将 PDF 内容当作纯文本解析。PDF 是二进制格式，其起始标识 %PDF-1.4 后紧跟大量非 UTF-8/UTF-16 可安全映射的原始字节（如压缩对象、二进制图像流、加密元数据等）。一旦调用 response.text()，浏览器会尝试按默认编码（通常是 UTF-8）解码这些字节；遇到非法序列时可能静默替换为 `，或截断/错位，导致Uint8Array` 数据失真——这正是你看到空白 PDF 的根本原因。
✅ 正确方案：跳过文本解析，直取原始字节缓冲区：
let response = await this.getDocument(id);
if (response.status === 200) {
// ✅ 关键：使用 arrayBuffer() 而非 text()
const arrayBuffer = await response.arrayBuffer();
const uint8Array = new Uint8Array(arrayBuffer);
const blob = new Blob([uint8Array], { type: 'application/pdf' });
const fileURL = URL.createObjectURL(blob);
window.open(fileURL, '_blank'); // 显式指定 _blank 更可靠
}
⚠️ 注意事项：
-
不要使用
response.blob()替代：虽然response.blob()也能生成 PDF Blob，但若后续需对字节进行处理（如签名、分片、校验），仍需Uint8Array或ArrayBuffer，直接arrayBuffer()更灵活且无额外解析开销。 -
Salesforce LWC 兼容性：该方法完全兼容 Lightning Web Components，
fetch和ArrayBuffer在现代 Salesforce 运行时（Chrome 内核）中已全面支持。 -
内存优化提示：对于大 PDF（>50MB），
arrayBuffer()会完整加载至内存。如需流式处理，可考虑ReadableStream+Response.body.getReader()，但预览场景通常无需此复杂度。 -
Content-Type 验证：建议在
if前增加response.headers.get('content-type')?.includes('application/pdf')校验，避免非 PDF 响应引发静默失败。
总结：PDF 是二进制载体，不是文本。始终优先使用 response.arrayBuffer() 获取原始字节，这是跨浏览器、跨框架（包括 LWC）安全还原 PDF 的黄金准则。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
