不能直接对std::string整体用~操作，因其是容器而非整数类型，编译报错；必须逐字节转unsigned char再取反，避免符号扩展错误，且加解密逻辑相同。
字符串按位取反加密为什么不能直接用 ~ 对 std::string 整体操作
因为 std::string 是容器，不是整数类型；~ 只能作用于整型（如 char、unsigned char），对 std::string 直接取反会编译报错：invalid operand of type 'std::string'。必须逐字节处理，且要注意符号扩展问题。
常见错误是把 char 当作有符号类型直接取反后存回，比如：
std::string s = "abc"; for (auto& c : s) c = ~c; // 危险：c 是 signed char，~'a' → 0xFFFFFF9E，在赋值时可能截断或引发未定义行为
- 务必用
unsigned char中转：先转成unsigned char，取反，再转回char（或直接存为unsigned char） - 若原始字符串含
\0，加密后仍可安全保存——std::string支持嵌入空字符，不依赖 C 风格字符串终止 - 不要用
std::string::c_str()后再取反，那只是只读视图，修改无效
如何安全实现可逆的按位取反加解密函数
按位取反是自反操作（~~x == x），所以加解密可用同一段逻辑。关键在于统一数据解释方式，避免平台相关性。
推荐写法：
立即学习“C++免费学习笔记（深入）”；
void bitwise_invert(std::string& s) {
for (unsigned char& c : reinterpret_cast<std::string::value_type*&>(s)) {
c = ~c;
}
}
但更清晰、更安全的做法是显式转换：
void bitwise_invert(std::string& s) {
for (char& c : s) {
unsigned char uc = static_cast<unsigned char>(c);
uc = ~uc;
c = static_cast<char>(uc);
}
}
- 用
static_cast显式转换，不依赖隐式提升，避免在不同编译器上行为不一致 - 不要用
(unsigned char)c这种 C 风格转换，易被误读且不检查范围 - 如果字符串来自网络或文件，且已知编码为 UTF-8，注意：按位取反会破坏 UTF-8 编码结构，解密后需原样还原字节流，不可当作合法 UTF-8 解析——它只是字节混淆，不是文本加密
为什么加密后字符串长度不变但内容可能显示异常
按位取反改变每个字节的值，例如 'A'（0x41）→ 0xBE，这个值在 ASCII 或 UTF-8 中通常不可见或为控制字符。终端打印会显示乱码、方块或空白，但这不影响二进制一致性。
-
std::string.size()加密前后完全一致，无内存重分配 - 若后续要 Base64 编码传输，应在取反后做 Base64，而不是先 Base64 再取反（后者会破坏 Base64 字符集）
- 调试时用十六进制打印验证是否可逆：
printf("%02x ", (unsigned char)s[i]); - 某些 IDE 或日志系统会自动过滤或替换非打印字符，导致“看不到变化”，实际字节已变
跨平台兼容性需要注意的两个细节
Windows 和 Linux 下 char 默认可能是 signed 或 unsigned，取决于编译器和 ABI。虽然 C++ 标准未规定，但实际中 Clang/GCC 在 x86_64 Linux 默认 char 为 signed，MSVC 在 Windows 也是 signed —— 但这不保证未来不变。
- 永远不要假设
char的符号性；所有涉及位运算的场景，必须显式转成unsigned char - 若用
std::vector<:byte></:byte>（C++17），更语义清晰：std::byte是无符号、无符号算术语义的底层字节类型，推荐用于此类混淆操作 - 加密后的字符串若写入文件，务必以二进制模式打开（
std::ios::binary），否则 Windows 下\r\n转换会破坏字节
混淆本身不提供安全性，只防简单文本扫描；真正需要保密请用 AES 等标准算法。按位取反的陷阱不在逻辑，而在类型细节和上下文环境——一个 unsigned 丢掉，整个还原就错。
