磁盘目录带有特殊汉字会导致无法添加至工作区

[miaoluxin]

在 win32-dialog-bindings.ts 的 readUtf16(第 37-42 行):
let end = 0
while (end + 1 < bytes.length && bytes[end] !== 0) end += 2
return bytes.toString('utf16le', 0, end)
它把路径当 UTF-16LE 扫描终止符时,只检查每个字符的第一个字节,遇到任何"低字节为 0"的合法字符就会提前截断——而 销 的 Unicode 码点正好是 U+9500(UTF-16LE 首字节为 0x00)!你的目录叫"营销XXXXXX",路径读到这里就断了,正好停在"营"后面——和报错"…\XXXX析\营"一字不差。任何含 销、一(U+4E00)、万(U+4E07)这类字符的目录都会踩中。

[173787247]

[miaoluxin]

Bug 细节答复:磁盘目录含特殊汉字(U+XX00 系)导致无法添加至工作区

适用对象:issue/PR 评审问询的补充说明。环境与数据均来自实际运行宿主与源码调查,非推测。

1. 精确版本

项	值
DSH / 包版本	0.1.1-rc.2(git b150a551b8d465e31e418e1b2eaf5e79bbb7d28e,tag dsh-v0.1.1-rc.2)
受影响包	@deepseek-ai/dsh-host-directory-picker-native@0.1.1-rc.2(源码树内,profile 为工作区链接模式,无独立安装)
Node / npm	v24.17.0 / 11.13.0

2. 运行环境

• 纯 Windows:Windows 11 Pro(build 26200, 64-bit)。宿主绑定 127.0.0.1 回环、无 SSH 会话——directory-picker-auto 启动时据此选择了 native 后端(报错中也写明 composed picker serves "native"),即"有人值守的本地 Windows 会话";链路不经过 WSL(wsl.exe 仅在系统中存在,本次未参与)。
• 无代理:HTTP_PROXY / HTTPS_PROXY / ALL_PROXY / NODE_USE_ENV_PROXY 均为空。本 bug 是纯本地路径读取,不涉及网络;评审提到的 Node 24 代理行为(NODE_USE_ENV_PROXY=1)与本 bug 无关。

3. 最小复现(确定性,无需新 profile / 关插件)

1. 任一 Windows 上运行 DSH web GUI(默认 profile 即可——native 选择器即默认后端,与额外插件无关)。
2. 建一个名字含 U+XX00 系字符的目录,如 营销服回执(销=U+9500)、一(U+4E00)或 万(U+4E07)。
3. 左侧工作区 → 添加工作区 → 系统原生文件夹选择器选中该目录 → 确定。
4. 必然报 workspace-invalid-path,错误里的路径被截断在该字符之前。

自证截断点在选择器而非别的层:直接 POST /api/workspace.create 传完整路径会成功(已实测,工作区正常创建);问题函数是 win32-dialog-bindings.ts 的 readUtf16。

4. 完整报错 / 轨迹片段

workspace create failed: workspace-invalid-path: cannot create a workspace at
"C:\Users\31632\Desktop\数字资产分析\营":
ENOENT: no such file or directory, realpath 'C:\Users\31632\Desktop\各业务域数字资产分析\营'

调用链:NativeDirectoryFlow → host.pickDirectory(win32 IFileOpenDialog 子进程,koffi)→ readUtf16 截断 → workspaces.create → POST /api/workspace.create → ensureWorkspace → realpath ENOENT → workspace-invalid-path

字节级根因(修复提交中已附分析):

// packages/host/directory-picker-native/src/win32-dialog-bindings.ts
while (end + 1 < bytes.length && bytes[end] !== 0) end += 2   // 只查每单元首字节

销(U+9500)的 UTF-16LE 字节为 00 95——首字节 0x00 被误判为字符串结束,路径在"营"之后即断;任何 U+XX00 系字符(销/一/万/…)都会触发,与插件、profile、代理、WSL 均无关。修复为按完整 00 00 双字节对判定结束,并新增含 销、一/万 的回归用例(win32-dialog-bindings.spec.ts,14/14 通过)。

5. 附:更窄的复现用例

桌面建一个名为 一 的空目录,从工作区选择器选中它即可——100% 复现,一个字符即可。

[argszero]

你的诊断完全正确——销 (U+9500) 的 UTF-16LE 首字节正是 0x00，单字节 NUL 扫描必然在此截断。补一个时代检查（era check）：这个截断缺陷上游已经修掉了。

• 修复提交：51c242749a（2026-08-14，"fix(directory-picker-native): stop truncating Win32 UTF-16 paths at U+XX00"）
• 在 0.1.2-alpha.1（cd5ef81481）里，win32-dialog-bindings.ts:42 已经是双字节判定：

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

• 所以如果你还在 rc.2 及以前，升级到 0.1.2-alpha.1 即可解决这个具体问题。

补充家族背景：这是同一机制的第 8/9 次独立报告（#3188/#3279/#3291/#3442/#3419/#3505 确认 + #3463 候选），触发字符全是 U+XX00 形态（一/万/开/中/阀/销…）。家族内早已收敛出同一行修复 + 必须用 U+XX00 字符做回归 fixture 的结论（ASCII fixture 结构上测不出）。

但同一函数还残留第二个、更隐蔽的缺陷（#4330）：win32-dialog-bindings.ts:38 仍然固定读 32768 字节：

const bytes = Buffer.from(koffi.view(address, 32768))

而 Win32 CoTaskMemAlloc 只分配了路径本身几十到几百字节的小块——固定 32KB view 会越界读，实测可触发访问违例、整个 dsh host 进程崩溃（#4330 作者 6 次复现，0.1.1-rc.2 未修，alpha.1 依旧）。修复形状是增长式有界 view：520 字节起步（≈MAX_PATH UTF-16），未遇 NUL 则翻倍，直到 32KB 封顶——与家族修复线（双字节 NUL）组合即完整。

小结：你的路径截断问题 → 升级即解；同函数越界崩溃 → 仍是待合入的 PR-ready 候选（上游 PR 通道目前不可用，供维护者取用）。

[miaoluxin]

Got it！ths~

[PerryLink]

已修。目录名中特殊汉字 (U+9500 等) 被截断导致无法添加至工作区的问题, 根因与 #4330 相同: Win32 目录选择器用固定 32KiB view 读小堆指针, 非 ASCII 路径被错误解码。

commit 141d72d "fix(directory-picker-native): decode the Win32 picker path without a fixed 32KiB view" 将 readUtf16 重写为 koffi.decode(pointer, 'str16') (packages/host/directory-picker-native/src/win32-dialog-bindings.ts:39-43)。

更新到最新版 (npm latest=0.1.5-rc.1) 或拉取 master 重建后重试; 若仍复现, 请带复现路径回帖。