不能直接对std::string用~操作，因其是容器而非整型；必须逐字节转unsigned char再取反，否则符号扩展致错；混淆与还原共用同一函数，仅防静态扫描，不保证UTF-8可读性。
字符串按位取反加密为什么不能直接用 ~ 对 std::string 操作
因为 std::string 是容器，不是单个整数；~ 是位运算符，只能作用于整型（如 char、unsigned char）。直接对 std::string 用 ~ 会编译失败——C++ 不支持对类类型重载该操作符用于整体取反。
真正要做的，是对每个字节（char）做按位取反。但要注意：char 在多数平台默认是有符号的，~'A'（即 ~65）结果是 -66，再存回 std::string 可能被截断或引发符号扩展问题。
- 务必把每个字符先转成
unsigned char，再取反，最后转回char（或保持为unsigned char存入std::vector<uint8_t></uint8_t>更安全） - 不要用
std::string直接存储二进制数据——它不是为 binary-safe 设计的；若必须用，确保不包含\0且不调用依赖 C-string 的接口（如c_str()后传给 C 函数） - 加密和解密是同一操作：对同一字节两次取反得到原值，所以加解密函数可共用
如何安全实现加密函数：避免符号陷阱和空字符截断
下面是一个最小可行的加密函数，输入输出均为 std::string，但内部全程用 unsigned char 处理：
std::string bitwise_not(const std::string& s) {
std::string out = s;
for (char& c : out) {
c = static_cast<char>(~static_cast<unsigned char>(c));
}
return out;
}
关键点：
立即学习“C++免费学习笔记（深入）”；
-
static_cast<unsigned char>(c)</unsigned>防止负值参与位运算（例如char(-1)转unsigned char得255，~255 == 0） -
static_cast<char>(...)</char>是为了兼容std::string的char类型，但注意：如果取反后高位为 1（如原值0→255→char(255)），在有符号char下表现为负值，这本身没问题——只要不拿它当数字用，只作字节容器即可 - 该函数可直接用于解密：对密文再调一次
bitwise_not就还原
遇到中文或 UTF-8 字符串时会出什么问题
UTF-8 是变长编码，一个汉字通常占 3 字节（如 "中" → \xe4\xb8\xad）。按位取反会破坏每个字节的 UTF-8 标志位，导致解码失败或显示乱码——这不是 bug，而是设计如此：这种混淆不保证语义可逆，只保证字节级可逆。
- 如果你的目标是“让字符串不可读但能还原”，那没问题；但别指望还原后还能被文本编辑器/终端正常显示中文
- 若需支持多字节字符的安全混淆，应先转为固定宽度编码（如 UTF-32），逐
uint32_t取反，再转回 UTF-8 ——但这已超出“按位取反”本意，且增加复杂度 - 实际场景中，这类混淆常用于硬编码字符串防静态扫描，而非通用文本加密，所以通常只处理 ASCII 或已知纯 Latin-1 字节流
性能与边界情况：空字符串、嵌入 \0、跨平台差异
这个操作是 O(n)，无内存分配（除了返回拷贝），非常快。但有几个容易忽略的实际细节：
-
std::string允许含\0，但若你后续用.c_str()传给 C 接口（如printf("%s", s.c_str())），会提前截断——这不是加密的问题，是std::string和 C-string 语义冲突 - Windows 和 Linux 下
char默认符号性一致（通常 signed），但 C++ 标准未强制；稳妥起见始终显式转unsigned char - 若字符串超大（如几 MB），考虑用
std::string_view输入 + 输出到预分配的std::string& out引用，避免重复拷贝
最简健壮写法就是老老实实遍历每个 unsigned char，别试图用 SIMD 或 STL 算法简化——可读性和正确性比省几个指令重要得多。
