它们共同解决的问题
计算机以二进制形式存储一切——字节序列，值范围 0 到 255。当需要在只处理可打印文本的系统（如电子邮件正文、JSON 字段、URL 参数、cookie）中传输或存储二进制数据时，必须先对其进行编码。
Base64 和十六进制是两种最常见的解决方案。它们解决相同的问题，但做出了不同的权衡。
Hex 编码的工作原理
十六进制使用 16 个字符：0-9 和 a-f。每个字节（0-255）映射为两个十六进制字符，因为 256 等于 16 的平方。
"Hi" → bytes: 72, 105 → hex: 48 69 → "4869"
大小开销：每个字节变成 2 个字符，因此十六进制编码数据的大小恰好是原始数据的 2 倍。
字符集 [0-9a-f] 在几乎所有上下文中都是安全的——URL、文件名、终端输出、数据库字段、日志文件。
Base64 编码的工作原理
Base64 使用 64 个字符：A-Z、a-z、0-9，以及 + 和 /（= 用于填充）。每 3 个输入字节映射为 4 个 Base64 字符。
"Hi!" → bytes: 72, 105, 33 → base64: "SGkh"
大小开销：3 个字节变成 4 个字符，因此 Base64 比原始数据大约 大 33%（相比之下，十六进制开销为 100%）。对于图像或文件等大型负载，这种差异是显著的。
并排比较
| 属性 | Hex | Base64 |
|---|---|---|
| 使用的字符 | 0-9, a-f（16 个字符） | A-Z, a-z, 0-9, +, /（64 个字符） |
| 大小开销 | +100%（原始大小的 2 倍） | +33%（大约原始大小的 4/3） |
| 人类可读性 | 字节值可见 | 不可读 |
| 默认 URL 安全 | 是 | 否（+ 和 / 需要转义） |
| URL 安全变体 | — | Base64url：使用 - 和 _ |
| 常见用例 | 校验和、哈希、颜色 | 图像、文件、JWT、电子邮件 |
何时使用 Hex
校验和与哈希——SHA-256、MD5 以及大多数哈希函数按惯例输出十六进制。运行 sha256sum 会得到一个 64 字符的十六进制字符串。该格式可读性足够，可以直观地比较前 8 个字符。
颜色代码——CSS 颜色如 #ff6600 是十六进制：R=ff (255), G=66 (102), B=00 (0)。
二进制协议调试——检查原始网络数据包或文件头时，十六进制显示精确的字节值。xxd、hexdump 和 Wireshark 等工具默认使用十六进制。
数据库 ID 和令牌——许多系统将 UUID 存储为 32 字符的十六进制字符串。十六进制紧凑且 URL 安全，无需转义。
// Node.js：以十六进制形式输出哈希
const hash = crypto.createHash('sha256').update(data).digest('hex');
// Node.js：以十六进制形式生成随机令牌
const token = crypto.randomBytes(32).toString('hex'); // 64 字符
何时使用 Base64
在文本格式中嵌入二进制数据——JSON 没有二进制类型。在 JSON 字段中存储图像、证书或文件需要使用 Base64。对于大型负载，较低的大小开销很重要。
电子邮件附件——自 1990 年代初以来，电子邮件附件的 MIME 编码一直使用 Base64。
JWT（JSON Web Token）——JWT 头部和负载使用 Base64url 编码。可以通过按 . 分割并对每个部分进行 Base64 解码来解码 JWT——无需密钥即可读取声明。
数据 URI——直接在 CSS 或 HTML 中嵌入图像使用 Base64：data:image/png;base64,iVBOR...
TLS 证书——PEM 格式（-----BEGIN CERTIFICATE----- 格式）是 Base64 编码的 DER 数据。
// Node.js：编码为 Base64
const encoded = Buffer.from(binaryData).toString('base64');
// 用于 JWT 和 URL 的 URL 安全 Base64
const urlSafe = encoded.replace(/+/g, '-').replace(///g, '_').replace(/=/g, '');
URL 安全性：一个实际问题
标准 Base64 使用 + 和 /，这两个字符在 URL 中都有特殊含义（+ 表示空格；/ 是路径分隔符）。如果需要在 URL 查询参数中使用 Base64，要么进行百分号编码，要么切换到 Base64url 变体（RFC 4648）：将 + 替换为 -，/ 替换为 _，并去掉 = 填充。
十六进制没有这个问题——字符 0-9a-f 在任何上下文中都是 URL 安全的。
快速决策指南
- 表示 哈希或校验和？→ Hex
- 在 JSON、HTML 或电子邮件中 嵌入文件或图像？→ Base64
- 构建 JWT 或 OAuth 令牌？→ Base64url
- 在字节级别 调试二进制数据？→ Hex
- 在 URL 中 存储随机字节作为令牌？→ Hex（更简单）或 Base64url（更短）
- CSS 颜色代码？→ Hex（通用标准）
→ 尝试 Base64 String Converter 即时编码和解码，或使用 Hash Text Tool 获取十六进制编码的哈希。