Replies: 2 comments 1 reply
|
I checked the current repository HEAD ( while (end + 1 < bytes.length && bytes[end] !== 0) end += 2This checks only the first byte of each UTF-16LE code unit. A character such as U+5F00 ( The fix should test the complete code unit ( |
|
Confirmed the same root cause. readUtf16 checks only the LOW byte of each UTF-16LE code unit, so ANY BMP character whose low byte is 0x00 (e.g. 一 U+4E00, 开 U+5F00) is mistaken for the terminator. Example: D:\项目一\资料 is truncated to D:\项目, then fs.realpath fails with ENOENT. Proposed fix - check the whole code unit:
Verified locally: the old code returns the truncated path (fs.realpath on it fails with ENOENT); the fix returns the full path, and a regression test fails on the old code and passes with the fix. Environment: Windows 10, dsh 0.1.0-rc.6 (npm). 已确认同一根因。readUtf16 只检查每个 UTF-16LE code unit 的低字节,因此任何低字节为 0x00 的 BMP 字符(如「一」U+4E00、「开」U+5F00)都会被误判为字符串结束。示例:D:\项目一\资料 会被截断为 D:\项目,随后 fs.realpath 报 ENOENT。 修复建议——检查完整的 code unit:
本地已验证:旧代码返回截断路径(fs.realpath 对其报 ENOENT),修复后返回完整路径;回归测试在旧代码下失败、修复后通过。环境:Windows 10,dsh 0.1.0-rc.6(npm)。 |
Uh oh!
There was an error while loading. Please reload this page.
win上选工作区,native picker会截断中文路径. packages/host/directory-picker-native/src/win32-dialog-bindings.ts的 readUtf16用"单字节是否为 0"来判断 UTF-16 字符串结束,导致「开」= U+5F00,UTF-16LE 编码是 00 5F —— 低字节是 0x00,被误判成字符串结束,直接创建失败工作区...
All reactions