我以為非 UTF-8 太邊角，結果打開打一個字就會把亂碼存回去

9 月 22 日中午我說，純文字也該能改。接著又說，非 UTF-8 那些實在太邊角。如果不做，txt 會變亂碼嗎。

先量了。Big5、GB18030、Shift-JIS、有 BOM 的 UTF-16，當時的偵測都認得出來。沒有 BOM 的 UTF-16 被看成 Latin-1，打開就是一串亂碼。那天 txt 還是唯讀，亂碼停在畫面上，檔案還在。改成能編輯之後，打一個字，自動存檔就會把亂碼寫回去。原本的內容救不回來。這不算邊角。打開、打字，就會發生。

---

所以只放行 UTF-8。其他編碼維持唯讀，畫面上寫明：要編輯，另存成 UTF-8。唯讀的 txt 本來連另存都按不了，這條路要單獨打開，另存出來的那份當場就能改。能不能改，每次問文件本身，不在打開時抄一份就再也不改。

測試裡還抓到另一個洞。沒有 BOM、內容又全是英文的 UTF-16，位元組看起來像合法的 UTF-8，會被放行成可編輯。樣本改成帶一個中文字，偵測才落到該唯讀的那一側。

同一天早上我還問過，關掉再開為什麼總是回到第一行。那是看 agent 寫的長文件會一直碰到的事。我要 HTML 跟 PDF 一起做，三種視窗體驗才一致。Markdown 記頂行跟游標，PDF 記頁碼，最多一百個最近的檔。指定了行號的開啟蓋過紀錄。純文字這次沒排進這份記憶。

偵測錯的那一種，今天唯讀還救得回來。改成能編輯之後，打一個字就存不回來了。

收尾

Markdown 自己其實也會在存檔時默默轉成 UTF-8。txt 先擋，是因為記事本、舊 log、Big5 真的會出現。Markdown 幾乎都是 UTF-8，這次先不去動它。

先不說了，我得去開一份沒有 BOM 的 UTF-16，確認它還是唯讀。

這件事發生於 2026 年 9 月 22 日，文章整理於 2026 年 10 月。