dsh-encoding

在中文 Windows 上跑 DeepSeek Harness 时，一个很常见却恼人的现象是：命令明明执行成功了，终端里却是一片「ÖÐÎÄ」式的乱码。根源往往不在命令本身，而是老式 CLI、Git Bash、MSYS2 或 PowerShell 5.1 按 GBK（cp936）或 UTF-16LE 往管道里写字节，而 Harness 内置的 bash/pwsh 工具默认按 UTF-8 去解读——解码发生在不可插拔的核心子进程层里，单靠换终端字体解决不了。dsh-encoding 选择不碰核心、也不假装能「修好」内置 shell，而是在插件层补上两条专门面向编码的通路。

插件提供 encoding_run 与 encoding_decode 两个互补工具。encoding_run 自行拉起子进程，以原始字节捕获 stdout/stderr，再启发式识别 UTF-8、UTF-16LE 或 GBK 并解码；需要时也可强制指定编码。encoding_decode 则面向已经进 Harness 的乱码字符串，典型场景是把被误当成 latin1 的 GBK 字节还原成可读中文；若信息已在上游误解码中变成 U+FFFD，会明确告知无法伪造恢复。输出末尾会标注退出码，解码存疑时也会给出警告，而不是静默糊弄。

值得事先了解的是定位：encoding_run 是独立执行工具，不带内置 bash 的沙箱、审批或后台任务能力，权限与 Harness 进程一致；它也不替代 ctx.shell 或内置 pwsh。编码检测在少数边界场景下可能歧义（例如无 BOM 的纯中文 UTF-16LE 与 GBK），已知来源编码时建议手动指定。每路输出有 8 MiB 上限，超时会终止整棵进程树。

适合在 Windows 上日常用 dsh 驱动 agent、又经常要跟本地中文环境命令行打交道的用户：需要看清 GBK 命令结果、或要把对话里已经出现的乱码救回来时，可以把它当作薄而专注的补充层，与内置 shell 并行使用。