很多开发者在搞懂 Base64 之前，就已经无数次和它打过照面：邮件附件、data URL、认证令牌、配置文件，以及那些一打开就密密麻麻的字母数字。它看上去像被加密了，其实没有；看上去像被压缩了，结果往往比原始数据还大。它真正的作用很实用：让二进制数据安全地穿过那些只认文本的系统。
Base64 要解决的根本问题
计算机里的一切文件本质上都是字节，都是 0 到 255 之间的数字序列。现代协议常常可以直接传输这些字节，但许多更老或面向文本的系统做不到：有的把某些字节值保留为控制字符，有的强行假定某种字符编码，有的会改写换行符，还有的干脆拒绝任何不可打印的内容。
Base64 通过把任意字节翻译成一小撮普通字符，构造出一种安全的表示形式。标准 Base64 用到大小写拉丁字母、数字、加号、斜杠，必要时再加上等号做填充。这些字符可以顺利地存活在文本字段、日志、JSON 字符串和各种传输层里，而不会被误解成原始的二进制控制信号。
字节是如何变成 Base64 字符的
它的名字来自字符表的大小：一共六十四个符号。也就是说一个 Base64 字符恰好能表示六个比特，因为六位二进制刚好有六十四种组合。编码器每次读入三个字节、即二十四个比特，再切成四组、每组六位，每组的数值对应字符表里的一个字符。
以单词 Man 为例，它在 ASCII 里正好占三个字节。Base64 把这二十四个比特切成四个六位值，输出 TWFu。没有任何东西被隐藏，只是同样的比特被重新分了组而已，任何拥有解码器的人都能精确还原出原始字节。
为什么末尾会出现填充符
输入并不总能被三整除。当结尾只剩下一个或两个字节时，编码器仍然需要用六位的 Base64 字符把它们表达出来。标准 Base64 会在末尾补上一个或两个等号，用来标明最后一组数据并不完整。填充让编码结果的长度始终是四的倍数，也帮助解码器判断有效数据到哪里为止。
有些格式会省略填充，因为长度本身就能反推出来。JWT 用到的 Base64URL 变体通常就去掉了末尾的等号。这不改变底层思路，但意味着解码器可能需要先把缺失的填充补回去，再调用严格的标准实现。
把二进制变成文本的代价
Base64 用体积换来了兼容性。三个源字节变成四个文本字符，因此在还没计入换行和外层标记之前，编码结果就已经大了约三分之一。把一个小图标内嵌进 CSS 也许很方便；但把一段大视频塞进 JSON 通常就是浪费，既难以流式处理，解析起来也更昂贵。
压缩能缓和这部分开销，但无法让 Base64 变得免费。系统应当只在确实遇到纯文本边界时才用它，而不是把它当成文件上传、二进制响应体或对象存储的默认替代品。
Base64 真正派得上用场的地方
电子邮件是个经典例子。MIME 借助 Base64，让附件能穿过那些历史上只认可打印字符的邮件基础设施。网页用 data URL 把小图片或字体直接嵌进 HTML 和 CSS。接口有时在 JSON 里用 Base64 承载小段二进制值，因为 JSON 没有原生字节类型。证书、密钥也常被包进 PEM 文本里。
Base64URL 则解决了一个相关的传输难题：标准 Base64 里的加号和斜杠在 URL 中有特殊含义，等号在查询参数里也碍事。URL 安全变体用连字符和下划线替换它们并常常省去填充，于是 JWT 的各片段才能干净地出现在 HTTP 头和链接里。
Base64 并不能提供什么
最常见的误解，是以为 Base64 能保护信息。它不提供任何机密性、完整性、真实性，也不是密码安全手段。一串 Base64 在人眼里也许陌生，但解码它无需任何密钥、瞬间即可完成。把凭据或个人数据丢进 Base64 编码器，等同于换了一种写法，而不是把它们锁了起来。
Base64 也不会校验解码后数据的含义。解码器顶多判断字符是否符合字符表，而还原出的字节仍可能损坏、恶意，或根本是错误的格式。应用必须另行限制大小、在合适时验证签名或哈希，并始终把解码内容当作不可信输入。
一个实用的思考方式
把 Base64 理解成"打包"最为贴切：它把难以穿过文本通道的字节，装进一个可预测的文本容器。包裹更大、容易打开，本身不提供安全保障；当兼容性比体积更重要时，这笔交易才值得。
要判断是否该用它，先看数据必须跨越的那道边界。边界接受二进制，就直接发二进制；只接受文本、且载荷不大，Base64 就是一座可靠的桥。这条规则既解释了它为何长盛不衰，也说明了它在许多场合本就该被避开。