Base64 解码出现中文乱码怎么办？

Base64 处理的是字节，不是文字

文本必须先按 UTF-8、GBK 等字符集转换为字节，之后才能进行 Base64 编码。解码得到字节后，还要使用相同字符集还原文本。

如果编码端使用 UTF-8，解码端却按 Latin-1 或系统默认编码读取，英文可能正常，中文则会乱码。

浏览器中的常见陷阱

传统 btoa 和 atob 直接处理的是单字节字符串，不能安全地把任意 Unicode 文本直接传入。应先使用 TextEncoder 转为 UTF-8 字节，解码后再用 TextDecoder 还原。

还要区分普通 Base64 和 Base64URL。后者会把加号和斜杠替换为减号和下划线，并可能省略末尾等号。

乱码排查顺序

先确认输入是否确实为 Base64，再询问来源系统使用的字符集，然后检查换行、URL 编码和 Base64URL 替换。

如果来源是文件或接口响应，不要先按错误字符集转成字符串，应尽量保留原始字节后再解码。

用 UTF-8 正确处理中文的完整过程

编码时先把字符串交给 UTF-8 编码器得到字节数组，再把这些字节转换为 Base64。解码时顺序相反：先把 Base64 还原为字节数组，再用 UTF-8 解码器生成字符串。两端必须对字符集达成一致。

如果中间经过 URL 查询参数、表单或 JSON，还要检查 Base64 中的加号是否被当成空格，以及等号是否被截断。此时看起来像字符编码问题，实际损坏发生在传输层。

• 文本 → UTF-8 字节 → Base64
• Base64 → 字节 → UTF-8 文本
• 不要直接对任意中文调用传统 btoa
• 通过 URL 传输时对 Base64 再做 URL 编码

不知道原始字符集时怎么办

Base64 自身没有字符集元数据，因此无法仅凭编码结果百分之百判断原文是 UTF-8、GBK 还是其他编码。应优先查看接口文档、HTTP Content-Type、文件格式说明或来源系统配置。

如果只能依靠试验，可以分别使用候选字符集解码并检查是否出现大量替换字符、不可见控制字符或不符合语言规律的文本。但这种启发式判断不适合自动处理重要数据。

• 查看 Content-Type 中的 charset
• 确认文件或数据库原始编码
• 联系数据提供方确认约定
• 不要把“看起来能读”当作编码正确的唯一依据

图片和文件的 Base64 不是文本

图片、压缩包和 PDF 等二进制文件经过 Base64 编码后，解码结果仍然是二进制字节，不应使用 TextDecoder 强行转换为文字。正确做法是根据 MIME 类型构造 Blob、文件或数据 URL。

Base64 会让体积增加约三分之一，不适合替代正常文件传输。小图标和短配置可以内嵌，较大文件更适合使用文件上传、对象存储或普通静态资源地址。

• 先确认内容是文本还是二进制
• 保留正确 MIME 类型
• 大文件避免内嵌 Base64
• 不要把 Base64 当成压缩或加密