atob处理多字节Base64编解码规避Unicode报错

直接使用 atob() 解码包含中文或 Emoji 的 Base64 字符串，结果极易出现乱码。这并非程序错误，而是其设计逻辑所致。atob() 仅将 Base64 还原为 Latin-1 字节流，而 JavaScript 内部采用 UTF-16 编码的字符串。两者之间缺少关键一步：将 UTF-8 字节序列正确映射为 Unicode 码点。缺少这一步，你得到的只会是一堆类似 \u00e4\u00bd\u00a0 这样无法直接阅读的字符。

为什么 atob("5l2g5aw9") 不等于 "你好"

关键在于理解数据流。字符串 "5l2g5aw9" 实际上是 UTF-8 字节序列 [0xe4, 0xbd, 0xa0, 0xe5, 0xa5, 0xbd] 的 Base64 编码。当 atob() 解码后，它返回一个长度为 6 的字符串，其中每个字符的 .charCodeAt(0) 值恰好对应原始的 UTF-8 字节值：228, 189, 160, 229, 165, 189。问题在于，JavaScript 引擎将这些数值直接当作独立的 Latin-1 码点来解释，完全跳过了 UTF-8 的解码流程。

由此引发的常见现象包括：

• 控制台打印结果可能显示为乱码、空白或空字符串。
• 尝试 JSON.parse() 时，会因遇到非法 Unicode 序列而抛出错误。
• 中文字符可能显示为方块、问号，或在某些位置被截断。

atob() 必须与 decodeURIComponent() 配套使用

解决之道是固定的解码顺序：decodeURIComponent(atob(encodedStr))。这两个步骤缺一不可，且顺序不能颠倒。

实际操作时，有几个细节需要注意：

• 如果 Base64 字符串来自服务端，可能包含换行符、空格或填充符缺失，解码前最好先用 .trim() 清理。
• 若 Base64 源自 URL（例如 JWT 的 payload 部分），需先进行字符还原：将 - 替换为 +，将 _ 替换为 /，并根据需要补足 = 填充符。
• 避免使用已废弃的 escape() 函数，它对 +、/ 等字符的处理不一致，容易引入新的错误。
• 一个验证示例：decodeURIComponent(atob("JUU0JUJEJUEwJUU1JUFEJUE3")) 的结果正是 "你好"。

编码端必须用 encodeURIComponent() 预处理

编码过程同样有讲究。btoa() 函数本身不支持 Latin-1 范围之外的字符，因此不能让它直接处理中文。正确的做法是在编码前，先将字符串转换为纯 ASCII 的百分号编码格式。

安全的编码流程如下：

• btoa(encodeURIComponent(str)) 是唯一推荐的路径。
• 错误写法示例：btoa("你好") 会直接抛出 DOMException: The string to be encoded contains characters outside of the Latin1 range。
• 需要警惕一种过时且不可靠的绕过方法：btoa(unescape(encodeURIComponent(str)))，不建议使用。
• 请注意：encodeURIComponent() 的输出本身不是 Base64，不能单独用于 Basic Auth 或 JWT 等协议的字段填充。

这套 encodeURIComponent + btoa / atob + decodeURIComponent 的组合拳在现代浏览器中表现稳定，但其代价也显而易见：每次编解码都涉及两次完整的字符串转换（URI 编/解 + Base64 编/解）。对于超过 100KB 的文本，性能延迟是可以感知的。因此，如果面临高性能需求或需要处理大量二进制数据，更稳妥的方案是考虑在后端统一处理，或者在前端使用 TextEncoder 配合手动实现的 Base64 编解码逻辑（当然，这需要自行处理兼容性问题）。