这篇文章把 Base64 的编码原理和工程逻辑彻底讲清楚。

一、Base64到底解决什么问题？

计算机世界里有两套"语言程序"：

• 二进制世界图片、音频、加密后的密文、protobuf 消息…，它们是任意的二进制流，可能包含 \ 、 <、> 、 & 或控制字符等“危险分子”。
• 文本世界JSON、XML、HTML、URL、邮件协议、配置文件…，它们只认可打印的 ASCII 字符，看到 \ 就截断，看到 <以为是标签开头，看到 & 以为是转义符。

Base64 是一座桥它把二进制数据翻译成文本世界能安全识别的字符。让二进制数据能在邮件里发、在 JSON 里传、在 URL 里带、在配置文件里存。

代价是体积膨胀约33%。不过，但工程上，兼容性往往比带宽更贵。

二、编码原理： 位一组的“切片游戏”

为什么是6位？

ASCII 有256个字符，但安全无歧义可打印的只有64个：

• A-Z
• a-z
• 0-9
• '+' 和 '/'

6×4=24 → 16+8=24 = 256 /16 =16?，不对，这里只需要说明

主要过程的观点是，字节 → 字符

以经典“Man”为例：

字符	ASCII码	二进制
M	77 = 01001101₂	01001101₂
a	97 = 01100001₂	01100001₂
n	110 = 01101110₂	01101110₂
拼接成24位：01001101 01100001 01101110 → 010011010110000101101110

            

再看接下来。按6位重新切分 → 四组6位：

|010011|010110|000101|101110|
| | | | |
|001001|101100|001001|1110?，|

：查Base64索引表 → 对应字符：

索引	字符
18	T
38	W
5	F
46	u

✔ "Man"  ↔↕↗↘ 结果 TWFu

三、不足三字节如何补齐？——Padding 与‘=’标记说明

原始字节数	补齐后	输出字符数	标记

}
}

"M"





"M"





"M"





"M"

-->

'M'

TQ==

ad>
ad>
ad>
ad>
ad>
ad>
ad>
ad>
ad>
ad>
ad>
ad>
ad>
aD>
darkness?darkness，batch?batch，darkness?The darkness?，话说回来，The darkness?might，©

---

使用者痛点 - 忘记填充导致解码报错； 请务必检查末尾是否有 =。 - URL 中出现 + 或 /被转义为 %20 等，引起 JWT 验证失败；使用 URL 安全编码即可。- 直接将 Base64 当作加密导致安全误区；按理说，Base64 并非加密，只是可读编码。

---

四、“体积大了33%。我们还离不开它”的原因与典型场景举例：

. Data URI —— 把资源直接嵌进代码中：

<\/code>

A 小图标经 Base64 编码后 ~1.33KB，但省掉了一次 HTTP 请求。 话说回来，首屏关键资源优先级高于单纯体积。

. JWT —— 在 HTTP Header 中传递自包含令牌：

{
“alg”这方面。“HS256”,“typ”: “JWT”
}
{
至于“sub”，“1234567890”
}…eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
<\/code>

Kotlin / JS / Python 都需要把 Header 与 Payload 用 Base64URL 编码，以避免 +/ 被 URL 转义。解析错误由缺少这一步会导致。

. PEM 格式证书与密钥：

DER 二进制证书被包裹后可以安全复制粘贴到 GitHub Issue 或邮箱中，不担心乱码或换行导致损坏。

. JSON 中携带二进制字段：

{
"filename": "avatar.png"。"content": "iVBORw0KGgoAAAANSUhEUgAAADIA..."
}
<\/code>

BFF 前后端交互常用此方式，因为整个 JSON 序列化/反序列化链路都是文本处理。若直接放 raw binary 则需要额外协议支持。

. 邮件附件：早期网关仅支持7‑bit ASCII，所以强制采用 Base64 编码。即使现在支持多字节，也仍然依赖此机制来保证兼容性。

五、“什么时候不该用 Base64？”——给你一个判断清单：

/* 为了可读性使用纯列表 /

场景/业务需求类型

替代方案 原因 --> 微服务内部 RPC 通讯 *--> Protobuf / gRPC *--> 直接使用裸二进制流。无需额外编码 *--> -->

" """

原则 - 若双方都能处理裸二进制，则不要给自己添麻烦；- 对于大文件，Base64 会明显提高传输成本；- 对对象存储直接上传原始文件更经济。

---

go package main

import ( "encoding/base64" "fmt" )

func main { data := byte // 标准编码 encoded := base64.StdEncoding.EncodeToString fmt.Println // TWFu

// 解码
decoded,_ := base64.StdEncoding.DecodeString
fmt.Println) // Man
// URL 安全编码
urlSafe := base64.URLEncoding.EncodeToString)
fmt.Println // aGVsbG8rd29ybGQvdGVzdA==

}

* 两种编码器区别*:

/* 简洁对照表 */

标准 URL安全

+ vs - />

/ vs _` />

PADDING== 可选去掉。其实，`

JWT 用的是 base64.URLEncoding。因为标准 Base62 的 + 和 / 在 URL 中会被转义成 %2B 和 %2F，体积反而更大。

---

• \*\*原理\*\*: 将字节拆成每组6位，再查表映射成ASCII字符；不足部分通过填充 `=` 标记。
• \*\*代价\*\*: 大约 +33% 的体积膨胀。
• \*\*收益\*\*: 二进制数据可以无歧义、安全地跨越 JSON / XML / URL / 邮件 / 配置等文本渠道流通。
• \*\*原则\*\*: 对外兼容使用 Base62；对内性能优先考虑裸二进制或专门协议。若双方都能处理原始流，就别给自己加戏！* 使用者痛点回顾 *:
  • No padding ➜ 解码失败.
  * 领域经验提示 *:
  • MIME 协议仍旧依赖此机制.
  " }}

  ---

---