中文乱码本质是字符集链路断裂：mysql存utf8mb4，odbc unicode driver解码为utf-16，若用sql_c_char（char）接收，驱动会强制转为系统ansi（gbk），而“前”的utf-16码0x524d在gbk中无效，导致显示为鍘?；正确做法是用sql_c_wchar + wchar_t，并确保vs项目启用unicode字符集。
数据库操作中的中文乱码，几乎全是字符集链路断裂导致的——从数据库表定义、连接配置、驱动行为到C++变量接收，任一环节用错编码，就会在输出或日志里看到鍘?、??或空字段。不是代码写错了，是数据在某一层被错误转码了。
MySQL ODBC Unicode Driver 为什么把“前”变成“鍘?”
这是最典型的宽窄字符陷阱：MySQL 存的是 utf8mb4（UTF-8），ODBC Unicode Driver 内部正确解码成 UTF-16，但如果你用 SQL_C_CHAR（即 char*）去接，驱动会自动调用 WideCharToMultiByte(CP_ACP) 把 UTF-16 强制转成系统 ANSI（中文 Windows 默认是 GBK），而“前”的 UTF-16 是 0x524D，GBK 下这个码点根本不存在，于是转成两个无效字节，再被终端按 UTF-8 解读就变成 鍘?。
- 必须用
SQL_C_WCHAR+wchar_t*接收，跳过 ANSI 转换层 - 连接字符串里加
charset=utf8mb4只影响通信层，不改变驱动对应用层数据类型的处理逻辑 - VS 项目要设为“使用 Unicode 字符集”，否则
wchar_t可能被当作unsigned short处理，引发 ABI 不匹配
std::string 接 MySQL 返回的中文，为什么长度不对或内容截断？
std::string 本身不携带编码信息，它只是字节容器。当你用 SQL_C_CHAR 从 ODBC 读数据时，驱动返回的是 GBK 字节流（Windows），但你的代码把它当 UTF-8 处理——比如调用 utf8_to_wstring()，结果就是解码失败；或者直接 cout ，控制台又用 UTF-8 解 GBK 字节，双重错位。
- 确认你拿到的字节流真实编码：查 ODBC 驱动类型（ANSI/Unicode）、连接参数、目标字段字符集
- 不要对
std::string做“隐式 UTF-8 假设”，先用MultiByteToWideChar(CP_ACP, ...)或MultiByteToWideChar(CP_UTF8, ...)显式转换 - 如果数据库字段是
utf8mb4，且你用了 Unicode Driver，就该用wchar_t*+SQL_C_WCHAR，避免中间经过char*
跨平台项目里怎么避开 Windows 特有 API 还能读写中文？
硬写 SetConsoleOutputCP 或 MultiByteToWideChar 会导致 Linux/macOS 编译失败。但数据库层其实可以统一：只要确保整个链路走 UTF-8，就不依赖 Windows API。
- MySQL 服务端、表、连接全部设为
utf8mb4，连接字符串加charset=utf8mb4 - 用 MySQL C++ Connector（非 ODBC）替代，它原生支持 UTF-8 字符串，
sql::ResultSet::getString()直接返回std::string含 UTF-8 字节，无需额外转换 - Linux/macOS 终端默认 UTF-8，
std::cout 可直接输出；Windows 下只需提前执行 <code>chcp 65001或调用SetConsoleOutputCP(CP_UTF8)——用#ifdef _WIN32包裹即可 - 路径含中文时，
std::ifstream在 Windows 下无法处理 UTF-8 路径，必须用_wfopen或CreateFileW；Linux/macOS 无此限制
最容易被忽略的是：ODBC 的 SQL_C_CHAR 和 SQL_C_WCHAR 是两种完全不同的数据绑定协议，不是“多加个 L 就行”。选错类型，驱动就在你不知情时做了不可逆的编码转换，后续任何 std::string 操作都救不回来。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
