atob解码websocket报文前需先剥离data:协议头并校验base64格式，再通过uint8array和textdecoder将latin-1字节转为utf-8字符串，否则中文/emoji会乱码。
atob 解码 WebSocket 报文前必须剥离 data: 协议头
WebSocket 收到的 Base64 字符串若来自服务端预签名响应、元数据字段或调试注入，常带 data:text/plain;base64, 这类前缀。直接传给 atob() 会触发 InvalidCharacterError —— 因为 atob() 只认纯 Base64 字符（A-Z、a-z、0-9、+、/、=），其余全是非法字符。
实操建议：
- 用
.split(',')切分一次，取最后一段：const raw = message.split(',').pop() - 更稳妥的做法是用正则提取：
const raw = message.replace(/^data:[^;]+;base64,/, '') - 切完务必校验长度是否为 4 的倍数，且只含 Base64 字符集，否则提前 return 或 throw
中文/Emoji 报文解码失败？说明没走 UTF-8 字节还原路径
atob() 返回的是 Latin-1 字符串（每个字符对应一个字节），不是 UTF-8 文本。如果原始报文含中文、emoji 或任意非 ASCII 字符，直接 atob(raw) 得到的是一串乱码字符串，.length 和 .charCodeAt() 值全错。
正确做法是把 atob() 结果转成 Uint8Array，再用 TextDecoder 解码：
function b64_to_utf8(b64str) {
const bin = atob(b64str);
const bytes = new Uint8Array(bin.length);
for (let i = 0; i
<p>注意点：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2287" title="WebSocket 8.18.2"><img
src="https://img.php.cn/upload/manual/001/221/864/6a1560869301b447.png" alt="WebSocket 8.18.2" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2287" title="WebSocket 8.18.2" class="overflowclass">WebSocket 8.18.2</a>
<p class="overflowclass">WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2287" title="WebSocket 8.18.2" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 不要用
decodeURIComponent(escape(...))方案，它在 emoji 场景下会出错 -
TextDecoder在所有现代浏览器中已稳定支持（Chrome 54+/Firefox 53+/Safari 10.1+） - 若需兼容 IE，必须引入 polyfill 或改用
js-base64库的Base64.decode()
WebSocket 实时流中频繁调用 atob 可能引发性能抖动
高频报文（如每秒数十条心跳+业务混合帧）下，反复构造 Uint8Array、调用 TextDecoder.decode() 会产生短生命周期对象，触发 V8 频繁 GC，表现为页面卡顿或帧率下降。
优化方向：
- 复用
TextDecoder实例：声明为模块级常量，避免每次新建new TextDecoder('utf-8') - 对纯 ASCII 报文走快速路径：先用正则
/^[A-Za-z0-9+/]*={0,2}$/粗筛，匹配则直接atob()+String()，跳过字节转换 - 若报文结构固定（如前 4 字节为 length header），可提前截断并仅解码 payload 区域，减少处理量
敏感报文解码后仍需校验内容完整性
Base64 只是编码，不提供加密或防篡改能力。WebSocket 通道若未启用 wss://，中间人可轻易替换 Base64 字符串，导致解码后得到伪造文本。
关键防护动作：
- 强制使用
wss协议，禁用ws明文连接 - 服务端应在 Base64 编码前附加签名（如 HMAC-SHA256），客户端解码后先验签再业务处理
- 对解码结果做最小业务校验：比如 JSON 报文必须以
{开头、含必要字段；二进制协议头需匹配 magic number - 日志中避免打印完整解码后明文，尤其含 token、手机号等字段
最容易被忽略的是：即使用了 wss，若服务端签名密钥硬编码在前端 JS 里，整套校验就形同虚设。
