两个路径分隔符的故事（2021）

# 两个路径分隔符的故事 来源：https://alexwlchan.net/2021/slashes/ 昨天我再次想起，macOS 会愉快地允许你创建名字里看似包含斜杠的文件，就像 Finder 里展示的这样： 一个 Finder 窗口，包含两个条目。第一个是名为“a/b/c”（a 斜杠 b 斜杠 c）的文件夹，第二个是名为“x/y/z”（x 斜杠 y 斜杠 z）的文本文件。我通过 Finder 的“新建文件夹”按钮创建了文件夹，并通过 TextEdit 保存了文本文件。尽管我明白这是怎么运作的，但每次看到它都让我脑子有点转不过弯来。 如果你不知道这是怎么回事，运行 `ls` 命令就能看出端倪： `` $ ls a:b:c/ x:y:z.txt `` 这些文件的名字里要么是冒号，要么是斜杠——取决于你怎么看它们。 我并不完全理解所有细节，但我知道这是 macOS 拥有**两个**路径分隔符的副作用：斜杠（`/`）和冒号（`:`）。这两个分隔符用于不同的上下文，系统会在需要时在它们之间进行转换。 这两个分隔符反映了现代 macOS 的两个前身系统：经典 Mac OS（https://en.wikipedia.org/wiki/Classic_Mac_OS）和类 Unix 的 NeXTSTEP（https://en.wikipedia.org/wiki/NeXTSTEP）。当它们被整合到一起时，苹果的工程师必须构建一个文件系统，既要兼容经典 Mac 的文件系统（Mac OS 扩展文件系统，即 HFS+（https://en.wikipedia.org/wiki/HFS_Plus）），又要兼容 NeXTSTEP 的文件系统（Unix 文件系统，即 UFS）。除了其他差异外，这些系统使用不同的路径分隔符：HFS+ 使用冒号，而 UFS 使用斜杠。 有一篇由几位苹果工程师撰写的 Usenix 2000 论文（http://www.wsanchez.net/papers/USENIX_2000/），更详细地描述了将经典 Mac OS 和 Unix 结合时遇到的问题。它实际上精确地描述了我们在 Finder 和 `ls` 中看到的现象： > [转换层] 可能在罕见情况下导致用户可见的精神分裂——当文件名包含冒号字符时，这些字符在 Carbon 应用中显示为斜杠，而在 BSD 程序和 Cocoa 应用中则显示为冒号。 在现代 macOS 中，你最容易遇到冒号作为路径分隔符的地方是 AppleScript： `` $ which osascript /usr/bin/osascript $ osascript -e 'tell application "Finder" to get (path to me)' alias Phoenix SSD:usr:bin:osascript `` 这很可能是因为 AppleScript 可追溯到 System 7，当时只需要关心 HFS+ 和冒号。它也可以返回 UNIX（或 POSIX）风格的路径，但需要明确要求： `` $ osascript -e 'tell application "Finder" to get POSIX path of (path to me)' /usr/bin/osascript `` 2017 年，苹果用苹果文件系统（简称 APFS（https://en.wikipedia.org/wiki/Apple_File_System））取代了 HFS+，但双路径分隔符依然存在。我找不到任何文档来证实，但我猜测这主要是为了向后兼容——选择一个单一的路径分隔符会破坏大量的软件。 “文件名中的斜杠”让我脑袋发懵，是因为我开始编程时，Unix 风格的文件系统已经完全占据主导地位。在我的认知里，斜杠是*唯一的*目录分隔符，而 Windows 用反斜杠（`\`）显得很奇怪。实际上，文件系统历史上使用过多种目录分隔符（https://en.wikipedia.org/wiki/Path_(computing)#Representations_of_paths_by_operating_system_and_shell），只是当前 Unix 的霸权才让斜杠显得如此特别。在另一条时间线上，文件名中出现正斜杠可能完全正常。