繁簡亂碼轉換器 (GBK/Big5)：解決網頁與檔案亂碼的編碼救星
什麼是繁簡亂碼轉換器？
繁簡亂碼轉換器 (Encoding Converter) 是為了解決中文網路世界長久以來的「編碼衝突」問題。在 Unicode (UTF-8) 普及之前，繁體中文主要使用 Big5 編碼，而簡體中文使用 GBK (或 GB2312) 編碼。這兩套系統互不相容。
當您用繁體中文系統開啟一個簡體編碼的文字檔（如 .txt 歌詞、字幕檔），或者瀏覽一個老舊的簡體網站時，電腦會錯誤地用 Big5 邏輯去解讀 GBK 代碼，結果就是呈現出一堆無意義的符號（如「锟斤拷」、「燙燙燙」等知名亂碼）。本工具能精準識別並在 Big5、GBK、UTF-8 之間進行轉碼，瞬間將外星文還原為可閱讀的中文。
誰適合或需要使用這個工具？
只要您會接觸到跨兩岸三地的數位檔案，這個工具就是必備的：
1. 程式開發者與工程師：
維護老舊資料庫 (Legacy System) 時，常會遇到資料庫是 Big5 但網頁是 UTF-8 的痛苦整合問題。或者需要處理兩岸資料串接 API 時的編碼轉換。
2. 電子書與小說讀者：
從網路下載的 TXT 小說檔，打開來全是亂碼？通常是因為那是 GBK 編碼的檔案。複製進來轉一下，馬上能看。
3. 字幕組與影視愛好者：
下載的 SRT/ASS 字幕檔掛載到影片上變成方塊字？因為播放器預設讀取 UTF-8，但字幕檔是 ANSI/Big5。轉換編碼後存檔即可解決。
4. 行政文書人員：
收到中國客戶寄來的 CSV 報表，用 Excel 打開全是亂碼？這是 Excel 預設編碼誤判的問題。先修復亂碼再開啟，資料才不會錯亂。
5. 遊戲玩家：
玩一些非官方中文化的老遊戲或模組 (Mods)，常會遇到文字顯示錯誤，這通常也是字型編碼不對應所致。
亂碼產生的每個因子如何影響結果？
知己知彼，才能解開亂碼之謎：
1. 編碼標準 (Encoding Standards)：
* Big5：台灣、香港常用的繁體編碼。收錄字數較少（約 1.3 萬字），遇到罕見字（如「喆」、「堃」）容易缺字或變成「?」。
* GBK：中國大陸常用的簡體編碼。收錄字數多（2 萬多字），包含繁體字，但編碼位置與 Big5 完全不同。
* UTF-8：萬國碼，現代網頁標準。它能同時顯示繁簡中日韓與各國語言，是解決亂碼的終極方案。
亂碼通常發生在「用 Big5 的解碼器去讀 GBK 的內容」。
2. 字型支援 (Font Support)：
有時候不是編碼錯（值是對的），而是您的電腦沒有安裝對應語言的字型，導致顯示為「方框 (□)」。這叫缺字 (Tofu)，嚴格來說不算亂碼，解法是安裝中文字型。
3. BOM (Byte Order Mark)：
在 UTF-8 檔案的開頭，有時會藏著幾個隱形位元組 (EF BB BF) 用來標示編碼。有些軟體（如 PHP 老版本或某些編輯器）看不懂 BOM 會報錯或顯示亂碼。轉換工具可協助去除或添加 BOM。
4. 全形與半形：
轉換過程中，有時標點符號會跑掉。GBK 的全形空白與 Big5 的全形空白編碼也不同，轉換時需特別注意標點的對應。
轉換結果代表什麼意思？
使用本工具後，您可能會看到幾種結果：
1. 完美還原：
亂碼變成了通順的中文。這代表您選對了「來源編碼 (Source)」與「目標編碼 (Target)」。例如：來源 GBK -> 目標 Big5。
2. 還是亂碼，但樣子變了：
這代表您選錯了來源編碼。例如檔案其實是 UTF-8，您卻選了 GBK 去轉。請嘗試切換來源選項。
3. 變成「」或「?」：
這代表「缺字」。來源編碼有的字，目標編碼沒有。例如 GBK 裡有很多簡化字在 Big5 裡根本沒有對應的編碼位置，系統只好用問號代替。解決方法是轉成 UTF-8，因為 UTF-8 包山包海，絕對不會掉字。
4. 繁簡轉換 (Translation)：
注意，「編碼轉換 (Encoding)」不等於「繁簡翻譯 (Translation)」。
* 編碼轉換：把 GBK 的「体」轉成 UTF-8 的「体」。(字沒變，只是電腦存法變了)
* 繁簡翻譯：把「体」變成「體」。(字變了)
本工具主要處理編碼，但也常與繁簡翻譯功能搭配使用。
轉換成功後，該採取什麼行動？
為了長治久安，請養成良好的編碼習慣：
1. 統一存成 UTF-8：
這是最重要的一點。無論原本是 Big5 還是 GBK，修復後請一律存檔為 UTF-8 Without BOM。這是目前世界通用的最安全格式，保證在任何電腦、手機、瀏覽器上都能正常顯示。
2. 修正網頁 Meta 標籤：
如果您是開發者，發現網頁亂碼，請檢查 HTML 檔頭是否宣告了 `<meta charset="UTF-8">`。這能告訴瀏覽器「請用 UTF-8 來讀我」，避免瀏覽器猜錯。
3. 檢查資料庫校對 (Collation)：
MySQL 資料庫亂碼常是因為連線字串 (Connection String) 沒設定 charset=utf8mb4，或者資料表校對設成了 latin1。請從源頭修正。
4. 備份原始檔：
在進行任何批次轉碼前，務必備份原始檔案。編碼轉換是破壞性的，一旦轉錯並存檔，有時候無法逆向還原（例如變成一堆問號後就救不回來了）。
常見問題 (FAQs)
Q1: 為什麼會有「锟斤拷」這種奇怪的亂碼？
這是一個經典的編碼錯誤。當 UTF-8 的「 (Replacement Character, EF BF BD)」被重複多次，並錯誤地用 GBK 解碼時，就會剛好對應到 GBK 裡的「锟(EFBF)」、「斤(BDEF)」、「拷(BFBD)」。看到它，就知道是 UTF-8 被誤當成 GBK 讀了。
Q2: 以前的「像是掛」或「許功蓋」問題是什麼？
這是 Big5 編碼著名的「衝碼」問題。因為 Big5 的編碼範圍包含了一些特殊位元組（如 0x5C，即反斜線 \），許多程式語言會把它當作跳脫字元 (Escape Character) 處理，導致「許、功、蓋、餐」等字後面的字元被吃掉或報錯。解決方法一樣是：轉成 UTF-8 就沒事了。
Q3: 繁體跟簡體可以直接互轉嗎？會有錯字嗎？
可以，但有風險。因為繁簡不是一對一的，是「一對多」。例如簡體的「发」對應繁體的「發（發財）」和「髮（頭髮）」。簡單的轉換程式可能會把「頭髮」轉成「頭發」。高品質的轉換需要依賴詞庫上下文判斷（本工具致力於提供高準確度轉換）。
Q4: 記事本 (Notepad) 另存新檔能解決嗎？
可以。用 Windows 記事本開啟亂碼檔（如果它夠聰明猜對編碼），顯示正常後，選擇「另存新檔」，編碼選「UTF-8」，通常就能修復最簡單的案例。
Q5: 什麼是 Unicode？
Unicode 是電腦科學界的「秦始皇統一度量衡」。它給世界上每個字元（包含中文、英文、Emoji、古埃及文）一個獨一無二的編號。UTF-8 是 Unicode 的一種儲存方式。使用了 Unicode，從此不再有亂碼問題。
References & Data Sources
- Unicode 與 UTF-8 的關係(Wikipedia)
- Big5 編碼表(Big5 Code Chart)
- 中文亂碼生成的原理(The Will Will Web)