TXT 小說變成亂碼：Big5 編碼怎麼修

你打開一個 .txt，畫面上不是中文，而是一堆奇怪的符號。檔案多半沒壞。位元組都在，只是被用錯誤的對照表讀出來。

為什麼會這樣

純文字檔不會在檔案裡註明自己用什麼編碼。它就是一串位元組，怎麼解讀由開啟它的程式決定。

繁體中文的舊檔案幾乎都是 Big5。從 BBS 精華區流傳下來的小說、早年的個人網頁存檔、老軟體匯出的文字，大多屬於這一類。

Big5 和 GBK 都用兩個位元組表示一個漢字，而且兩個位元組的最高位元都是 1。當這些位元組被當成 Latin-1 讀出來，每一個漢字就變成兩個帶重音的拉丁符號。

所以亂碼有個明顯的樣子：畫面上的字數大約是原文的兩倍，而且夾雜大量 § ª ¥ ¡ 這類符號。看到這個形狀，幾乎可以確定是中文編碼被當成西歐編碼讀了。

如果整體正常，只有零星幾個字變成問號或方塊，那多半是字集範圍的問題，不是整體編碼猜錯。

Big5 原始字集收的字有限，香港的粵語用字和一些罕用字要靠 Big5-HKSCS 增補才有。用標準 Big5 去讀含增補字的檔案，就會只有那幾個字壞掉。

講清楚比較好：Aurora Reader 先試 UTF-8，失敗就退回 Latin-1。它不會偵測 Big5，設定裡也沒有選擇編碼的地方。

Latin-1 同時解釋了為什麼你看到的是亂碼而不是錯誤訊息。在那個編碼裡每個位元組都對應得到某個符號，所以退路永遠「成功」，只是給出錯的字。

在電腦上對副本轉檔，然後把轉好的檔案傳回手機：

iconv -f BIG5 -t UTF-8 book.txt > book-utf8.txt

如果只有少數字轉不過去而中斷，改用 -f BIG5-HKSCS 再試一次，它的收字比標準 Big5 多。

有些從網路流傳的檔案其實是 GBK，只是內容看起來像繁體。轉錯了會出現「一半正常一半亂碼」，這時改成 -f GBK。

Windows 上用記事本另存新檔、編碼選 UTF-8 也可以，但大檔案會很慢。

一律拿副本操作：指定錯編碼的轉檔是不可逆的。

有時候相反：裡面的文字正常，解壓縮出來的檔名卻是亂碼。

這是另一回事。ZIP 格式長期沒有規定檔名的編碼，Windows 的壓縮軟體用 Big5 寫入檔名，而 Android 上的解壓縮工具通常假設 UTF-8。內容不受影響。

檔案不多就直接改名最快。數量多的話，在電腦上用可以指定檔名編碼的解壓縮軟體處理完，再傳過去。

還有一種情況：字都是對的，但目錄空空如也，整本三百萬字擠成一團。

這不是編碼問題。App 偵測章節時比對的是 Chapter 1、CHAPTER IV、Part 2 這幾種英文寫法，中文的「第一章」「第十七回」不在其中，所以中文 TXT 幾乎不會產生目錄。

同一段程式還有一個連帶影響：字數是用空白切開來數的。中文不用空白分詞，所以一本長篇小說可能只被算成幾千個「詞」，估出來的頁數因此嚴重偏低。

這兩點也一併回報給 App 專案了：章節偵測和字數計算。目前的替代做法是找同一本書的 EPUB 版本，章節結構本來就寫在檔案裡。

壞掉的檔案通常打不開，或讀到一半中斷。整本從頭到尾穩定地顯示錯字，代表位元組是完整的。差別寫在判斷檔案是否損壞。

改副檔名沒有用，因為副檔名和內容的位元組毫無關係。

如果字是對的，但某些字長得怪怪的，那既不是編碼也不是損壞，而是字型。

Noto Sans CJK 這類字型分成 TC、SC、JP、KR 幾個版本，同一個碼位在不同版本裡的字形不一樣。用日文版讀繁體中文，「骨」「直」「戶」這些字會顯示成日文的寫法；用簡體版則可能整批缺字，變成空白方塊。解法是換成繁體中文字型。

同一本書有 EPUB 就拿 EPUB。EPUB 把編碼寫在檔案裡，這個問題根本不會發生。中文維基文庫的 EPUB 匯出就是為此好用。