[Bug] Windows 原生目录选择器在低字节为 0x00 的字符（如 言 U+8A00）处截断所选路径，导致 workspace create failed: workspace-invalid-path / ENOENT

[beta-sx]

Bug 反馈：Windows 原生目录选择器在低字节为 0x00 的字符（如 一 U+4E00）处截断所选路径，导致 workspace create failed: workspace-invalid-path / ENOENT

问题概述

在 Windows 上，原生文件夹选择器（dsh-host-directory-picker-native）会把选中的路径静默截断在第一个 UTF-16 码点低字节为 0x00 的字符处（即所有 U+XX00 字符，例如 一 U+4E00、刀 U+5200、退 U+9000）。截断后的路径被提交给 workspace.create，随后报错：

workspace create failed: workspace-invalid-path: cannot create a workspace at "...": ENOENT: no such file or directory, realpath '...'

只要所选文件夹的路径中包含这类字符，工作区创建流程就完全不可用——尽管文件夹真实存在，且 DSH 其他环节对 Unicode 路径的支持都是完好的。

运行环境

项目	值
dsh	0.1.0-rc.6（全局 npm 安装 @deepseek-ai/dsh@0.1.0-rc.6）
受影响包	@deepseek-ai/dsh-host-directory-picker-native@0.1.0-rc.6
操作系统	Windows 10 10.0.19044
Node	v24.14.1
后端解析	native（win32 + 回环绑定时 directory-picker-auto 解析为 native）

复现步骤

1. Windows 上启动 dsh Web GUI（原生目录选择器后端生效）。

2. 通过选择器添加工作区，导航到路径中含低字节为 0x00 字符的文件夹。示例如下（虚构路径，用于演示）：

   D:\演示\模块一\项目
   

   第二个路径段是 模块一——字符 一（U+4E00，UTF-16LE 字节为 00 4E）位于该段末尾。

3. 确认选择。

预期行为

工作区在完整路径下创建成功：

D:\演示\模块一\项目

实际行为

对话框返回了完整路径，但该路径在 一 字处被截断，GUI 报错：

workspace create failed: workspace-invalid-path: cannot create a workspace at "D:\演示\模块": ENOENT: no such file or directory, realpath 'D:\演示\模块'

注意 D:\演示\模块 —— 正是真实路径在 一 字处被截掉后的前缀。

根本原因

lib/worker.cjs（由 src/win32-dialog-bindings.ts 构建而来）中的 readUtf16：

function readUtf16(koffi, address) {
	const bytes = Buffer.from(koffi.view(address, 32768));
	let end = 0;
	while (end + 1 < bytes.length && bytes[end] !== 0) end += 2;   // BUG
	return bytes.toString("utf16le", 0, end);
}

该循环在偶数偏移处查找第一个 0x00 字节，并将其当作字符串 NUL 终止符。这只对 ASCII 有效（ASCII 的高字节恒为 0x00）。对于码点为 U+XX00 的非 ASCII 字符，其 UTF-16LE 编码为 00 XX——低字节 0x00 恰好落在偶数偏移上，被误判为字符串结束。

以 一（U+4E00，字节 00 4E）为例：

D : \ 演 示 \ 模 块 一 项 目 ...
44 00 3A 00 5C 00 14 6F 3A 79 5C 00 21 6A 57 57 00 4E 79 98 EE 76
                                                    ^^^^
                                     偶数偏移处的 0x00 -> 扫描在此停止

→ 返回的字符串是 D:\演示\模块。

最小复现脚本：

const real = 'D:\\演示\\模块一\\项目';
const buf = Buffer.alloc((real.length + 1) * 2);
buf.write(real, 0, 'utf16le');
let end = 0;
while (end + 1 < buf.length && buf[end] !== 0) end += 2;
console.log(buf.toString('utf16le', 0, end));
// D:\演示\模块

建议修复

改为在偶数偏移处查找 NUL 字（0x0000），而不是单独的 0x00 字节：

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

已在本地验证：应用该修复后，同一缓冲区可完整还原出 D:\演示\模块一\项目。

影响范围

• 任何包含码点为 U+XX00 字符（如 一 U+4E00、刀 U+5200、退 U+9000 等）的文件夹/文件路径，都会在 Windows 原生选择器中触发此问题。这些是常见汉字，因此中文用户受影响面较广。
• 截断是静默的：GUI 在提交前不会展示所选路径，用户只能看到令人困惑的 workspace-invalid-path / ENOENT 报错。
• 其他目录选择器后端（browse、macOS osascript、Linux zenity/kdialog）不受影响——它们原样传递路径字符串。
• 已在安装树中全局搜索该扫描模式（end += 2 / bytes[end] !== 0），仅 dsh-host-directory-picker-native 一处存在；路径管道的其余环节（worker IPC → 客户端 → workspace.create → realpath）均为 Unicode 安全，并已端到端验证。

临时规避方案（在官方修复前）

• 避免选择路径中含 U+XX00 字符的文件夹；或
• 改用手动输入路径的方式，而不是原生对话框；或
• 按上述修复方案本地修改 readUtf16（对话框 worker 每次选择都会重新拉起子进程，因此立即生效；注意包重装会覆盖该补丁）。

[huguangyu666]

我也遇到了此问题

[beta-sx]

先在一个其他的路径工作区内创建新会话，然后把上述文档交给dsh来处理，应该可以修复好

[huguangyu666]

已修好

先在一个其他的路径工作区内创建新会话，然后把上述文档交给dsh来处理，应该可以修复好

[FenjuFu]

我在当前 master@47f943859b、Windows x64、Node.js v24.16.0 上复核了这个问题：readUtf16 仍只检查 UTF-16LE code unit 的低字节，最小复现会把 D:\演示\模块一\项目 解码成 D:\演示\模块。

我已在本地准备了一个最小补丁，将终止条件改为同时检查两个 NUL 字节：

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

同时在现有 mocked COM world 测试中加入了 C:\开发\模块一\😀 回归用例，既覆盖 开/一 这类低字节为 0x00 的 code unit，也确认代理对不会受影响。

本地验证结果：

• packages/host/directory-picker-native/tests：5 个测试文件通过，47 passed，1 个平台条件 skip
• tsc -b packages/host/directory-picker-native/tsconfig.json：通过
• 两个改动文件的 oxlint：通过
• tsdown --config packages/host/directory-picker-native/tsdown.config.ts：通过，确认修复进入发布用 lib/worker.cjs
• git diff --check：通过

改动仅涉及一行实现和一个回归测试。考虑到当前贡献指南暂不接受外部 PR，我没有推送分支。如果维护者愿意接收，我可以提供可直接应用的 git patch/commit；后续开放 PR 时也可以立即整理成 PR。