Base64URL编码字符串由A-Z、a-z、0-9、-、_组成，长度为4的倍数，填充符=仅可出现在末尾且数量为0~2个；示例为aGVsbG8、eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。
Base64URL编码的字符串长什么样？
Base64URL 是 Base64 的变种，主要为 URL 和文件名安全而设计：它用 - 替代 +，用 _ 替代 /，且不带填充字符（=）或可选带 0~2 个 =（RFC 4648 §5）。但实际中，很多 Base64URL 实现（如 JWT 的 payload/header）会省略填充，所以判断时不能强依赖 =。
常见合法 Base64URL 字符串示例：ABcd12_Ef、aGVsbG8、eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
非法示例：abc+def/（含 + 和 /）、ab==c（= 出现在中间）、ab=（长度模 4 不为 0 且含 =）
如何用C++做快速、安全的格式校验？
只校验格式（不 decode）是最快最稳妥的第一步。重点检查三件事：
- 字符集：每个字符必须是
A-Z、a-z、0-9、-或_ - 长度：必须是 4 的倍数（因为 Base64 每 4 字符编码 3 字节；Base64URL 继承该约束）
- 填充：如果出现
=，只能在末尾，且数量只能是 0、1 或 2；同时长度仍需满足模 4 == 0
bool is_base64url_format(const std::string& s) {
if (s.empty()) return false;
size_t pad = 0;
for (size_t i = 0; i < s.length(); ++i) {
char c = s[i];
if (c == '=') {
if (i < s.length() - 2) return false; // = 不能在倒数第 2 位之前
pad++;
} else if (!std::isalnum(c) && c != '-' && c != '_') {
return false;
}
}
if (pad > 2) return false;
if ((s.length() % 4) != 0) return false; // 关键：无论有无 =，长度必须是 4 的倍数
return true;
}
注意：std::isalnum 在不同 locale 下行为可能不同，建议显式比对字符范围，或用 unsigned char 转换避免 signed char 问题。
为什么不能只靠格式校验就断定“是Base64URL”？
格式合法 ≠ 实际可解码。例如：AAAA 格式合法，但 decode 后是 3 字节二进制数据，这没问题；而 AA=A 格式非法（已由上一步拦截）；但更隐蔽的是：AAAZ 格式合法，却无法 decode——因为 Z 不在 Base64URL 字母表里（Base64URL 字母表是 A–Z, a–z, 0–9, -, ，共 64 个，Z 虽然属于 A-Z，但它在标准 Base64 中是第 51 位，Base64URL 完全复用这个映射，所以 Z 是合法字符；真正非法的是像 AA!A 这种非字母数字且非 -/ 的字符）。
立即学习“C++免费学习笔记（深入）”；
所以，若业务需要确认“真能 decode”，必须走实际 decode 流程，并捕获无效字符或长度异常（比如最后 4 字节中出现 1 个 = 时，前 3 字符必须能映射到 24 位有效比特）。
要不要尝试 decode 来验证？
取决于你的场景：
- 如果只是过滤输入（如 JWT token 分段），格式校验 + 长度检查已足够，decode 属于冗余开销
- 如果要解析内容（如读取 JWT payload），那就必须 decode，且要用严格模式：遇到非法字符、非法填充位置、或 decode 后字节数不是 3 的倍数（原始数据长度），都应拒绝
C++ 没有标准 Base64URL 解码函数，需自己实现或借助库（如 OpenSSL 的 EVP<em>DecodeBlock</em> 需先将 -/ 替换为 +//，再处理填充）。自己实现时，查表建议用 256 元素的 char lookup[256]，把非法字符设为 -1，A→0，Z→25，a→26…_→63，这样单字节查表 O(1)，比字符串 find 快得多。
容易被忽略的一点：Base64URL 编码后的字符串，其原始数据长度可能为 0（即空字符串 encode 后是空串），但空串在格式校验中会被 s.empty() 拦住——如果你允许空输入，得单独放开这个判断。
