启用多字节字符集的遗留MFC应用能否无需全量迁移至Unicode支持UTF-8编码？

Boost.Locale与现有多字节配置的适配性 #

• 完全适配，不会和你当前的多字节字符集配置产生冲突
  • Boost.Locale是独立的编码转换工具库，本身不绑定项目的UNICODE/_UNICODE编译宏，你维持原有MFC“使用多字节字符集”的项目设置即可正常使用
  • 仅需在需要处理UTF-8的少量函数内，显式指定编码参数完成转换即可：比如将应用内部的CString（多字节模式下为系统ANSI代码页字符串，中文环境通常对应GBK/GB18030编码）转为UTF-8格式用于外部交互，或是将外部传入的UTF-8字符串解析为应用内部可直接使用的多字节格式
  • 注意使用时不要依赖Boost.Locale默认的隐式区域编码匹配逻辑，显式传入源、目标编码参数即可避免和现有MFC逻辑产生乱码冲突

无需全局迁移Unicode的替代实现方案 #

所有方案的核心逻辑是仅在与外部交互的边界位置做编码转换，全程不修改项目全局字符集配置，完全不影响现有遗留Windows API的调用：

• 方案一：Windows原生API封装（零依赖，优先推荐）
  • 直接调用系统内置的两个转换API，编写极薄的封装函数即可满足需求：
    • 生成UTF-8字符串：将应用内部的多字节字符串，通过MultiByteToWideChar以CP_ACP（当前系统ANSI代码页）为参数转为临时宽字符串，再通过WideCharToMultiByte以CP_UTF8为参数输出UTF-8格式
    • 解析UTF-8字符串：将外部传入的UTF-8字符串，通过MultiByteToWideChar以CP_UTF8为参数转为临时宽字符串，再通过WideCharToMultiByte以CP_ACP为参数转为应用内部可直接使用的多字节字符串
  • 该方案不需要引入任何第三方库，转换效率最高，和现有遗留API的适配性最好，几乎没有额外的编译和运行开销
• 方案二：轻量UTF-8专用库
  • 如果需要额外的UTF-8格式合法性校验、字符遍历等能力，可以选择单头文件的轻量UTF-8处理库，仅需引入少量头文件即可使用，不会像引入Boost.Locale那样带来较大的工程依赖

实施注意事项 #

• 应用内部的所有字符串处理、多字节版本的Windows API调用（如CreateFileA、MessageBoxA、注册表操作等）全部保持原有逻辑不变，仅在跨系统交互的边界点做编码转换即可
• 全程不需要将项目切换为Unicode编译模式，从根本上规避全局改造的高工作量和高风险

内容的提问来源于stack exchange，提问作者rahul