Angular使用Pako压缩请求后后端缺失GZIP_MAGIC的解决咨询

问题场景 #

应用基于Angular与Java开发，前端使用Pako库压缩请求体，代码如下：

var compressedBody = pako.gzip(JSON.stringify(request.body))
const clone = request.clone({ headers: request.headers.append('Content-Encoding', 'gzip'), body: compressedBody });

后端Java读取请求时，检测不到GZIP格式的魔法标识（GZIP_MAGIC）：readUShort(in)返回值为8752，而预期的GZIP_MAGIC值为35615，后端校验代码如下：

CheckedInputStream in = new CheckedInputStream(this_in, crc);
crc.reset();
// Check header magic
if (readUShort(in) != GZIP_MAGIC) {
    throw new ZipException("Not in GZIP format");
}

问题原因 #

Pako.gzip返回的是标准GZIP格式的Uint8Array，但直接将其作为请求体发送时，Angular会默认将二进制数据转换为UTF-8字符串，导致GZIP头部的字节序列被破坏，后端读取到错误数值。

解决方案 #

修改前端代码，将Pako生成的Uint8Array转换为Blob后再作为请求体发送，确保二进制数据以原始格式传输：

const jsonBody = JSON.stringify(request.body);
const compressedBody = pako.gzip(jsonBody);
// 将Uint8Array转换为Blob，保留原始二进制数据
const blob = new Blob([compressedBody], { type: 'application/json' });
const clone = request.clone({
  headers: request.headers.append('Content-Encoding', 'gzip'),
  body: blob
});

补充说明 #

GZIP标准的魔法标识是0x1F8B（十进制35615），Pako生成的压缩数据本身符合该标准，问题仅出在前端请求体的传输编码环节。转换为Blob后，请求会以二进制形式发送，后端输入流就能正确读取到GZIP_MAGIC，完成解压流程。

内容的提问来源于stack exchange，提问作者Ana Belén González Villalba