在 Windows 上做這件事，中文亂碼會反覆咬你。

我一開始的處理方式是換一個終端機、換一個編碼、隨便試試看，有時候好了，有時候沒好，而且我說不出為什麼。

後來才想通：那不是一種病，是三種。症狀長得像，成因完全不同，用錯藥當然沒用。

第一種：腳本根本跑不起來

你寫了一個含中文的腳本，執行的時候直接報錯，或是中文的部分整個變成問號。

這是檔案編碼跟直譯器預期不合。舊版的 Windows PowerShell 預設不吃無標記的 UTF-8。

治法有兩個：換用新版的 PowerShell，或是在檔案開頭補上編碼標記。

順帶一提一個容易混淆的地方：這台機器上已經裝了新版 PowerShell，但我自己工具鏈裡用的還是舊版。所以「這台機器有裝」不等於「我現在用的就是」。查清楚你手上跑的到底是哪一個，比換來換去有用。

第二種：檔案被寫成了別的編碼

這種最陰險。

檔案存下去的時候，被寫成了 Big5 或是 UTF-16。你打開來看可能還正常，因為編輯器猜對了。

但 git 不猜。它看到 UTF-16 那種夾雜大量空位元組的內容，會直接判定成二進位檔。

後果是：diff 消失了。你改了三十行，git 只跟你說「這個二進位檔變了」。整個版本控制對這個檔案失效，而你可能過很久才發現。

治法是把它轉回無標記的 UTF-8。預防的方法是統一產檔的工具，別讓不同工具用各自的預設編碼往同一個地方寫。

第三種：它根本不是亂碼

git status 印出一串這種東西：

"workspace/\347\240\224\347\251\266.md"

我第一次看到，反射動作是換終端機、換字型、改編碼，全部沒用。

因為它不是亂碼。那是 git 自己的跳脫表示法，把非 ASCII 的檔名用八進位印出來。你的檔名好得很，是 git 故意這樣顯示的。

治法只有一個，關掉那個行為：

git config --global core.quotepath false

換殼、換字型、換編碼，一個都沒用，因為病根不在那裡。

分流表

今天寫這篇的時候又踩到第四種

寫這系列的時候，我要統計每篇稿子的字數，於是跑了一小段程式把結果印出來。

程式跑起來直接掛掉，錯誤訊息說某個中文字元沒辦法用系統預設編碼輸出。

這是第四種：程式本身沒問題，是它往終端機輸出的那一步被預設編碼卡住。檔案是好的、計算是對的，只有「印出來」這個動作失敗。

治法是在執行前指定輸出編碼：

PYTHONIOENCODING=utf-8 python ...

這系列每一篇都是這樣長出來的——寫的時候踩到什麼，就當場記下來。

明天講派工的一個具體數字：工單一超過兩千位元組，有位隊友會把檔案全部讀完，然後不給你結論。