按位取反混淆仅破坏可读性而不加密，需用 unsigned char 中转避免符号扩展，还原即再次取反，但会生成'\0'导致截断，不可用于UTF-8或生产环境加密。
字符串按位取反混淆会破坏可读性但不加密
直接对字符串每个字节做 ~ 运算（即按位取反）是最简混淆手段，它不提供任何密码学强度，仅能防止文本被一眼识别。这种操作本质是将每个 char 视为 8 位无符号整数后取反，结果可能产生不可见字符、控制符甚至空字符 '\0'，导致 std::string 截断或输出异常。
关键点在于：C++ 中 char 有符号性未定义，~c 的结果依赖于编译器对 char 符号的解释。若 char 是有符号类型（如 MSVC 默认），~'\x01' 得到 -2，再存入 std::string 时会被截断为低 8 位（即 0xFE），但打印或比较时仍可能因符号扩展出错。
- 务必用
unsigned char中转：先转成unsigned char，再取反，再转回char存储 - 混淆后字符串长度不变，但内容不可直接
std::cout <<—— 可能含'\0'或非打印字符 - 不要用于跨平台二进制传输，不同系统对
char符号处理一致即可，但序列化时建议用 base64 包装
混淆函数必须显式处理符号扩展
错误写法：for (auto& c : s) c = ~c; —— 若 s 是 std::string，c 是 char&，~c 先提升为 int，再截回 char，符号不确定。
正确做法是强制以 8 位无符号视角运算：
立即学习“C++免费学习笔记（深入）”；
void obfuscate(std::string& s) {
for (char& c : s) {
unsigned char uc = static_cast<unsigned char>(c);
c = static_cast<char>(~uc);
}
}
还原只需再执行一遍相同逻辑（因为 ~~x == x）：
void deobfuscate(std::string& s) {
obfuscate(s); // 复用即可
}
-
static_cast<unsigned char>避免符号扩展干扰位运算 - 不能用
std::vector<uint8_t>替代std::string后直接操作 —— 虽然更安全，但与 C 风格字符串兼容性下降 - 若字符串含 UTF-8 多字节字符，此方法会破坏编码 —— 它只适合 ASCII 或已知单字节编码的场景
遇到空字符 '\0' 必须改用 std::vector<char>
std::string 允许包含 '\0'，但所有基于 C 风格字符串的接口（如 c_str()、printf("%s", s.c_str())、某些日志库）会在首个 '\0' 处截断。按位取反后，原 '\xFF' 变成 '\x00'，极易触发该问题。
解决方案不是避免生成 '\0'（无法避免），而是绕过 C 字符串语义：
- 始终用
std::string::data()+size()传递数据，而非c_str() - 调试打印时用循环输出十六进制：
for (auto c : s) printf("%02x ", (unsigned char)c); - 若需序列化/网络传输，混淆后立即 base64 编码，还原前先解码
性能几乎无开销，但别误当加密用
该操作是纯内存遍历，每个字节一次异或（^ 0xFF 等价于 ~），现代 CPU 下吞吐可达 GB/s。但它的脆弱性极明显：
- 明文和密文长度完全一致，且任意字符映射固定：
'A'→'\x5E'，永远不变 - 只要拿到一对明文-密文样本，就能反推出整个映射表
- 静态分析工具（如
strings命令）加-e l（little-endian UTF-16）参数仍可能扫出部分可读片段
真正需要保密时，必须用 AES 或 ChaCha20；这个“混淆”只适合临时隐藏硬编码字符串，比如防止被快速 grep 出口令字面量。一旦进入生产环境或涉及用户数据，它连入门门槛都算不上。
