正确做法是绕过字符串中间层，将Base64通过atob转为字节字符串后，逐字符取charCodeAt(0)填入Uint8Array；错误做法是用TextDecoder等将其当UTF-8解码。
直接用 atob 解 Base64 字符串再转 Uint8Array，遇到中文、emoji 或控制字符时容易在 decodeURIComponent(escape(...)) 类解码路径中抛错——根本原因不是 Base64 本身，而是后续误用字符串编码桥接逻辑。正确做法是绕过字符串中间层，把 Base64 → 二进制字节 → Uint8Array 作为原子操作完成。
先用 atob 得到原始字节流（非字符串）
atob 实际返回的是包含 8 位字节值的字符串（每个字符 UTF-16 码点 ≤ 255），但它**不是合法 UTF-8 字符串**，不能直接当文本处理。关键在于：不要对 atob 结果调用 encodeURI、unescape 或 TextDecoder，除非你明确知道它代表 UTF-8。
- ✅ 正确：将
atob返回字符串逐字符取.charCodeAt(0)，得到 0–255 的整数，填入Uint8Array - ❌ 错误：用
new TextDecoder('utf-8').decode(atob(...))—— 若原始加密数据含非法 UTF-8 字节序列（如 AES-GCM 密文），必然报错
安全构造 Uint8Array 的标准写法
以下函数可无损还原任意 Base64 编码的二进制数据（密钥、IV、密文等）：
function base64ToUint8Array(base64) {
const binStr = atob(base64);
const len = binStr.length;
const bytes = new Uint8Array(len);
for (let i = 0; i < len; i++) {
bytes[i] = binStr.charCodeAt(i);
}
return bytes;
}
这个方法不依赖编码语义，只做字节映射，适用于所有加密配置流（如 JWT 加密头、AES 密文块、RSA 公钥 PEM 提取的 DER 数据）。
若需进一步解析为文本（例如 JSON 配置），必须明确原始编码
如果 Base64 内容本就是 UTF-8 编码的 JSON（如加密前的明文配置），应在获得 Uint8Array 后用 TextDecoder 显式解码：
- 先
base64ToUint8Array(b64) - 再
new TextDecoder('utf-8').decode(uint8arr) - 若解码失败，说明原始数据不是 UTF-8 —— 此时不应强行修复，而应检查加密流程是否意外混入二进制数据
规避常见 Unicode 报错的检查清单
- 确认 Base64 字符串未被 URL 编码或截断（末尾等号缺失会导致
atob报错） - 避免在
atob后使用JSON.parse直接解析 —— 必须先转Uint8Array，再按需解码为字符串 - 服务端返回加密配置时，建议统一用 Base64url（RFC 4648 §5）并去掉填充，前端用
atob前先替换-→+、_→/ - 调试时可用
uint8Array.every(b => b 快速验证字节有效性
