2 分钟阅读
Base64 和 Unicode：日常排查版解释
Base64 到底是什么，为什么中文有时会乱码，以及怎样不丢字符地编码和解码。
Base64 看起来像一段暗号，但它本质上只是传输格式。它把字节转成普通 ASCII 文本，让值可以安全地经过 JSON、环境变量、URL、邮件正文和日志。
这个区别很重要：Base64 不是加密，也不会隐藏敏感信息。任何人都可以解码。
最常见的错误
很多 Base64 片段坏掉，并不是 Base64 本身坏了，而是前一步出错：文本用错误的字符编码变成了字节。
如果只有英文，这个问题可能长期看不出来。一旦遇到中文、emoji、重音字符或中英混合内容，就很容易暴露。
这段文本：
Hello yueyekidl 你好
必须先变成 UTF-8 字节，再把这些字节编码成 Base64：
SGVsbG8geXVleWVraWRsIOS9oOWlvQ==
按 UTF-8 解码，原文会回来。按错误假设解码，就会出现乱码。
Base64 适合用在哪里
当一个系统只接受文本值，但你需要把字节传过去时，Base64 很有用：
- JSON 响应里的短 payload。
- 复制进配置文件的 token-like 值。
- 放进日志或工单里的短二进制值。
- 需要穿过不喜欢原始 Unicode 的系统的字符串。
它不适合用来隐藏秘密、压缩大内容，或者把文件硬塞进本该使用对象存储的地方。
更稳的排查顺序
Base64 值解不开时，按这个顺序检查：
- 文本是不是有效 Base64？复制时多出的空格或标点会破坏它。
- 原始内容是文本还是二进制？
- 如果是文本，当时是不是按 UTF-8 编码？
- 你是不是先解成字节，再把字节当文本处理？
最后一步很容易藏 bug。先是字节，后是文本。
本地试一下
用 Base64 编解码工具 测试值，不需要发送到服务器。粘贴 Unicode 文本，编码，再切换到解码，确认往返后还是同一段文本。
如果本地能往返，别的系统里却失败，问题大概率在那个系统的编码假设上。