⚡ 站長快讀:核心重點
- 文章屬性:科技冷知識 / 規格解析
- 核心結論:Windows 用反斜線不是為了跟人不一樣,而是 MS-DOS 2.0 要新增目錄時,斜線早就被命令列參數佔走了。
- 適用對象:所有對科技好奇的人
📌 快速答案
一句話答案:Windows 反斜線路徑源自 MS-DOS 2.0——當年要加入階層目錄時,斜線已被命令列參數開關佔用,只好挑外形最接近的反斜線頂替。
🔍 故事的起點
同一台 Windows 電腦上,你其實同時在用兩套路徑寫法。檔案總管的位址列寫 C:\Users\Ted\Desktop,用反斜線;瀏覽器打開的網頁寫 https://adersaytech.com/tech-event/,用斜線;要是你裝了 WSL,終端機裡又變回 /home/ted。三種寫法擠在同一塊螢幕上,卻沒人覺得奇怪。
更妙的是,這件事常被說成「微軟為了跟 Unix 唱反調才故意選反斜線」。真相剛好相反:當年寫 MS-DOS 的人自己天天用 Xenix 收信,他們很想用斜線,只是那個字元早就被自家工具卡位了。這篇就用微軟與標準組織的一手文件,把這條路徑分岔重講一遍——順便回答一個更少人問的問題:為什麼網址跟著 Linux 走,而不是跟著 Windows。
🧪 原理拆解
先卡位的不是路徑,是「參數開關」
微軟資深工程師 Larry Osterman 在官方部落格寫過這段:DOS 1.0 只支援軟碟,而除了 command.com 以外,許多 DOS 工具程式是 IBM 寫的,它們用 / 當命令列的「開關字元」(switch character)。這個習慣不是憑空冒出來的——類 Unix 系統的開關字元是 -,DEC 的 VMS 與 DECSystem-10/20 則用 /,而幾位早期 MS-DOS 開發者正是 DEC-20 出身。
關鍵在於:DOS 1.0 根本沒有目錄,所有檔案都躺在單一根目錄下。既然沒有階層路徑,/ 和其他作業系統撞號就完全不是問題。電腦歷史博物館的紀錄也對得上:PC DOS 1.0 於 1981 年 8 月隨第一台 IBM PC 出貨,只支援軟碟。
DOS 2.0:硬碟來了,斜線卻已經沒空
轉折點是 MS-DOS 2.0。它在 1983 年 3 月隨 IBM PC/XT 出貨,由一支包含微軟共同創辦人 Paul Allen 的團隊改寫,新增了階層子目錄與硬碟支援。
要表示階層,當時檯面上有好幾種方案:DECSystem-20 寫成 PS:<SYSTEM>MONITR.EXE,4、VMS 改用中括號、類 Unix 則是一條以 / 為根、目錄與檔名不特別區分的簡潔階層。DOS 團隊選了類 Unix 那套寫法——但問題來了:/ 已經被開關字元佔走,. 又被拿去分隔主檔名與副檔名。兩個順位選項都不能用,於是他們挑了外形最像斜線的那個字元:\。
用 Osterman 的結論來說,反斜線之所以是反斜線,理由只有一句:因為斜線被佔走了。
冷知識裡的冷知識:DOS 本來可以長得像 Unix
寫 DOS 的人自己也覺得這結果不順眼。同一篇官方文章提到他們做了三件補救:
- 讓作業系統同時接受
/與\當路徑字元——這個設計一路活到今天。 - 加了一個未公開的系統呼叫可更改開關字元,並讓工具程式尊重這個設定。
- 在
config.sys提供SWITCHAR=設定,把開關字元改成-。
三件事湊起來的效果是:當年只要在 config.sys 寫一行 SWITCHAR=-,MS-DOS 就會切換成「參數用 -switch、路徑用 / 分隔」的類 Unix 風格。這條路後來沒走下去,switchar 也早已消失多年,但它證明了反斜線從頭到尾都是妥協,不是信仰。想親眼看程式碼的人,微軟已把 MS-DOS 1.25 與 2.0 的原始碼以 MIT 授權放上 GitHub。
那斜線又是誰先卡位的?
答案是 Unix 一脈,而且早就寫進國際標準。POSIX(IEEE Std 1003.1-2024)的路徑解析規則白紙黑字寫著:在路徑片段 a/b 裡,檔案 b 位於 a 這個目錄之下;只要路徑以斜線開頭,第一個檔名的上層就是該行程的根目錄,這種路徑稱為絕對路徑。
換句話說,斜線當分隔符的規則在 DOS 出生前就存在。DOS 不是不想用,是晚到一步,發現位子被坐走了。
網址的斜線,是直接繼承來的
網址就更單純——它根本沒另外發明。定義 URL 的 RFC 1738(1994 年 12 月,作者群包含全球資訊網發明人 Tim Berners-Lee)講得很直接:ftp、http、file 這些 scheme 的名稱可以視為階層式,而階層的各層元件以 / 分隔。
所以網址的斜線跟 Unix 是同一條血脈,跟 Windows 沒有關係。這也解釋了一個你可能看過卻沒細想的畫面:在瀏覽器打開本機檔案時,位址列會變成 file:///C:/Users/...——明明是 Windows 路徑,分隔符卻自動翻成斜線,因為那一刻它遵守的是 URL 的規則,不是 Windows 的規則。
💡 總結:冷知識延伸
站長我覺得這題最有意思的地方是:Windows 其實一直都吃斜線,只是沒人跟你講。 微軟 .NET 官方文件寫得很清楚,Windows 的路徑正規化流程會把所有斜線 / 轉成標準的 Windows 分隔符 \;PowerShell 官方文件也明說兩種斜線都可以用,只是把路徑丟給原生程式時,對方可能只認平台原生的分隔符,要查該用哪個就跑 [System.IO.Path]::DirectorySeparatorChar。
唯一的例外很值得記住:以 \\?\ 開頭的 DOS 裝置路徑會跳過正規化,官方文件特別註明這裡必須用標準的反斜線。這種路徑同時也是繞開路徑長度上限的老招,想深入可以接著看〈Windows 路徑為什麼不能超過 260 個字元?MAX_PATH 的歷史與解法〉。
再送一個更冷的:日文版 Windows 的路徑會顯示成 C:¥Users。微軟官方文件寫明,日文語系作業系統使用的 code page 字元集在那個位置放的是日圓符號而非反斜線,轉碼函式還會把反斜線 U+005C 與日圓符號 U+00A5 對到同一個字元。但翻開 Unicode 官方公布的 CP932 對照表,0x5C 對應的其實是 U+005C REVERSE SOLIDUS——同一個位元組,只是穿了不同衣服。韓文版 Windows 則顯示韓圜符號 ₩,微軟工程師 Raymond Chen 專文談過這段歷史。
❓ 常見問題
Q:在 Windows 用斜線寫路徑會出事嗎?
一般不會。Windows 的路徑正規化會把斜線轉成反斜線,PowerShell 也兩種都收。但有兩個地雷:一是 \\?\ 開頭的路徑不做正規化,只能用反斜線;二是命令列工具的參數至今仍以 / 開頭,路徑寫斜線容易被誤判成參數。
Q:為什麼寫程式時反斜線常常要打兩次?
因為在多數程式語言與正規表示式裡,反斜線本身是「跳脫字元」,要表達一個真正的反斜線就得再跳脫一次。這是反斜線在路徑之外的另一份工作,卻讓 Windows 路徑在程式碼裡特別難寫(跳脫規則見〈正規表示式 regex 入門:找檔案、抓資料、批次改文字一次學會〉)。
Q:網址可以改用反斜線嗎?
不行,標準沒有這種寫法。RFC 1738 明訂階層元件以斜線分隔;瀏覽器有時會「好心」把反斜線當斜線處理,那是相容性行為、不是規格保證,別依賴它。
🔗 延伸閱讀
📎 參考資料來源
📖 第一級|廠商官方與標準組織:
- Microsoft Learn:Why is the DOS path character(Larry Osterman,2005-06-24) — 2026-08-31 查證
- Microsoft Learn:File path formats on Windows systems — 2026-08-31 查證
- Microsoft Learn:about_Path_Syntax(PowerShell) — 2026-08-31 查證
- Microsoft Learn:Character Sets Used in File Names — 2026-08-31 查證
- Microsoft DevBlogs:The history of the path separator in Japanese and Korean Windows — 2026-08-31 查證
- GitHub:microsoft/MS-DOS 原始碼(v1.25 / v2.0 / v4.0,MIT) — 2026-08-31 查證
- IETF RFC 1738:Uniform Resource Locators (URL) — 2026-08-31 查證
- The Open Group / IEEE Std 1003.1-2024:General Concepts(Pathname Resolution) — 2026-08-31 查證
- Unicode Consortium:CP932 對 Unicode 官方對照表 — 2026-08-31 查證
📖 第二級|權威技術媒體:
- Computer History Museum:Microsoft MS-DOS early source code — 2026-08-31 查證
⚠️ 本文核心事實以第一級為準,第二級為補充。