C++标准库不提供Base64编解码函数，需手写实现；采用静态查表法，每3字节转4字符，补‘=’填充，约50行可完成。
Base64 编码在 C++ 中没有标准库函数
标准 C++（C++11/14/17/20）不提供 base64_encode 或 base64_decode，必须自己实现或依赖第三方。别指望 <string></string> 或 <codecvt></codecvt>（后者已弃用且不支持 Base64）。常见误区是误用 std::codecvt_base64 —— 它根本不存在。
最轻量、可控、无依赖的做法是手写编码表 + 查表逻辑，约 50 行可跑通。
手写 Base64 编码：查表 + 分组处理
Base64 将每 3 字节（24 bit）拆成 4 组 6 bit，映射到 64 字符集（A–Z, a–z, 0–9, +, /），末尾补 = 表示填充。解码则反向操作。
- 编码前先定义静态字符表：
static const char table[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; - 输入字节数为
n，输出长度固定为((n + 2) / 3) * 4（向上取整到 4 的倍数） - 每次取 3 字节，不足则补 0；算出 4 个索引后，根据实际字节数决定是否把末尾的
'='写入 - 注意：输入为
const uint8_t*，避免符号扩展问题；输出用std::string构造时指定 size 避免多次扩容
示例关键片段：
立即学习“C++免费学习笔记（深入）”；
std::string base64_encode(const uint8_t* data, size_t len) {
static const char table[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
std::string out(((len + 2) / 3) * 4, '=');
for (size_t i = 0, j = 0; i < len; i += 3, j += 4) {
uint32_t val = (data[i] << 16) | ((i + 1 < len ? data[i + 1] : 0) << 8) | (i + 2 < len ? data[i + 2] : 0);
out[j] = table[(val >> 18) & 0x3F];
out[j + 1] = table[(val >> 12) & 0x3F];
out[j + 2] = (i + 1 < len) ? table[(val >> 6) & 0x3F] : '=';
out[j + 3] = (i + 2 < len) ? table[val & 0x3F] : '=';
}
return out;
}
Base64 解码：需校验非法字符和填充位置
解码比编码更易出错。不能简单跳过空白或换行 —— 标准 Base64（RFC 4648）只允许 A–Z/a–z/0–9/+// 和 =，其余字符（如空格、\n、_）都应视为错误，除非你明确支持变种（如 URL-safe Base64）。
- 先预扫一遍：遇到非 Base64 字符（不含
'='）直接返回空或抛异常 -
'='只能出现在末尾，且最多连续两个；若出现"A=BC"这类中间等号，就是非法输入 - 解码时每 4 字节一组，查表得 4 个 6-bit 值，拼成 3 字节；若遇到
'='，按数量丢弃末尾字节（1 个 = 丢 1 字节，2 个 = 丢 2 字节） - 查表建议用
std::array<int8_t></int8_t>预填充：非 Base64 字符设为 -1，避免std::string::find查表慢
别忽略边界与安全细节
真实项目中容易翻车的地方不是算法，而是这些：
- 输入指针为空或长度溢出（
size_t溢出导致极大值）—— 解码前加if (!data || len == 0)判断 - URL 场景下用的是 Base64URL（
'-'替'+'，'_'替'/'，省略'='），必须区分变种，不能混用 - 二进制数据含 \0 时，别用
strlen测长；用传入的len，这是唯一可信长度 - 若需高性能（如日志批量编码），考虑 SIMD 加速或查表分块，但普通场景纯查表已足够快
最常被跳过的一步：对解码结果做有效性验证 —— 比如解密前确认长度是否符合预期，或用原始数据哈希交叉核对。Base64 本身不防篡改，只是编码。
