std::hex 不能直接将字符串转为十六进制字符串，需逐字节处理：先将每个 char 转为 unsigned char 避免符号扩展，再转 int 后用 std::hex 输出两位十六进制。
std::hex 不能直接转字符串，得逐字节处理
很多人以为 std::hex 能像 Python 的 binascii.hexlify() 那样直接把 std::string 变成十六进制字符串，其实它只是控制输出流的整数格式。对字符串整体用 std::hex 没效果，必须遍历每个 unsigned char 元素，再分别转成两位十六进制数字。
关键点在于：字符串本质是字节序列，而 C++ 中 char 有符号性不确定，直接强转可能出负值（比如 0xFF 在有符号 char 下是 -1），导致 std::hex 输出异常（如 ffffffff）。所以必须先转成 unsigned char，再转 int。
- 错误写法：
os —— <code>s[i]是char，符号扩展会污染高位 - 正确写法：
os - 推荐用
std::format（C++20）：std::format("{:02x}", (unsigned char)c)，更安全简洁
UTF-8 字符串转 hex 时，别误以为“一个 char = 一个字符”
如果原始字符串含中文、emoji 等，且编码是 UTF-8（绝大多数现代场景默认如此），那么一个逻辑字符可能占多个字节。此时“字符串转 hex”实际就是把 UTF-8 编码后的字节流原样转成十六进制——这是正确的，也是唯一可逆的做法。
常见误区是试图先解码成 char32_t 再转 hex，这不仅多余，还会因 BOM、代理对、无效序列等问题引入复杂性。除非你明确需要 Unicode 码点层面的表示（比如调试字符集问题），否则直接按字节处理即可。
立即学习“C++免费学习笔记（深入）”；
-
"中"（UTF-8）是 3 字节：e4 b8 ad→ hex 字符串应为"e4b8ad" - 若用
wstring+std::codecvt_utf8（已弃用）强行转宽字符，代码臃肿且不可移植 - 跨平台安全做法：确认输入是 UTF-8 字节流，不做额外编码转换
性能敏感场景下，避免流操作和临时 string 拼接
用 std::ostringstream 或反复 += 拼接 std::string，在长字符串（如几 MB 的二进制数据）上会产生大量内存重分配和拷贝。实际项目中，尤其是网络协议打包、日志 dump 场景，建议预分配空间并用查表法加速。
十六进制字符只有 16 种，可用静态 const 数组做映射，每个字节拆高低 4 位，查两次表，比格式化函数快 3–5 倍。
- 查表示例：
static constexpr char hex_chars[] = "0123456789abcdef"; - 预分配：
result.reserve(input.size() * 2); - 核心循环：
result += hex_chars[b >> 4]; result += hex_chars[b & 0xf]; - 注意：
std::format（C++20）内部已优化，小数据量下可读性优先；大数据量仍建议手写查表
Windows 下处理 ANSI 字符串要小心默认编码陷阱
在 Windows 控制台或旧 API（如 GetCommandLineA）中拿到的 char*，其编码取决于当前系统 ACP（ANSI Code Page），比如中文 Windows 是 GBK。这时若直接转 hex，得到的是 GBK 字节流的十六进制表示——不是 UTF-8，也不是 Unicode。如果后续要和其他平台（如 Linux/UTF-8）交互，必须先明确是否需转码。
- 判断是否为 ANSI：看来源是否来自
MultiByteToWideChar(CP_ACP, ...)类接口 - 不推荐自动检测编码：无可靠方法区分 GBK/Big5/Shift-JIS
- 稳妥做法：业务层约定输入编码（如强制 UTF-8），或统一用宽字符接口（
std::wstring+WideCharToMultiByte(CP_UTF8, ...)）再转 hex - 错误示范：
std::string s = "你好"; /* 源文件保存为 UTF-8，但编译器按系统编码读入 */→ 结果不可控
实际最常被忽略的，是字符类型符号性与编码上下文的耦合——同一个 char 变量，在 Linux clang 编译的 UTF-8 环境里是字节，在 Windows MSVC 默认设置下可能是 GBK 片段，而 hex 转换本身只认字节。不厘清输入源的真实字节含义，转出来的十六进制串再漂亮也没法还原。
