当文件夹名字带“销”字的，无法建立工作区？

[ebynapura]

是不是个BUG

[weijiafu14]

这个现象值得查，但光凭"带'销'字"这一条，谁也没法帮你——因为可能的成因至少有三种，而且处置完全不同。下面是能把它们分开的几个问题，都是你那边几分钟就能答的。

先做一个决定性的对照实验

建两个文件夹，只差一个字，然后各建一次工作区：

• 测试销售 （带"销"）
• 测试销告 → 不行的话再试 测试X售、测试中文（纯中文但不含"销"）

四种可能的结果，指向四个不同的成因：

结果	说明什么
只有含"销"的失败	真的是这个字触发的——那多半是编码/字节层的问题（见下）
所有中文名都失败	不是"销"的问题，是中文路径整体不支持或编码不对
含某些中文字失败、另一些正常	编码转换里某一类字节序列出问题——把成功和失败的字各列几个，这份清单对定位极有价值
换个位置建同名文件夹就正常	与字无关，是那个具体路径的问题（权限、路径长度、盘符、同步盘）

需要补的信息

现在这帖只有一句话加一个问号，没有任何人能据此动手。请补上：

1. 操作系统（Windows / macOS / Linux；如果是 Windows，是不是中文版、系统区域设置是不是"中文(简体)"）；
2. DSH 版本（dsh --version）和你用的是 web 还是 CLI；
3. 完整的文件夹绝对路径（可以打码，但保留是不是纯 ASCII、有没有空格、在哪个盘）；
4. "无法建立"具体是什么样——界面报错了？报什么？还是点了没反应、闪一下就回去了？
5. 有没有报错信息：如果是 web，按 F12 打开开发者工具 → Console，重现一次，把红色报错贴上来。

第 4、5 条尤其重要。 这个社区里有一类问题的表现是"点了没反应/闪回去"，而后端其实返回了完整的错误信息、只是前端把它扔了（#902 就是这样，那位为此做了一次逆向工程才找到根因）。如果你这条也是这种，那控制台里那一行可能直接就是答案。

一个值得先排除的方向：Windows 中文环境的编码

如果你在 Windows 中文版上，那这个方向优先级最高。这个社区里已经有过同环境的编码问题——#2373 报的是中文 Windows 下 python 工具链因为控制台是 GBK 而崩溃（UnicodeEncodeError: 'gbk' codec can't encode character），作者后来自己实现了 PYTHONIOENCODING=utf-8 的修复。

同一个环境因素（系统默认代码页是 GBK 而不是 UTF-8）也可能影响路径处理：一个中文文件夹名在 UTF-8 和 GBK 之间来回转换时，某些字会转坏或转不回来。如果上面的对照实验显示"部分中文字失败、部分正常"，基本就是这一类。

快速自查：把那个文件夹改名成纯英文（比如 sales），再建一次工作区。如果立刻就好了，那基本坐实是路径编码，而不是别的。

我能确定的一件事

工作区的位置是可以自己指定的——DSH 的整个数据目录挂在 DSH_HOME 环境变量下，工作区路径也是你自己选的。所以在查清楚之前，把项目放在一个纯 ASCII 路径下是一个可靠的临时办法，不影响任何功能。

（这一条我们能确定，是因为我们的自动化回归每次都在一个全新的临时 DSH_HOME 里从零跑完整流程——不过那些路径都是纯 ASCII 的，所以我们从来没有撞过中文路径这一类问题，帮不上更具体的。）

边界与利益相关

我们不修 DSH 自家组件——工作区创建在 DSH 里。我没有复现过你这个现象，也没有在中文 Windows 上跑过 DSH（我在 macOS，路径全是英文），上面全部是排查方向，不是结论。#902 / #2373 是别人的报告。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——这是 DSH 建工作区那一步的事，装什么插件都不改变它。

补完上面那几项，这帖被人接手的概率会高很多。

[nokkies]

是 BUG，而且可以精确解释为什么偏偏是“销”这个字。

原生文件夹选择器在解码返回的路径时，是按 UTF-16LE 扫描 NUL 结束符的，但它只检查每个码元的低字节：

while (bytes[end] !== 0) end += 2

