[BUG] Windows 原生目录选择器把含 U+xx00 字符的路径截断（如「软件开发」→「软件」），中文目录无法添加为工作区

[kenreri]

环境

• dsh: 0.1.1-rc.2（npm 全局安装 @deepseek-ai/dsh）
• Node: v24.16.0
• OS: Windows 11 x64（Microsoft Windows [Version 10.0.26100.4652]，中文区域）
• 形态：dsh web 本机部署，浏览器访问 http://127.0.0.1:3080
• 目录选择后端：native（win32 IFileDialog，由 dsh-host-directory-picker-native 的子进程驱动）

复现步骤

1. 在 %USERPROFILE%\Documents 下新建文件夹 软件开发
2. Web GUI → 添加工作区…，在弹出的系统目录选择框中选中该文件夹并确认
3. 添加失败，界面反馈的路径被截断为 C:\Users\15301\Documents\软件

期望 / 实际

• 期望：完整路径 ...\软件开发 被接纳为工作区
• 实际：路径在「件」后被截断为 ...\软件；由于该目录不存在，workspaces.create 报错，工作区加不上

根因

@deepseek-ai/dsh-host-directory-picker-native/lib/worker.cjs 的 readUtf16() 在扫描 NUL 结尾的 UTF-16 缓冲区时，只检查每个码元的低字节是否为 0：

while (end + 1 < bytes.length && bytes[end] !== 0) end += 2;
return bytes.toString("utf16le", 0, end);

「开」的码点是 U+5F00，UTF-16LE 内存字节为 00 5F——低字节恰好是 0x00，被误判为字符串结尾，路径即在此截断。凡是名字里含 U+xx00 形字符的目录都会触发（如 一 U+4E00、开 U+5F00）。macOS/Linux 后端走 stdout 文本（UTF-8），不受影响；此问题仅限 Windows 原生选择框。

对同一份字节分别运行新旧算法的最小复现：

const buf = Buffer.from("C:\\Users\\15301\\Documents\\软件开发\0", "utf16le");
const scan = c => { let e = 0; while (e + 2 <= buf.length && c(e)) e += 2; return buf.toString("utf16le", 0, e); };
console.log(scan(e => buf[e] !== 0));                      // 旧算法 -> C:\Users\15301\Documents\软件
console.log(scan(e => !(buf[e] === 0 && buf[e + 1] === 0))); // 新算法 -> C:\Users\15301\Documents\软件开发

建议修复

终止符判断改为「连续两个字节均为 0」（真正的 UTF-16 NUL 终止符）：

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

备注

已在本机按上述方式临时修补 worker.cjs 并验证通过（选择框子进程每次点选时重新拉起，无需重启即可生效）；注意 npm 升级 dsh 会覆盖该文件，希望官方在源码（win32-dialog-bindings.ts 的同一处逻辑）中修复。

[argszero]

Verified against the rc.2 source — your diagnosis is exact. readUtf16() lives at packages/host/directory-picker-native/src/win32-dialog-bindings.ts:37-42 (the lib/worker.cjs you patched is just its compiled copy):

const bytes = Buffer.from(koffi.view(address, 32768))
let end = 0
while (end + 1 < bytes.length && bytes[end] !== 0) end += 2
return bytes.toString('utf16le', 0, end)

1. You've hit the ~10th report of this truncation family. Same low-byte-NUL scan: #3188 = #3279 = #3291 (duplicates), #3442, #3419, #3505 (all confirmed), #3463 (candidate), plus today's #4624 (same mechanism, 一 U+4E00) and #4648 (mixed EN+CN folder names — almost certainly the same root cause when the CJK segment contains a U+xx00 character). Maintainers treat these as one root cause, and your single-line dual-byte fix is the right correction for this mechanism.

2. But this function has a second, independent bug your patch does not fix — and it's a crash, not a truncation. koffi.view(address, 32768) always reads a fixed 32 KiB, while the native buffer behind GetDisplayName is CoTaskMemAlloc'd to roughly the string length. Reading 32 KiB past a short allocation is an out-of-bounds read; on real Windows it has segfaulted and taken down the entire host process (6 reproductions on 0.1.1-rc.2, reported in #4330, still unfixed). The NUL-scan fix alone leaves that OOB read in place.

3. Combined fix — dual-byte terminator + grow-bounded view:

function readUtf16(koffi: Koffi, address: unknown): string {
  let size = 512                       // start small: most paths are short
  while (size <= 32768) {              // cap preserves today's max-path behavior
    const bytes = Buffer.from(koffi.view(address, size))
    for (let end = 0; end + 1 < bytes.length; end += 2) {
      if (bytes[end] === 0 && bytes[end + 1] === 0) {   // real UTF-16 NUL
        return bytes.toString('utf16le', 0, end)
      }
    }
    if (size === 32768) return bytes.toString('utf16le', 0, size)
    size *= 2                          // no terminator: the allocation is bigger
  }
  return ''
}

Two behaviors, one loop: it stops at the first true 00 00 terminator (mechanism A), and it never reads more bytes than the terminator search has already validated — so a short CoTaskMemAlloc block can never be over-read (mechanism B). The 32 KiB cap keeps the pathological-long-path behavior identical to today.

4. Regression tests already exist to extend — packages/host/directory-picker-native/tests/win32-dialog-bindings.spec.ts has the harness; a case with 软件开发\0 (mixes U+xx00 and normal CJK) plus a short-allocation case would lock both mechanisms. This is the family's #1 PR-ready candidate once the Issues/PR channel reopens — the source fix is two functions deep in one file with zero API surface change.

[nokkies]

Confirmed — and your example is the clearest of the three reports of this, because it names the property that actually matters.

软件开发 truncates to 软件 because 开 is U+5F00, whose UTF-16LE bytes are 00 5F. The picker finds the string's NUL terminator by testing only the low byte of each code unit, but a terminator is a whole code unit, so any character encoded 00 xx reads as end-of-string.

That is the real rule: it is not "Chinese paths break", nor "mixed English and Chinese breaks". It is specifically a character whose low byte is zero — U+xx00 — which is why some Chinese directory names work perfectly and others truncate mid-name.

Fix:

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

Same root cause as #4624 (U+4E00 一) and #4648. Reproduced and verified; the fuller write-up, including why the package's existing CJK test could not reach this, is on #4624.