为何UTF-8路径在不同核心CLI工具的输出中存在不同的转义方式？

咱们先来看个有意思的极端场景——假设我是个偏爱搞怪命名的人，给文件起了个堪称“最辣眼睛”但又逻辑自洽的名字：
[-] {title: "Non-Metadata", id: "s4a4ji"}{.JSON5}.dir
（这名字还混了Pandoc Markdown和JSON5的语法，就是故意不想让它“正常”）

符合POSIX标准的转义方式 #

当我用ls命令查看这个文件时，它输出的转义格式是完全贴合POSIX标准的——不管是sh这种基础Shell，还是Fedora 40里的bash，都能毫无问题地解析这个输出，甚至你直接复制这段输出就能在Shell里引用这个文件：

• 执行的命令：ls "$PWD"
• 输出的文件名转义格式：' [-]'$'\t''{title: "Non-Metadata",'$'\t''id: "s4a4ji"}{.JSON5}.dir'
  这里ls用了Shell原生支持的转义方式，比如$'\t'来表示制表符，用单引号包裹特殊字符，确保Shell能准确识别每个部分。

八进制转义方式 #

但tree和file这两个工具的处理逻辑就不一样了，它们会把不可见的控制字符（比如这里的制表符）转换成八进制转义的形式，这种格式更偏向于可视化展示，让用户能清楚看到文件名里藏了哪些特殊字符，但没法直接像POSIX格式那样在Shell里使用：

• 执行的命令：tree "$PWD"
• 输出的文件名转义格式：

.
└──   [-]\011`{title: "Non-Metadata",\011id: "s4a4ji"}`{.JSON5}.dir

这里的\011就是制表符的八进制表示，虽然能直观展示特殊字符，但Shell并不会把它解析成实际的制表符。

备注：内容来源于stack exchange，提问作者RokeJulianLockhart