Bug: native directory picker truncates paths containing U+XX00 CJK chars (e.g. 开 U+5F00) — workspace create fails on Windows

[HorusJiang]

一句话说明

Windows 下通过"选择工作区"系统对话框选择含特定中文字符（低字节为 0x00，如 开 U+5F00）的路径时，路径被截断，导致工作区创建失败（ENOENT）。

复现步骤

1. Windows 上启动 dsh web（directory-picker-auto 在 win32 + loopback 下解析为 native 系统目录选择器）
2. 新建会话 → 选择工作区 → 导航到含 开（U+5F00）的目录，如 D:\projects\DSH\DSH代码学习\04-插件开发
3. 确认选择

实际结果

workspace create failed: workspace-invalid-path: cannot create a workspace at "D:\projects\DSH\DSH代码学习\04-插件": ENOENT: no such file or directory

路径被截断：04-插件开发 → 04-插件（开 及之后全部丢失）。

预期结果

完整路径 D:\projects\DSH\DSH代码学习\04-插件开发 被接受，工作区正常创建。

环境

• Windows
• DSH 0.1.0-rc.5（源码运行）
• packages/host/directory-picker-native（native picker）

根因（已定位到具体代码）

packages/host/directory-picker-native/src/win32-dialog-bindings.ts 的 readUtf16（第 37-42 行）：

function readUtf16(koffi: Koffi, address: unknown): string {
  const bytes = Buffer.from(koffi.view(address, 32768))
  let end = 0
  while (end + 1 < bytes.length && bytes[end] !== 0) end += 2   // ← 只检查 UTF-16 单元的低字节
  return bytes.toString('utf16le', 0, end)
}

bytes[end] !== 0 只检查每个 2 字节 UTF-16 单元的低字节。UTF-16LE 中，任何低字节为 0 的 BMP 字符都会让循环提前终止：

• 开 = U+5F00 → LE 字节 00 5f → 低字节 0x00 → 循环在此终止，截断其后的所有字符
• 对照组：01-学习笔记 中 学(U+5B66)/习(U+4E60)/笔/记 低字节均非零 → 正常

最小复现（纯 JS，无需 Windows COM 环境）

function readUtf16Buggy(bytes) {
  let end = 0
  while (end + 1 < bytes.length && bytes[end] !== 0) end += 2
  return bytes.toString('utf16le', 0, end)
}
const p = 'D:\\projects\\DSH\\DSH代码学习\\04-插件开发'
const mem = Buffer.alloc(Buffer.byteLength(p, 'utf16le') + 2)
Buffer.from(p, 'utf16le').copy(mem)
console.log(readUtf16Buggy(mem))
// 输出: "D:\projects\DSH\DSH代码学习\04-插件"  ← 丢了"开发"

建议修复

检查完整的 UTF-16 单元（2 字节）是否为 0x0000：

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

影响面

任何路径中含低字节为 0 的 CJK 字符（开 U+5F00、一 U+4E00、汉 U+6C49、主 U+4E3B、文 U+6587 等）的 Windows 用户，在通过 native 目录选择器选择工作区时都会遇到此问题。01-学习笔记/02-实验与练习 这类路径不受影响，所以该 bug 容易被掩盖。

[HorusJiang]

我把路径从 04-插件开发 改成 04-插件 之后，可以正常创建工作区了。

[argszero]

报告完整精确，这是 readUtf16 低字节 NUL bug 家族的又一独立复现——目前家族已有 5 个确认报告 + 1 个候选，你的帖子是其中之一且复现链最干净（纯 JS 最小复现 + 对照组 + 实际验证）。

家族汇总（同一 bug，packages/host/directory-picker-native/src/win32-dialog-bindings.ts:37-42 的 readUtf16 单字节终止符扫描）：

• 【bug report】打开工作区选择目录的时候，目录名字里【开发】之后的字符串会被截断 #3188（C:\Codex\开发设置 → 截断为 C:\Codex\）
• [Bug] Windows 原生文件夹选择器把路径在"低字节为 0 的汉字"处截断（如"xx项目开发"变成"xx项目"） #3279（开/万/不/中/主 等 U+XX00 汉字）
• readUtf16 在 Windows 原生文件夹对话框中会把含低字节为 0x00 的汉字（如 开 U+5F00）的路径截断，导致"添加工作区"报误导性的 ENOENT #3291（D:\...\CAN盒子二次开发\can_auto_test 截断于 开）
• [Bug报告] 工作区选择器在"阀"(U+9600) 处截断所选路径（低位字节为 0 的字符均受影响） #3442（D:\data\疏水阀数据\2025年 截断于 阀 U+9600——作者给了带 U+XX00 fixture 的回归测试）
• Bug: native directory picker truncates paths containing U+XX00 CJK chars (e.g. 开 U+5F00) — workspace create fails on Windows #3419（本贴）：04-插件开发 截断于 开（U+5F00），01-学习笔记 不受影响——对照组恰好证明低字节为 0 是充分条件
• bug:自定模式在window下无法打开所载配置目录 #3463 候选（"Windows 无法打开所载配置目录"——若路径来自 native 对话框则同根，已请求作者确认路径来源）

修复确认：你建议的双字节检查与 #3442 作者的修复等价（你的 !(bytes[end]===0 && bytes[end+1]===0) 是否定形式，#3291 的 (bytes[end]!==0 || bytes[end+1]!==0) 是肯定形式，语义相同）。真正 UTF-16LE NUL 是两个连续 0 字节。

回归测试要点（关键）：测试 fixture 必须含 U+XX00 字符（如 开/中/阀）——ASCII 或普通 CJK（如 学 U+5B66 低字节 0x66）结构性无法命中此模式，这正是现有测试漏掉它的原因。建议用你实际踩到的 04-插件开发 或 #3442 的 C:\疏水阀数据\2025年\子目录 作 fixture。

修复状态：修复本身就绪（1 行 + 回归测试），家族 5 报独立复现互相印证；只差并入上游（当前 CONTRIBUTING 不收外部 PR，等通道重开）。我这边也有完整修复 diff 和家族证据链，随时可协助整理成 PR。

[leenkcool]

我是插件库，我感觉你的想法很好，我想收录，可以提ISSUE。 具体提的方法如下。
#4456

我也帮你置顶帖子，省得被埋没。 被收录的插件审核前送STAR