Windows非Unicode语言设为韩语后，遗留C++程序PDF加载字体失败

DevOps 小满

2026-5-19

解决Windows 7遗留C++程序韩语环境下PDF字体加载失败的问题

我之前处理过不少Windows遗留程序的本地化兼容问题，你遇到的这个情况很典型——当系统「非Unicode程序语言」切换到韩语时，pdf.load_font返回-1，核心原因是系统语言环境改变了默认的字体查找规则，尤其是遗留C++程序依赖的ANSI字体映射逻辑，在韩语环境下和英语环境完全不同。

下面是几个针对性的解决思路，按优先级推荐：

直接指定字体文件路径（最稳妥）
别让PDF库自动猜字体，直接传入系统字体的绝对路径，比如Windows自带的支持多语言的Malgun Gothic（韩语常用字体）或者通用的Arial。这样不管系统语言怎么切换，都能精准定位到字体文件。示例代码：
```
// 加载Malgun Gothic字体（支持韩语）
int pdf_font = pdf.load_font("C:\\Windows\\Fonts\\malgun.ttf", 0);
// 或者加载Arial（英语环境常用，也支持基本韩语显示）
// int pdf_font = pdf.load_font("C:\\Windows\\Fonts\\arial.ttf", 0);
```
注意：不同Windows版本的字体文件名可能有细微差异，比如有些版本的Malgun Gothic是malgunbd.ttf（粗体），可以在C:\Windows\Fonts目录下确认实际文件名。
避免依赖本地化的字体名称
如果你的代码是通过字体名称（比如"Arial"）加载的，在韩语系统中，系统返回的字体名称可能是本地化的（比如Arial的韩语标注名），导致PDF库匹配失败。可以用Windows APIEnumFontFamiliesEx枚举系统中所有可用字体，获取字体的英文名称或者内部标识符，再用这个准确名称来加载。
举个简单的枚举思路：
```
// 用EnumFontFamiliesEx遍历字体，筛选目标字体的正确名称
LOGFONT lf = {0};
lf.lfCharSet = DEFAULT_CHARSET;
EnumFontFamiliesEx(GetDC(NULL), &lf, (FONTENUMPROCA)EnumFontProc, 0, 0);
```
在回调函数EnumFontProc里，你可以提取ENUMLOGFONTEX结构体中的elfFullName（完整字体名），找到你需要的字体后记录下来，再传入pdf.load_font。
强制程序使用特定代码页/区域设置
对于遗留C++程序，可以在启动时强制设置线程的区域为英语，或者切换到UTF-8代码页，避免系统韩语环境影响字符串解析。示例代码：
```
// 设置线程区域为英语（美国）
SetThreadLocale(MAKELCID(MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US), SORT_DEFAULT));
// 强制使用UTF-8代码页（如果PDF库支持）
SetConsoleOutputCP(CP_UTF8);
SetConsoleCP(CP_UTF8);
```
这个方法要注意兼容性，可能会影响程序其他模块的文本显示，建议先小范围测试。
检查PDF库的字体加载逻辑
有些老旧的PDF库在非Unicode环境下，会依赖系统的ANSI代码页（韩语是949，英语是1252），导致无法正确解析字体名称。可以查看PDF库的官方文档，是否有参数可以指定字体查找的代码页，或者强制启用Unicode字体加载模式。

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