Repository navigation
Windows 解压包含 UTF-8 路径的归档时因多字节代码页转换失败 #516
Description
Activity
- added a commit that references this issue
on Aug 27, 2026 已在 mcpp 2026.8.27.2 发布(PR #517),四个平台的产物已在 GitHub 与 GitCode 两个
host 上齐备,xim-pkgindex的latest也已指向它。结论:不是解压问题,解压是对的
抛异常的是 mcpp 自己,在
src/modgraph/scanner.cppm:238的
dir.filename().string()。MSVC 的path::string()走WideCharToMultiByte(ACP),
遇到当前代码页拼不出的字符就抛std::system_error。你给的排查方向是合理的,但结论指错了方向,而这一点有硬证据:
ERROR_NO_UNICODE_TRANSLATION的前提是宽名里存在 ACP 拼不出的字符。如果 xlings
真的按 ANSI 写坏了名字、盘上落的是 mojibake,那些字符逐个都在 CP1252 里,mcpp
反而不会抛。mcpp 抛了,恰恰证明文件是以正确的 UTF-16 名字落盘的。这也是 #230 的同一处漏网:#231 加固了三个窄化站点,漏掉了同一个 walk 循环里
早一行执行的is_excluded_walk_dir—— 所以加固path_matches_glob对目录名从来无效。触发条件比看上去宽:
include_dirs = { "*" }的字面前缀为空,会从解压根无界递归遍历
整棵上游源码树;在 mcpplibs/mcpp-index891b2f7上量,130 个 recipe 有 103 个含这样的
glob。cpp-httplib 只是第一个带非 ASCII 路径的上游。修好之后的行为
test/www/日本語Dir/这类条目会被跳过并报告一次,构建继续:warning: 'C:/.../test/www' contains names this system's active code page cannot represent impact: those files take no part in the build这正是你提的第 4 条("至少应当报告失败的条目")。注意
chcp改的是控制台代码页,
对进程 ACP 无效。测试数据/文档被跳过是无害的;源文件则需要改名,或换一台代码页覆盖得了的机器。验证
同一个 runner、同一个测试、同一个 ACP 上的红→绿:
- 不含修复的 commit:
FAILED ... it throws std::system_error with description "No mapping for the Unicode character exists in the target multi-byte code page."
—— 与你报的逐字相同 - 含修复的 commit:
[ OK ] Scanner.GlobWalkSurvivesNamesTheCodePageCannotSpell (40 ms)
—— 是OK不是SKIPPED,即它确实在非 UTF-8 ACP 的 runner 上跑了
mcpp-index PR #260 把 pin 升到
2026.8.27.2后,httplib/httplib-tls/
httplib-zstd三个用例应当在 Windows 上转绿。后续:#518 记了两件本次范围之外的事——项目根目录含非 ACP 字符时构建会先以
"没有源文件"失败(指错方向的诊断),以及嵌activeCodePage=UTF-8清单的可行性。- 不含修复的 commit:
使用最新版本mcpp, mcpp-index 已合入
- added a commit that references this issue
on Sep 1, 2026
环境
MCPP_INDEX_MIRROR=GLOBAL归档信息
下载地址：
https://github.com/yhirose/cpp-httplib/archive/refs/tags/v0.53.1.tar.gz
SHA-256：
归档中包含以下非 ASCII 路径：
cpp-httplib-0.53.1/test/www/日本語Dir/
cpp-httplib-0.53.1/test/www/日本語Dir/meson.build
cpp-httplib-0.53.1/test/www/日本語Dir/日本語File.txt
复现步骤
在 mcpp-index PR #260 的代码中执行：
mcpp index update
mcpp test -p httplib-brotli
以下测试也会发生相同错误：
mcpp test -p httplib-tls
mcpp test -p httplib-zstd
实际结果
三个测试均在下载 compat.httplib 后立即失败：
Downloading compat.httplib v0.53.1
error: internal: unhandled exception: No mapping for the Unicode character exists in the target multi-byte code page.
错误发生在 feature 依赖下载和源码编译之前。
预期结果
mcpp 应当能够在 Windows 上正确解压包含 UTF-8 文件名的归档，并继续构建包。
如果确实无法解压，至少应当报告失败的归档条目，而不是抛出未处理的内部异常。
排查证据
综合以上信息，问题很可能是 Windows 解压逻辑将 UTF-8 归档路径通过当前 ANSI/多字节代码页进行转换，导致无法表示日文路径。
建议修复方向
Windows 归档解压过程应完整使用 Unicode 路径：