Base64解码前需先用XML解析器提取节点文本并清理空白及实体（如=），再选用严格校验填充的解码库；解密前须确认密钥、IV、算法参数与服务端完全一致，并分层捕获异常、校验明文格式。
Base64 解码前先确认 XML 中的编码边界
XML 里混 Base64 数据，最常踩的坑是直接对整个 <data> 标签内容调用解码函数，结果报 invalid character 或解出乱码。根本原因是：XML 解析器可能已做转义（比如把 + 变成 +），或数据被换行/缩进污染。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用标准 XML 解析器（如
pugi::xml_document或tinyxml2）提取<attachment>节点文本，再调用node.text().get()获取原始字符串 - 手动清理空白字符：
std::erase_if(str, ::isspace)（C++20）或遍历过滤'\n''\r''\t'' ' - 检查是否含 XML 实体：若含
=（即=的数字实体），需先用简单映射还原；+和/一般不会被转义，但=常被转成=
选对 Base64 解码实现，避免内存越界和填充错误
C++ 没有标准 Base64 库，手写易错，第三方库又容易引入不兼容行为。常见错误是忽略填充符 = 的校验，或把 3 字节输入当 4 字节处理，导致解码后长度不对、末尾字节错乱。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 优先用
boost::beast::detail::base64::decode（轻量、无依赖、严格校验填充）或openssl EVP_DecodeBlock（需注意它不接受带填充的输入，得先截掉=） - 若用自研解码，必须验证输入长度 % 4 == 0，且末尾最多两个
=；解码缓冲区大小按input_len * 3 / 4分配，别硬写固定大小数组 - 解码返回值务必检查：OpenSSL 返回实际字节数，Boost Beast 返回
std::pair<bool, std::size_t>，first == false表示非法字符
解密前确认密钥、IV 和算法参数与服务端完全一致
Base64 解码后得到的是密文二进制流，但 AES/CBC 解密失败往往不是代码问题，而是参数对不上：比如服务端用 PKCS#7 填充、你用了 PKCS#5；或 IV 是从 Base64 单独字段给的，却被误拼到密文里一起解码。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 把密钥和 IV 都当作独立 Base64 字段解析（例如
<key>和<iv>），别从同一段数据里“截取” - 确认加密模式：CBC 必须配 IV，GCM 必须配 nonce + auth tag；OpenSSL 的
EVP_aes_128_cbc不会自动处理填充，得自己调EVP_CIPHER_CTX_set_padding(ctx, 1) - 密钥长度必须匹配算法：AES-128 要 16 字节密钥，若 Base64 解码后是 32 字节，说明可能是 hex 字符串而非 raw bytes，得先 hex-decode
XML 解析 + Base64 + 解密串联时的异常传播要分层捕获
一连串操作（XML parse → extract text → Base64 decode → AES decrypt）里任何一步失败，都可能导致程序崩溃或静默返回空结果。尤其在嵌入式或服务端场景，没日志很难定位是 XML 结构错、Base64 脏数据，还是密钥过期。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 每步单独 try/catch，抛出带上下文的异常，例如：
throw std::runtime_error("Base64 decode failed on node 'attachment': " + base64_str.substr(0, 20)) - 解密后立刻校验明文格式：比如预期是 ZIP，就检查前 4 字节是否为
PK\x03\x04；是 JSON 就用jsoncpp尝试 parse，失败则说明解密错而非数据本身坏 - 不要复用同一块 buffer：Base64 解码输出和 AES 解密输入/输出必须分离，否则 CBC 模式下 IV 被覆盖会导致后续块全错
真正卡住人的地方，往往是 XML 实体转义和 Base64 填充校验这两个环节——它们不出错时不显眼，一出错就全链路静默失败，而且调试时看不到原始传输字节流。留一手：把 Base64 字符串原样存文件，用命令行 base64 -d 对照验证，比在代码里加断点快得多。
