如何利用 atob 处理 WebSocket 传输的 Base64 压缩报文并还原为文本
很多开发者都踩过这个坑：直接用 atob 去解码 WebSocket 传过来的 Base64 压缩报文，结果要么报错，要么得到一堆乱码。问题出在哪？其实，atob 只能处理纯 ASCII 字符串，而经过 GZIP 压缩再 Base64 编码的数据，解码出来本质上是一串二进制字节流，根本不是可读的文本。
为什么 atob("H4sIAAAAAAA...") 会失败或返回乱码
咱们得先搞清楚 atob 到底干了什么。它接收一个合法的 Base64 字符串，然后输出一个由原始字节组成的“字符串”——注意，这里的每个字符，其 charCodeAt() 的值都在 0 到 255 之间。当服务端把 GZIP 压缩后的二进制数据做 Base64 编码再通过 WebSocket 推过来时，客户端收到的就是这个压缩数据的 Base64 外壳。如果你直接用 atob 剥开这层外壳，得到的是一串“二进制字符串”，这东西没法直接当 UTF-8 文本去 console.log 或者 JSON.parse。
- 典型错误现象：
atob("...")这一步执行成功了，但紧接着JSON.parse(decoded)就抛出一个SyntaxError: Unexpected token。 - 根本原因：GZIP 的输出是任意的字节序列。
atob解出来的字符串里，很可能包含像\x00\x1f\x8b...这样的非法 UTF-16 码点，Ja vaScript 引擎自然无法将其解释为有效的文本字符串。 - 关键区别要牢记：
btoa和atob并不是“文本编解码器”。它们绕过了编码层，做的是字节与 Latin-1 字符串之间的直接映射。
正确还原流程：atob → Uint8Array → inflate → TextDecoder
那么，正确的打开方式是什么？必须把 atob 的输出立刻转换成 Uint8Array，然后交给解压库（比如 pako）处理，最后再用 TextDecoder 转成 UTF-8 文本。这几步，一步都不能少。
- 第一步：用
atob解开 Base64，得到二进制字符串：const binStr = atob(base64Data) - 第二步：把这个字符串逐个字符转换成字节：
const bytes = new Uint8Array(binStr.length); for (let i = 0; i - 第三步：用 pako.inflate 进行解压：
const inflated = pako.inflate(bytes)（需要提前import pako from 'pako'） - 第四步：用
TextDecoder还原为最终文本：const text = new TextDecoder('utf-8').decode(inflated) - ⚠️ 特别注意：务必确认服务端使用的是标准的 GZIP 格式（而不是 deflate raw），否则
pako.inflate可能会抛出invalid block type错误。
WebSocket onmessage 中的实际处理代码
假设服务端推送的是 BinaryWebSocketFrame（二进制帧），并且其负载是经过 GZIP 压缩再 Base64 编码的字符串（这种设计常用于兼容性兜底），处理代码可以这样写：
websocket.onmessage = function(event) {
if (typeof event.data === 'string') {
try {
// 1. Base64 解码
const binStr = atob(event.data);
// 2. 转 Uint8Array
const bytes = new Uint8Array(binStr.length);
for (let i = 0; i < binStr.length; i++) {
bytes[i] = binStr.charCodeAt(i);
}
// 3. GZIP 解压（pako）
const inflated = pako.inflate(bytes);
// 4. UTF-8 解码
const text = new TextDecoder('utf-8').decode(inflated);
console.log('解压后文本:', text);
// 5. 后续处理，如 JSON.parse(text)
} catch (e) {
console.error('Base64/GZIP 解析失败:', e);
}
}
};
- 另一种情况：如果服务端直接发送的是纯二进制帧（
ArrayBuffer），那就完全不需要atob了，直接new Uint8Array(event.data)然后交给pako.inflate即可。 - 兼容性考量：如果浏览器环境不支持
pako，可以考虑使用较新的DecompressionStreamAPI（Chrome 110+、Firefox 120+），但这需要配合ReadableStream使用，兼容性范围更窄。 - 性能提示：
atob对输入字符串长度有隐式限制（大约 2^27 个字符），超长的 Base64 字符串会触发"InvalidCharacterError"。遇到这种情况，就得考虑分块处理，或者让服务端进行数据切片。
最后，真正容易让人栽跟头的点，往往在于从 atob 到 Uint8Array 的转换这一步。很多人误以为 atob 返回的就是“字节数组”或者“可以直接解压的 buffer”。其实不然，它返回的是一个“伪字符串”——每个字符虽然代表一个字节，但 Ja vaScript 的字符串本身并不是字节容器，必须显式地进行投射转换。漏掉这一步，后面所有的解压和解码操作都会失效。这才是关键所在。
