[Bug报告] 工作区选择器在"阀"(U+9600) 处截断所选路径（低位字节为 0 的字符均受影响）

[pisceslailai]

[Bug] 工作区选择器在"阀"(U+9600) 处截断所选路径

环境：Windows + dsh web（0.1.0-rc.5），通过原生 Win32 文件夹选择器（host.pickDirectory）选择工作区。

复现步骤：

1. 新建一个名称包含"阀"(U+9600) 的文件夹，例如 D:\data\疏水阀数据\2025年；
2. 在工作区选择器中选中该文件夹（或其下的任意文件夹）。

预期结果：注册的工作区路径等于所选完整路径。

实际结果：路径在第一个"阀"字处被截断——显示为 D:\data\疏水，"阀"及其后所有内容全部丢失。

根因：packages/host/directory-picker-native/src/win32-dialog-bindings.ts 的 readUtf16 在查找 UTF-16 字符串的 NUL 终止符时，只检查每个编码单元的低位字节：

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

任何码点为 0x100 整数倍的 BMP 字符，其 UTF-16LE 编码的低位字节都是 0x00——例如 阀 (U+9600)、退 (U+9000)、耀 (U+8000)、怀 (U+6000)——扫描会在这里提前结束，该字符及其后的路径内容被丢弃。这正是阀门/蒸汽类数据的目录名含"阀"时必然触发的原因。

修复方案：改为检查完整的 16 位编码单元（Windows 路径不可能包含 U+0000，因此该判断是安全的）：

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

回归测试：已在 tests/win32-dialog-bindings.spec.ts 中加入含"阀"路径的用例（C:\疏水阀数据\2025年\子目录），包内测试全部通过（13 个）。

[argszero]

Confirmed — this is the 4th report of the same bug, and your root cause + fix + test are exactly right. Family closure:

The readUtf16 low-byte truncation family (4 reports)

#	Reporter	Trigger char	Status
#3188	zhengwx1995	开发设置 (开 U+5F00)	root cause misattributed initially, corrected
#3279	dandaogc	开/万/不/中/主	duplicate
#3291	victorwwd	开 U+5F00 + exact fix	canonical diagnosis
#3442	pisceslailai	阀 U+9600 + regression test	complete fix + test

Your diagnosis matches the canonical one from #3291 (verified at source + empirically reproduced in node): win32-dialog-bindings.ts:37-42 scans with bytes[end] !== 0 (low byte only), so any BMP char whose codepoint is a multiple of 0x100 (阀 U+9600, 开 U+5F00, 退 U+9000, 耀 U+8000, 怀 U+6000…) stores as 00 XX in UTF-16LE and terminates the scan mid-path.

On your fix

Your negated-both-bytes form:

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

is equivalent to the bytes[end] !== 0 || bytes[end+1] !== 0 form from #3291 — both correctly require two consecutive zero bytes (the true UTF-16LE NUL). Windows paths cannot contain U+0000, so the check is safe.

The regression test is the critical part — and your fixture (C:\疏水阀数据\2025年\子目录 with 阀 U+9600) is exactly the right shape. This is why the bug survived this long: existing tests use ASCII fixtures, which structurally cannot hit the 00 XX byte pattern. A U+XX00 codepoint fixture is the only way to pin this. (Your 13-test suite passing with the new case is the correct gate.)

Suggested PR shape (when the channel reopens)

This is the cleanest small fix in the queue: 1 line in readUtf16 + the U+XX00 regression test. It closes four threads (#3188 = #3279 = #3291 = #3442). Since three separate reporters now independently converged on the same one-line fix, maintainer review should be trivial.

One note for the maintainers: consider a sweep for other readUtf16-style decoders in the codebase (any manual UTF-16LE NUL scan with a single-byte check) — the family pattern is "even-offset 0 byte mistaken for terminator", and the same class could exist in other native bindings.