64 个字符的字符表
Base64 的字符表由 A–Z（26 个）、a–z（26 个）、0–9（10 个）再加 + 和 / 组成，正好 64 个。每个字符代表 6 位二进制，四个字符拼出 3 个字节。
记住这个构成，就能一眼识别 Base64：如果一串文本只包含这些字符且长度是 4 的倍数，八成就是 Base64 编码的结果。
填充符 = 的作用
原文长度不一定是 3 的倍数，编码后就用 = 把长度补齐到 4 的倍数。一个 = 表示原文末尾差 1 个字节，两个 = 表示差 2 个字节。
= 只会出现在末尾，最多两个。复制结果时千万别丢了它，缺了填充符，严格的解码器会直接报错。
URL 安全变体
标准 Base64 的 + 和 / 在网址里有特殊含义，放进 URL 参数会被转义或截断。于是有了变体：用 - 代替 +，用 _ 代替 /，通常还去掉末尾的 =。
JWT 的 token 用的就是这种变体。如果你看到的 Base64 里有 - 和 _ 而没有 +/=，那它就是 URL 安全版，解码时要选对应的模式。
MIME 与其他变体
邮件附件用的 Base64（MIME 规范）要求每 76 个字符换行，这是为了兼容老邮件系统。从邮件里抠出来的编码文本带换行是正常的。
不同变体之间不能混用解码器。用错变体轻则报错，重则解出乱码，拿到 Base64 字符串先看它长什么样，再选解码方式。
常见问题
为什么 Base64 偏偏是 64 个字符？
因为 2 的 6 次方等于 64，每个字符恰好表示 6 位二进制，4 个字符拼成 24 位即 3 个字节，转换过程整齐高效，这是设计上的巧妙之处。
= 出现在中间正常吗？
不正常。填充符只出现在末尾，最多两个。如果中间出现 =，说明字符串被截断拼接错了，或者它根本不是 Base64。
URL 安全版和标准版能通用吗？
不能直接通用。- _ 和 + / 是两套符号，解码前要先确认版本。用错解码器会报错或得到乱码，JWT 场景务必用 URL 安全模式。
Base64 字符串有长度上限吗？
编码规范本身没有上限，但实际使用中要注意：URL 参数有长度限制，某些数据库字段也有长度限制，超长内容建议换存储方式而非硬塞。