C++实现简单的XOR字符串加密算法 _ 字符流位运算加解密逻辑【源码】-C++-PHP中文网

直接用std::string做xor加密易出错，因char在不同平台可能有符号，0xff会被解释为-1，整型提升后导致符号扩展和解密失败；应显式转unsigned char处理。

c++实现简单的xor字符串加密算法 _ 字符流位运算加解密逻辑【源码】

为什么直接用 `std::string` 做 XOR 加密容易出错？

因为 XOR 是按字节（unsigned char）运算的，而 C++ 中 char 在不同平台可能默认有符号——若某字节值为 0xFF，在有符号 char 下会被解释为 -1，再参与 ^ 运算时会先整型提升为负数，结果意外溢出或符号扩展，导致解密失败。

实操建议：

始终将字符串每个字节显式转为 unsigned char 再异或，避免隐式符号转换
密钥也需统一用 unsigned char 处理，哪怕它是 std::string 字面量
不要对 std::string 的 c_str() 指针直接做指针运算加解密，它不保证可写（尤其短字符串优化后）

如何安全地实现循环密钥 XOR 加密函数？

核心是「逐字节异或 + 密钥索引模长」，但必须控制类型和边界。下面是最小可靠实现：

std::string xor_encrypt(const std::string& plaintext, const std::string& key) {
    if (key.empty()) return plaintext;
    std::string out = plaintext;
    for (size_t i = 0; i (plaintext[i]);
        unsigned char k = static_cast<unsigned char>(key[i % key.size()]);
        out[i] = static_cast<char>(p ^ k);
    }
    return out;
}</char></unsigned>

注意点：

输入 plaintext 和 key 都按 const std::string& 传入，避免拷贝开销
输出先拷贝原串（out = plaintext），确保内存布局连续且可写
密钥为空时直接返回原文，防止 i % 0 崩溃
加解密函数完全相同——XOR 是自反操作，a ^ b ^ b == a

遇到中文或 UTF-8 字符时为何解密乱码？

不是算法错了，是误把 UTF-8 多字节当单字节处理。UTF-8 中一个汉字通常占 3 字节（如 0xE4 0xB8 0xAD），XOR 加密若对每个字节单独异或，解密时只要字节顺序不变，依然能还原——但前提是：你把它当原始字节流处理，而非“字符”。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

所以关键判断是：

如果你的数据源本身就是 UTF-8 编码的 std::string（比如从文件读入、网络接收），那就照常加密，解密后仍为合法 UTF-8，显示层负责解码
如果你用 std::wstring 或 char32_t 存 Unicode 码点，那不能直接套用这个函数——XOR 必须作用于最终存储的字节序列，而非抽象码点
调试时别用 std::cout 打印，二进制内容可能含控制字符，终端会截断或乱显；改用十六进制输出验证

加密后的字符串能直接存进 JSON 或写入文本文件吗？

不能，除非你明确转义。XOR 后的字节流大概率包含 \x00、\x0A、\x1F 等非打印、不可见甚至非法字符，JSON 解析器会报 invalid character，文本编辑器可能静默截断。

安全做法：

若需嵌入文本环境（如 JSON、INI、日志），务必先 Base64 编码加密结果，再存；解密前先 Base64 解码
若写入二进制文件（如 std::ofstream 以 std::ios::binary 打开），则可直接写 encrypted_str.data() 和 .size()
别尝试用 std::quoted 或手动转义——它只为可读性设计，不保证 JSON 兼容性

最易被忽略的一点：加解密逻辑本身很简单，但数据进出环节（编码、传输、存储）的上下文决定它是否真正可用。没处理好字节视图和文本视图的边界，再正确的 XOR 也会在第一步就失效。