Base64 编解码器 - 在线 Base64 Encode/Decode

1. 中文解出乱码的根本原因

Base64 编码的对象是字节，不是字符。同一个「你好」：UTF-8 Base64 是 5L2g5aW9，GBK Base64 是 xOO6ww==——两套结果完全不同。按 UTF-8 去解 GBK 载荷会得到成片 �；按 Latin-1 去解 UTF-8 载荷会得到 ä½ å¥½。排错顺序：先确认来源字符集，再在工具里切换「字符集」解码。界面在 � / ä¸ 症状时会提示改换字符集，而不是默默给错结果。

2. 字符集怎么选

• 新建与现代 API：保持 UTF-8（默认）。
• 来自 Windows 中文老系统、部分银行/政务接口：选 GBK 再编或解。
• 排查「UTF-8 字节被当成 Latin-1」时：用 Latin-1 解码对照，再切回 UTF-8 验证。
• 文件拖入按原始字节编码，不受文本字符集选项影响；文本框编解码才走字符集。

3. URL-safe 变体与 padding 规则

• 标准 Base64 的字母表含 + 和 /，这两个字符放进 URL 会被转义，于是有了 URL-safe 变体：+ 换成 -，/ 换成 _。
• padding 的 = 同样不适合 URL，很多实现（包括 JWT）直接剥掉；解码时需要补齐到 4 的倍数长度再解。
• 本工具对缺 padding 的输入自动补齐；判断一段字符串是不是 Base64，先看字符集是否只落在 A-Za-z0-9+/=（或 -_=）内。

4. Base64 不是加密

Base64 是编码不是加密：任何人拿到密文都能立即还原，它提供的保密性为零——相当于把信装进透明信封。它的设计目的只有一个：让二进制数据能安全通过只允许 ASCII 文本的通道（邮件正文、URL 参数、JSON 字符串、data URI）。真正需要保密的内容请使用 AES-GCM 等加密方案（可配合本站 AES 工具），Base64 只解决「能不能传」，不解决「能不能看」。

5. 体积膨胀的精确规律

每 3 个字节编码为 4 个字符，因此标准 Base64 的体积恒定为原始数据的 4/3（约 +33.3%），不足 3 字节用 = 补齐：精确公式是 4 × ceil(n/3)。实际影响举例：1 KB 的图片转 Base64 后约 1366 个字符；把图片内联进 CSS 或 JSON 时，这个膨胀叠加 gzip（Base64 后的可压缩性显著下降）会让有效负载明显变大——大图慎用内联，小图标（几 KB 以内）才是 data URI 的合理场景。

6. 解码结果的下一步识别

1. 解出以 data: 开头 → 这是一张 data URI，直接粘贴进浏览器地址栏或 img 标签就能渲染。
2. 解出以 PK 开头（十六进制 50 4B）→ ZIP 系压缩包（docx/xlsx/jar 都是），存成文件后改后缀打开。
3. 解出以 %PDF 开头 → PDF 文档，保存为 .pdf 即可。
4. 解出可见 JSON/XML 文本 → 多半是 JWT payload、配置片段或 API 响应体，配合 JSON 格式化工具继续处理。

7. MIME 换行、空白与「几乎是 Base64」的输入

邮件与部分老网关会按 MIME 规则每 76 字符插换行；复制进工具时若带着换行、空格或制表符，严格解码器会报非法字符。本工具在归一化阶段会容忍常见空白并补齐缺失的 =。仍失败时按顺序查：是否混入了非 Base64 字母（如中文引号）、是否其实是 Base32/Hex、是否把「整段 JWT」当成单段 Base64（JWT 是三段，应用 JWT 解码器）。文件拖入走原始字节路径，文本框才走字符集选项——两种输入不要混用排查结论。

8. 和 Base64URL / JWT / data URI 的分工

• URL 查询、JWT 段用 Base64URL（- _，常无 padding）；本页的 URL-safe 开关覆盖这一字母表。
• 完整 JWT（两段点号）请用 JWT 解码器：它会分三段并解释 claims，而不是把整串当普通 Base64。
• 图片/音频内联优先「Base64 转图片」或 data URI 工具；本页侧重文本往返与字符集排错。