Bug 报告 + 修复：Windows 下选择含中文路径的目录被截断（UTF-16 终止符扫描缺陷）

[vbcssc]

问题现象

Windows 上通过 Web UI 添加目录到工作区时，只要路径里含有低字节为 0 的汉字，目录选择器返回的路径就会被截断：

• 添加 D:\...\开源仓库-分析区\llm-as-a-verifier → 实际注册的是 D:\...（ASCII 前缀，目录存在则静默注册成功）
• 添加 D:\...\skills-开发-工作区\skill-judge → 报 workspace create failed: workspace-invalid-path: cannot create a workspace at "D:\...\skills-": ENOENT

根因

packages/host/directory-picker-native/src/win32-dialog-bindings.ts 的 readUtf16 用单字节判断 UTF-16 字符串的结尾：

while (end + 1 < bytes.length && bytes[end] !== 0) end += 2

但 UTF-16LE 字符串的终止符是双字节 0x0000。U+xx00 平面的汉字（一 U+4E00、开 U+5F00、退 U+9000 …）编码为 00 xx，低字节就是 0x00，被误判为字符串终止符 → 路径在第一个这样的汉字处被截断。

为什么以前有的中文路径"正常"？纯属侥幸：像 期货量化交易项目 这类路径（期 671F、货 8D27、量 91CF …）的汉字低字节恰好都不为 0，不触发。这是数据相关的缺陷，与时间线无关。

修复

终止符判定改为完整双字节单元：

while (end + 1 < bytes.length && !(bytes[end] === 0 && bytes[end + 1] === 0)) end += 2

已验证：

• 新增回归测试（路径含 开 U+5F00，断言完整往返；旧代码会截成 C:\），包内 47 个测试全绿
• 用真实 koffi 在 Windows 上对 5 条含中文路径实测，全部完整往返（含全 U+xx00 序列 一退刀最）
• 尝试过 koffi 便捷解码（koffi.decode(addr, 'str16') 等）：裸地址解码段错误、as() 报 expected pointer、Buffer 直传段错误 —— 手写 view + Buffer 读取是唯一可行路径，因此修复落在扫描逻辑上

请求

修复已放在 fork 分支：https://github.com/vbcssc/deepseek-harness/tree/mydev-fix-utf16

包含：

• 源码修复 + 回归测试（win32-dialog-bindings.ts / win32-dialog-bindings.spec.ts）
• Agent Note：2026-08-20-win32-dialog-cjk-zero-low-byte-truncation.md（含字节级证据与备选方案分析）

由于仓库关闭了 Pull Request，通过 Discussion 提交。请官方团队评估合并 —— 此缺陷对 Windows 中文路径用户影响较大，建议随 rc.8 或后续版本带上。

—— vbcssc

[vbcssc]

跟进（2026-08-20）：0.1.0-rc.8 已发布，但该修复未被合入。

已核实：

• 官方 tag dsh-v0.1.0-rc.8 的源码 packages/host/directory-picker-native/src/win32-dialog-bindings.ts 第 40 行仍是旧的单字节判断 bytes[end] !== 0；
• npm 上 picker 包 0.1.0-rc.8 的构建产物 lib/worker.cjs 第 24 行同样是旧逻辑；
• 官方代码注释里已确认 koffi.decode(addr, "str16") 崩溃、改用手写 view 读取，但终止符扫描一直写错（单字节 0x00 会把 U+xx00 平面汉字如 开 U+5F00、一 U+4E00、退 U+9000 的低字节 0x00 误判为结尾）。

本地已对 rc.8 全局安装的 worker.cjs 重新打补丁（双字节 0x0000 判定），真实 koffi 复验 5/5 通过，Windows 中文路径用户目前不受影响。

请官方评估将此修复纳入后续版本（rc.9 / 1.0）。修复分支仍在：https://github.com/vbcssc/deepseek-harness/tree/mydev-fix-utf16

—— vbcssc

[ylwl1997]

这条 Windows 中文路径截断（UTF-16 终止符按单字节扫）非常实锤，而且你已经对到 win32-dialog-bindings / picker 构建产物——rc.8 仍未合入说明还需要官方跟进。

补充一个用户侧临时规避：尽量把工作区放在纯 ASCII 路径下做验证；含「开/发」这类低字节可能为 0 的汉字路径，目录选择器现在确实不可信。

希望下一 rc 把 str16 扫描修进 release；在合入前，这类「装得上但工作区路径坏掉」也会让第三方插件实测误报，目录侧只能标环境限制。

[argszero]

#3505 是 readUtf16 家族的第 6 个独立确认报告（#3188 = #3279 = #3291 同根 + #3442 + #3419 + 本贴），另有 #3463 待作者补路径信息确认为第 7 例。借你这个干净的自带修复，补上家族闭环的三块拼图：

1. 修复形式等价确认 —— 5 个独立报告者收敛到同一行

你的 !(bytes[end] === 0 && bytes[end + 1] === 0)（否定式双字节检查）与家族已发表的两种形式等价：

• readUtf16 在 Windows 原生文件夹对话框中会把含低字节为 0x00 的汉字（如 开 U+5F00）的路径截断，导致"添加工作区"报误导性的 ENOENT #3291 正向式 (bytes[end] !== 0 || bytes[end + 1] !== 0)
• [Bug报告] 工作区选择器在"阀"(U+9600) 处截断所选路径（低位字节为 0 的字符均受影响） #3442 / Bug: native directory picker truncates paths containing U+XX00 CJK chars (e.g. 开 U+5F00) — workspace create fails on Windows #3419 否定式（同你）

五个互不知情的报告者各自独立推导出同一行修复，本身就是正确性的强交叉验证。rc.8 未合入不影响修复本身的有效性。

2. 防御性全库扫描完成 —— 唯一脆弱点，无扩散（此前我在 #3442 回复中预告过这个 sweep）

对 rc.8 全库所有手写 UTF-16 解码路径过了一遍：

• win32-dialog-bindings.ts:40 —— 唯一的手写终止符扫描，唯一脆弱点
• sandbox-windows-acl/src/ffi.ts:467（errorText/FormatMessageW）与 :486（getTempPath/GetTempPathW）—— 走 Win32 API 返回的显式字符长度（subarray(0, length * 2)），不扫描终止符 → 安全
• 其余 str16 全部由 koffi 处理 → 安全

结论：单行修复 = 整个家族闭合，不存在第二处同型 bug 等着补。

3. 回归测试选型正确 —— 恰好命中家族 fixture 要求

开 U+5F00 低字节恰为 0x00，正是能锁住此 bug 的 U+XX00 形态。家族既有教训：ASCII fixture 结构性碰不到 00 XX 模式（现有测试一直没抓到它就是这个原因）；学 U+5B66 低字节 0x66 也测不出。你的 47 测试绿 + 真实 koffi 5/5 往返（含全 U+xx00 序列）是家族迄今验证密度最高的一份。

给官方的信号：6 个独立确认 + 1 个候选、同一单行修复、Windows 中文路径高影响面（开/一/中/阀/汉/主 都是常用字）、作者已对构建产物验证——建议 rc.9 优先合入，成本远低于再漏一个 rc。

一个非阻塞的轻量边界（可留作后续 hardening）：koffi.view(address, 32768) 固定 32KB 上限无超限检测，理论上 >16384 字符的路径会静默截断（正常 MAX_PATH/长路径场景远达不到），不影响本次修复。