中文 Base64 为什么是 5Lit5paH：UTF-8 先行

「中文」的 Base64 是 5Lit5paH。这个结果的来源是：先把两个字按 UTF-8 变成 6 个字节 E4 B8 AD E6 96 87，再对 6 个字节做 Base64。顺序反过来（先 Base64 再考虑字符集）在概念上不成立——Base64 只认字节，不认字符。

顺序错了就会乱码

字符 → 字节 → Base64 是唯一正确的链条。任何「字符 → Base64」的说法都省略了中间那步，而恰恰是这步决定了结果。

同一个「中文」，在 GBK 下是 4 个字节 D6 D0 CE C4，Base64 结果是 1tDOxA==。对比 UTF-8 的 5Lit5paH，长度和内容都不同。

所以「Base64 解出来是乱码」几乎从来不是 Base64 的问题，而是编码时与解码时用了不同字符集。

Emoji 与生僻字

常用 Emoji（如 😀）在 UTF-8 下是 4 个字节，比汉字多 1 个。生僻字、部分少数民族文字同样是 4 字节。四字节字符的 Base64 结果里会出现更多 + 与 /，放进 URL 时更容易被转义。

这个工具先按 UTF-8 把文本转成字节再编码，解码时按 UTF-8 还原，所以中文、Emoji、多语言混排都不会乱码。

乱码排查三步

1. 确认 Base64 本身能解：先解成字节，不要直接显示成文本。字符表之外的字符会立刻报错，说明输入的 Base64 本身有问题。
2. 确认字节数与内容对得上：一段 4 字中文的 UTF-8 是 12 字节，Base64 后 16 个字符（不含填充）；如果只有 8 个字符，那就是 2 字节编码（GBK）的数据。
3. 换字符集重解：同一串字节按 UTF-8 解出乱码时，试 GBK；按 GBK 解出乱码时，试 UTF-8。

三步里只有第三步是「猜」，前两步都能确定性地判断。

多行文本怎么处理

换行符是普通字符（\n，1 个字节），会一起参与编码，解码后原样还原。所以多行文本不需要特殊处理。

反过来，粘贴 76 字符一换行的 MIME 格式 Base64 时，解码前会先忽略所有空白，折行的文本也能直接解。