如何借助 atob 处理多字节字符的 Base64 编解码逻辑以规避 Unicode 报错

atob() 解码含中文、emoji 的 Base64 字符串会乱码，因其仅还原为 Latin-1 字节流，未进行 UTF-8 到 UTF-16 的转换；正确方式是 decodeURIComponent(atob(encodedStr))。

直接用 atob() 解码含中文、emoji 等多字节字符的 Base64 字符串，一定会乱码或解出非法字符串——这不是 bug，是它设计如此。 它只把 Base64 解回 Latin-1 字节流（每个字符对应 0–255 的整数），而 JavaScript 字符串是 UTF-16，中间缺了一层 UTF-8 字节到 Unicode 的映射。必须补上这层，否则拿到的就是一堆 u00e4u00bdu00a0 这类不可读值。

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

因为 "5l2g5aw9" 是 UTF-8 字节 [0xe4, 0xbd, 0xa0, 0xe5, 0xa5, 0xbd] 的 Base64 编码；atob() 解出来的是一个长度为 6 的字符串，其每个字符的 .charCodeAt(0) 值恰好是 228, 189, 160, 229, 165, 189 ——也就是原始 UTF-8 字节值。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 等协议字段

这套组合在现代浏览器中稳定，但隐含成本明显：每次编解码都经历两次字符串转换（URI 编/解 + Base64 编/解）。对 >100KB 的文本，延迟可感知。真正需要高性能或处理二进制数据时，应考虑后端统一处理，或前端改用 TextEncoder + Base64 手动实现（但兼容性需自行兜底）。