一个 UTF-16 结束符是整个码元两个字节都为零。而“销”是 U+9500，UTF-16LE 的字节序是 00 95 —— 低字节正好是 0x00。于是解码器把这个字的第一个字节当成了字符串结尾，路径在这里被截断，随后 realpath 以 ENOENT 失败，工作区就建不起来，界面上显示的还是那个被截断的路径。

所以这不是“中文路径不支持”，而是“低字节为零的那一类字符不支持”。凡是 U+XX00 形式的字都会中招，例如“一”（U+4E00，字节 00 4E）同样会。

顺带说明为什么现有测试没能发现：测试里一直用的是“选”（U+9009，字节 09 90）和“中”（U+4E2D，字节 2D 4E），这两个字的低字节都不是零，所以那条用例无论如何都碰不到这个分支。

修复就是把判断改成整个码元：

while (bytes.readUInt16LE(end) !== 0) end += 2

这与 #4624 和 #4648 是同一个根因（那两个是从“混合中英文的文件夹选不了”这个外部现象报上来的）。本地已按上面的方式修好并加了以低字节为零的字符构造的回归用例。

临时规避：把文件夹改名成不含此类字符的名字，或者手动输入路径而不用选择器。

[weijiafu14]

跟进：你这个问题已经有答案了，而且根因比"中文路径"精确得多。

我上次给你那张四行对照表里的第 3 行（"部分中文字失败——把成功与失败的字各列几个"），命中的就是它。#4654 报的是同一件事，并且给出了确切规则：

不是"中文路径不行"，也不是"中英混合不行"，而是 U+xx00 这一类字符不行——低字节恰好是 0x00 的字。

Windows 原生目录选择器（dsh-host-directory-picker-native）扫描 UTF-16 字符串的结束符时，只检查每个码元的低字节是否为 0：

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

而 UTF-16 的终止符是一整个码元两个字节都为 0。所以「开」（U+5F00，内存字节 00 5F）、「一」（U+4E00）这类字，低字节就是 0x00，被当成字符串结束，路径当场截断。软件开发 → 软件。

这解释了为什么它看起来像"有的中文目录行、有的不行"：取决于目录名里有没有 U+xx00 的字，跟中文本身无关。macOS/Linux 后端走 UTF-8 文本，不受影响，所以这是 Windows 独有的。

对你的意义：

• 如果你的目录名里有「开」「一」这类字，那就是这个 bug，去 [BUG] Windows 原生目录选择器把含 U+xx00 字符的路径截断（如「软件开发」→「软件」），中文目录无法添加为工作区 #4654 跟进（社区已核到源码行、给了修复补丁，那边还统计出这是同一家族的第约 10 份报告：【bug report】打开工作区选择目录的时候，目录名字里【开发】之后的字符串会被截断 #3188/[Bug] Windows 原生文件夹选择器把路径在"低字节为 0 的汉字"处截断（如"xx项目开发"变成"xx项目"） #3279/readUtf16 在 Windows 原生文件夹对话框中会把含低字节为 0x00 的汉字（如 开 U+5F00）的路径截断，导致"添加工作区"报误导性的 ENOENT #3291/[Bug报告] 工作区选择器在"阀"(U+9600) 处截断所选路径（低位字节为 0 的字符均受影响） #3442/Bug: native directory picker truncates paths containing U+XX00 CJK chars (e.g. 开 U+5F00) — workspace create fails on Windows #3419/Bug 报告 + 修复：Windows 下选择含中文路径的目录被截断（UTF-16 终止符扫描缺陷） #3505/[BUG] Windows 目录选择器读取路径被截断（readUtf16 只检查低字节），含"一"等汉字的路径创建工作区失败 ENOENT #4624）。
• 临时绕过：把目录改名成不含 U+xx00 字符的中文名（例如「软件研发」而不是「软件开发」），或者不用图形选择框、直接把完整路径粘进去（如果你那条路径能手工输入的话）。
• 如果改了名还是不行，那就不是这个 bug，我上次那张表里另外三行仍然适用，麻烦按第 4、5 条把后端日志贴出来。

我上次说了"我在 macOS、路径全英文、从没撞过中文路径问题，帮不上更具体的"——这次能给你确切答案，是因为几天后有人把根因查到了字节层。抱歉让你等了这么久。

利益相关不变：我维护一个第三方 DSH 插件（Pi 生态兼容层），目录选择器是 DSH 自家组件，我们既不碰也修不了，上面全是转述 #4654 里已核证的结论。