Win32 + ImGui 桌面端开发：窗口名字符乱码终极避坑指南

坑一：ImGui 中文完美，窗口标题却变成“貧慱騤”？

【案发现场】
在通过 ImGui 加载了 msyh.ttc（微软雅黑）后，软件内部的 UI 中文显示极其完美。但是，当我试图用 CreateWindowW 创建母窗口并传入中文标题时：

HWND hwnd = CreateWindowW(wc.lpszClassName, L"高频惯导标定系统", ...);

窗口左上角的标题却显示成了类似“貧慱騤”的生僻字乱码。

【底层尸检】
罪魁祸首是编译器对源文件编码的“自作聪明”。
我的 .cpp 文件是 UTF-8 编码。当 GCC 编译器看到 L"..." 宏时，它试图把源文件转换成宽字符，但由于 Windows 默认区域设置（GBK），它错误地将纯正的 UTF-8 字节（如“高”字的 E9 AB）查了 GBK 字典，强行拼凑出了“貧”等毫无关联的汉字。

【破局之道】
永远不要相信编译器的 L 宏，在运行时通过 Windows 原生 API 进行动态转换！

#include <string>
#include <windows.h>

// --- 运行时 UTF-8 转 UTF-16 宽字符的核心函数 ---
std::wstring Utf8ToWide(const std::string& utf8Str) {
    if (utf8Str.empty()) return L"";
    int size_needed = MultiByteToWideChar(CP_UTF8, 0, utf8Str.c_str(), -1, NULL, 0);
    std::wstring wstr(size_needed - 1, 0);
    MultiByteToWideChar(CP_UTF8, 0, utf8Str.c_str(), -1, &wstr[0], size_needed - 1);
    return wstr;
}

调用方式： Utf8ToWide("高频惯导标定系统").c_str()。这样纯正的 UTF-8 将直接由系统翻译，绝对精准。

坑二：退而求其次用英文标题，“High” 却被腰斩成了 “H”？

【案发现场】
既然中文这么折腾，我妥协了，直接传英文宽字符总行了吧？

HWND hwnd = CreateWindowW(wc.lpszClassName, L"High-Frequency System", ...);

结果编译一跑，好家伙，那么长一串英文，窗口标题只剩下一个孤零零的字母 “H”。

【底层尸检】
这是 MSYS2 MinGW GCC 开发环境独有的“幽灵大坑”！

• 在 Linux/POSIX 标准里（GCC 默认行为），宽字符 wchar_t 是 4 个字节！
• 在 Windows 底层 API 的眼里，宽字符是 2 个字节（UTF-16）！

当 GCC 编译 L"High" 时，字母 “H” 被编译成了 4 字节：0x48 0x00 0x00 0x00。
Windows 的 CreateWindowW 拿过内存，按 2 字节一读：
第一次读到 0x48 0x00（“H”），完美。
第二次读到紧接着的 0x00 0x00，Windows 瞬间判定：“连续两个 0，字符串结束了（Null Terminator）！” 直接触发截断！

【破局之道】
放弃依赖环境的 wchar_t，要么使用严格锁定 2 字节的 char16_t，要么坚持使用坑一中的 Utf8ToWide 动态转换纯 char 字符串。

坑三：终极 Boss —— 精神分裂的 Win32 消息循环

【案发现场】
即使我使用了最完美的 Utf8ToWide 甚至直接硬编码了 UTF-16 十六进制数组，窗口标题依然是乱码。
【底层尸检】
这是 Windows C++ 桌面开发最容易忽视的致命盲区。在没有全局配置 -DUNICODE 编译宏的情况下，如果你混用了 W（宽字符）和 A（ANSI窄字符）API，窗口就会“精神分裂”。

我的窗口是用 CreateWindowW 创建的（声明为 UTF-16 窗口）。但是在底层的消息循环中，我却使用了默认的宏：

// 致命错误：因为没定义 UNICODE，宏自动展开成了 DefWindowProcA
return DefWindowProc(hwnd, msg, wParam, lParam);

当系统需要重绘标题栏（发送 WM_GETTEXT 消息）时，它用 A 版本的处理逻辑去强行读取我们传入的 W 版本的 UTF-16 内存指针，把双字节当单字节劈开解析，必然引发毁灭性的乱码！

【终极防御指南（正确代码演示）】
必须将底层消息循环的**“四大管道”全部焊死为 W 版本**，彻底纯化宽字符血统：

// 1. 窗口回调函数中，必须使用 DefWindowProcW
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) {
    if (ImGui_ImplWin32_WndProcHandler(hwnd, msg, wParam, lParam)) return true;
    switch (msg) {
        case WM_DESTROY: PostQuitMessage(0); return 0;
    }
    // 【关键防御点】
    return DefWindowProcW(hwnd, msg, wParam, lParam); 
}

int WINAPI WinMain(...) {
    // 2. 注册和创建窗口必须带 W
    WNDCLASSEXW wc = { /*...*/, WndProc, /*...*/, L"ImGui Example", nullptr };
    RegisterClassExW(&wc);

    std::wstring window_title = Utf8ToWide("高频惯导数据后处理与多维精度标定系统 v1.0");
    HWND hwnd = CreateWindowW(wc.lpszClassName, window_title.c_str(), /*...*/);

    // 3. 消息循环必须带 W
    MSG msg;
    while (!done) {
        // 【关键防御点】
        while (PeekMessageW(&msg, nullptr, 0U, 0U, PM_REMOVE)) {
            TranslateMessage(&msg);
            DispatchMessageW(&msg); // 【关键防御点】
            if (msg.message == WM_QUIT) done = true;
        }
        // ... ImGui 渲染逻辑 ...
    }
}

总结

在现代 C++ GUI 开发中，尤其是结合 GCC 和 Win32 API 时，永远不要轻信默认的宏展开，永远要明确你操作的内存是单字节、UTF-8 还是 UTF-16。
经历了这轮底层的毒打，当带有完美中文字体、高清行业图标的母窗口稳稳地钉在屏幕上时，你会发现，软件工程的魅力，恰恰就在于驯服这些底层怪兽的过程。