為什麼只有 Chromium 系能直接覆寫硬碟

一句話版本

「直接覆寫你硬碟上的那個檔案」需要 File System Access API, 而目前只有 Chromium 系瀏覽器(Chrome、Edge、Brave、Arc、Opera)實作了它的完整版本。

網頁本來拿不到你的檔案

傳統的 <input type="file"> 只給網頁一份快照:你選了檔案,網頁拿到內容, 然後就沒有回頭路了 —— 想把修改結果交還給你,只能觸發一次下載,你再自己去覆蓋原檔。 那是「下載到下載資料夾 → 打開檔案總管 → 拖回原本的位置 → 確認覆蓋」的四步儀式。

File System Access API 改變的是這一點:使用者主動選擇之後,網頁可以拿到一個 可寫入的 handle,之後對同一個檔案的儲存就是真的寫回原處。

這個編輯器用到的用途
showDirectoryPicker()開一個資料夾,列出裡面的 .md
showSaveFilePicker()另存新檔
createWritable()把新內容寫回同一個檔案

Firefox 與 Safari 的狀況

兩者都實作了規格裡「沙箱」的那一半(OPFS,網頁專用的私有儲存空間), 但沒有開放「使用者自己挑選的資料夾」那一半。原因不是還沒排到,而是它們對這個能力的隱私評估更保守: 一個可以持續寫入使用者目錄的網頁 API,被濫用時的後果不容易補救。

所以在 Firefox 與 Safari 上,這個編輯器會退化成:可以編輯、可以預覽、可以複製, 存檔則變成下載一份新檔案。功能不是壞掉,是瀏覽器沒給那把鑰匙。

為什麼重新載入後又要授權一次

授權是綁在這次瀏覽階段的。你重新載入頁面之後,網頁還記得「上次是哪個資料夾」 (handle 存在 IndexedDB 裡,所以側邊欄能顯示 📂 重新開啟: 資料夾名稱), 但要真的讀寫,必須再一次得到你的同意,而且那次同意必須由你的點擊觸發 —— 頁面不能自己偷偷要。

這就是為什麼流程是「按一下重新開啟 → 瀏覽器問你 → 允許」,而不是自動恢復。 覺得多一步很煩是合理的;但反過來想,這正是「網頁不能在你不知道的時候寫你的硬碟」的保證。

其他前提

檔案到底有沒有離開你的電腦

沒有。這個編輯器沒有後端可以接收檔案 —— 站台只負責把一份 HTML 送給你, 之後的讀取、解析、預覽、寫回都發生在你的瀏覽器裡。詳細的資料處理說明見隱私權政策

下載這一頁的 .md 原始檔 用編輯器打開它,就是一份現成的範例文件。

← 回手冊目錄