在 Linux 上，將檔案轉換為 UTF-8 表示將其位元組從產生該檔案的應用程式所使用的字元集重新編碼為幾乎所有現代工具都預期的標準 Unicode 位元組序列，並且完全可以在不開啟終端機的情況下於瀏覽器中完成。UTF-8 轉換器會讀取本地端大小不超過 10 MB 的文字檔，以您所選擇的明確來源編碼(UTF-16 little-endian、UTF-16 big-endian、Windows-1252 或 UTF-8 本身)進行解碼，並輸出一個不含 BOM 的全新 UTF-8 檔案供下載。由於檔案是在瀏覽器的 File 與 Encoding 介面中處理且從不上傳，因此即使在您可能沒有權限安裝 iconv、recode 或任何新套件的嚴格限制 Linux 工作站上，該操作仍保持在本地端執行。其合約刻意設計得很明確:您告訴工具位元組實際上是使用哪種編碼產生的，工具會以致命錯誤處理來驗證來源，並輸出符合標準的 UTF-8，讓您在替換原始檔案之前能夠在目標應用程式中進行測試。
為什麼檔案在 Linux 系統上會以錯誤的編碼呈現
UTF-8 幾乎是所有主流 Linux 發行版以及現代 shell 的語言環境設定中的預設編碼，但您實際處理的檔案未必都是在該預設下產生的。Windows 匯出的檔案可能是以 Windows-1252 編寫，並夾帶一個歐元符號或花式引號;較舊伺服器上的 Java 工具可能輸出了帶有位元組順序標記 (BOM) 的 UTF-16;同事試算表產生的 CSV 可能帶有隱藏的 UTF-8 BOM，使得 shell 腳本出錯;由嵌入式裝置輪替的日誌檔可能使用了廠商特有的單位元組頁面，當使用 cat 開啟時仍會顯示為亂碼。工作流程的 Linux 端本身沒有問題;真正的問題在於生產端與消費端之間歷史遺留下來的編碼不匹配。
通常在您決定如何修正之前，就能判斷編碼有誤。以 Latin-1 讀取 UTF-8 位元組時，開頭顯示為 é 而非 é 的檔案幾乎都是這種情況。充斥替換菱形或問號的檔案，表示所選的解碼器無法同時解讀多個位元組。僅在某個特定位元組位置之後才變成純亂碼的檔案，通常包含一個 UTF-16 BOM，後續的位元組對卻以錯誤的位元序讀取。這些症狀都無法告訴您正確的編碼是什麼，只能說明目前所選的編碼有誤，正因為如此，讓您明確選擇來源的工具會比自動猜測的工具更安全。
UTF-8 轉換器的功能與支援的編碼
此工具圍繞著一個單一規則運作:來源位元組會以您所選擇的 WHATWG 標籤搭配致命錯誤處理進行解碼，接著透過瀏覽器基於標準的 UTF-8 編碼器重新編碼，並透過一個可撤銷的本地 Blob URL 將可下載的檔案暴露出來。共支援四種來源編碼，且工具在沒有明確選擇的情況下拒絕運作，因為同一段位元組序列在多種舊式編碼下可能都是有效的，卻代表不同的字元，所以自動猜測看起來可能合理，實際上仍會損壞姓名、標點或符號。
UTF-8 模式會以致命錯誤處理來驗證來源:無效的接續位元組、截斷的序列以及禁止的編碼都會導致明確的失敗，而不是產生替換字元。前端的 UTF-8 位元組順序標記會由標準解碼器消化，而下載結果由 UTF-8 編碼器輸出時不會附加 BOM，因此可以直接放進 shell 腳本與 Unix 文字處理管線中使用，沒有安全疑慮。UTF-16LE 與 UTF-16BE 模式的差異在於位元組順序:即使位元組對仍可讀取，若位元組順序顛倒，檔案中的字母仍會變成亂碼。對於低位元組先儲存的格式請選擇 little-endian，對於高位元組先儲存的格式請選擇 big-endian，相符的 BOM 將被辨識並移除。輔助平面字元(例如表情符號)使用 UTF-16 代理對;解碼器會將有效的高位代理與低位代理合併為單一 Unicode 純量值，再輸出為 UTF-8;未配對或格式錯誤的序列會在致命解碼模式下被拒絕。Windows-1252 是常見的西方舊式代碼頁，常被誤標為 ISO-8859-1;瀏覽器中標準定義的 Windows-1252 解碼器會在 0x80 至 0x9F 位元組範圍內(包括歐元符號與花式引號)提供可列印的標點與符號，接著再重新編碼為 UTF-8。
支援的來源編碼一覽
| 來源編碼 | 常見來源 | BOM 處理 | Linux 上常見的失敗模式 |
|---|---|---|---|
| UTF-8 | 現代編輯器、Linux 工具、網頁匯出 | 前端的 BOM 會被消化;輸出檔案不帶 BOM | 若腳本覆寫了非 ASCII 位元組，則會出現替換菱形 |
| UTF-16LE | Windows Notepad、部分 JVM 上的 Java 預設值、部分 XML 匯出 | 相符的 BOM 會被辨識並移除 | 當被誤以 UTF-16BE 解碼時，字母對會互換 |
| UTF-16BE | 較舊的 Mac OS X 工具、部分 Java 環境、網路通訊協定 | 相符的 BOM 會被辨識並移除 | 當被誤以 UTF-16LE 解碼時，字母對會互換 |
| Windows-1252 | Windows 軟體、舊式 CSV 匯出、ANSI 編碼的日誌 | 不適用;為單一位元組舊式頁面 | 亂碼，例如將花式撇號顯示為 ’ |
來源與輸出大小之間的關係僅為性質上的描述:範圍在 0x80 至 0x9F 之間的 Windows-1252 位元組，在重新編碼後會變成兩個或三個 UTF-8 位元組，因此大多數西歐西歐檔案會略微變大，而純 ASCII 內容的大小則完全保持不變。頁面會顯示來源與輸出的位元組計數，讓您能夠看到變化，但不同的計數屬於預期情況，本身並不代表資料遺失。
在瀏覽器中將檔案轉換為 UTF-8:逐步說明
- 從產生該檔案的應用程式或可靠的詮釋資料中識別來源編碼。如果您不知道，檔案的症狀(替換菱形、字母對互換、經典的 é 亂碼)只能縮小可能性範圍;您仍必須挑選與檔案實際編寫方式相符的那一個。在您的 Linux 工作站上以瀏覽器開啟 UTF-8 轉換器。
- 在挑選檔案之前，請先於選擇器中選擇來源編碼。四個支援的選項為 UTF-8、UTF-16LE、UTF-16BE 與 Windows-1252。對於 UTF-16，請透過參考產生該檔案之應用程式的說明文件、檔案開頭的 BOM，或使用 xxd 進行快速的十六進位檢查，來決定檔案是低位元組先儲存(小端)還是高位元組先儲存(大端)。
- 從您的本地磁碟中選擇一個不超過 10 MB 的文字檔。系統會在讀取前先檢查大小，以避免載入意外過大的檔案;若您需要轉換一個數 GB 的日誌檔或資料庫傾印檔，請改用 Linux 主機上具備明確來源與目標編碼的可信任串流轉換工具。
- 等待預覽渲染完成，並仔細檢查解碼後的字元。檢視代表性的姓名、標點、貨幣符號，以及促使您進行轉換的那些非 ASCII 行。開頭相符的 BOM 會自動被消化;若預覽中仍殘留替換菱形或零星的 ?，這通常表示所選的來源編碼有誤。
- 下載結果檔案(其名稱結尾為 -utf8)，並在目標應用程式(shell 腳本、編輯器、資料庫載入器、支援 CSV 的工具)中開啟。將其與原始檔案進行比對，並針對您所關注的那些字元進行小幅抽樣檢查。請保留原始檔案，直到整個工作流程驗證完成後再進行替換。
如果預覽看起來不正確，請更改來源編碼選擇，頁面會取消可見的結果並使先前的下載 URL 失效;任務識別機制可避免較慢的舊檔案讀取作業取代較新的選擇，而過時的物件 URL 也會被撤銷，讓您不會意外下載到陳舊的結果。如果來源檔案中混用了多種編碼，單一解碼器無法可靠地修復，您需要先將其拆分或重新匯出來源檔案。
Linux 命令列工具與基於瀏覽器的轉換器之比較
Linux 長期以來一直支援在命令列進行檔案編碼轉換，而標準工具就是 iconv，可使用 iconv -f SOURCE -t UTF-8 input.txt -o output.txt 在幾乎任何一對字元集之間重新編碼。對於需要轉寫的檔案，可在後方附加 //TRANSLIT;對於應在遇到無法轉寫的位元組時失敗的檔案，請謹慎附加 //IGNORE。其他選項還包括 recode(對於常見情境具有更友善的語法)以及 vim 本身(可在其中設定 :set fileencoding=utf-8 並儲存)。這些工具非常適合批次腳本、伺服器自動化以及非常大型的檔案，而其所產生之 UTF-8 線路格式背後的標準定義於 RFC 3629 中。
基於瀏覽器的轉換器則適用於不同的利基。它不需要 shell 存取權，不需要安裝任何東西，並讓您能在下載之前透過預覽視覺化地驗證解碼後的字元。它還強制執行明確的編碼選擇搭配致命驗證，可在解碼時捕捉到損壞的 UTF-8 序列，而不是產生一個默默損毀的檔案。對於在能使用瀏覽器但無法執行套件管理器的工作站上進行快速的一次性轉換，該預覽正是修好檔案與推出更糟版本之間的差別。此工具所依循的 WHATWG 編碼規則記載於 WHATWG Encoding Standard，此標準與現代瀏覽器內部使用的參考資料相同。
在 Linux 工作流程中驗證已轉換的檔案
下載完成後，幾個快速的 shell 檢查即可確認檔案是否如工具所宣稱的那樣。file -i output-utf8.txt 應回報 charset=utf-8 且不應提及 BOM;若提及，則表示來源實際上並沒有可消化的 BOM。head -c 3 output-utf8.txt | xxd 會顯示前三個位元組;包含 ASCII 或帶變音符號之拉丁文字的純 UTF-8 檔案，開頭是其第一個字元的 ASCII 位元組，而非 ef bb bf。iconv -f UTF-8 -t UTF-8 output-utf8.txt > /dev/null 會對檔案進行來回轉換，僅在位元組不是有效的 UTF-8 時才會以非零狀態退出，這是轉換過程是否乾淨的強烈信號。
對於來源為 Windows-1252 的檔案，值得記住一個具體的數值範例。Windows-1252 位元組 0x80 對應到 Unicode 字元 U+20AC(歐元符號 €)，該單一來源位元組會在重新編碼後變成三個 UTF-8 位元組 E2 82 AC。其算術關係為一個位元組輸入、三個位元組輸出，因為 U+20AC 落在三位元組 UTF-8 範圍(碼點 U+0800 至 U+FFFF)中。每當您看到一個名目上是 Windows-1252 的檔案大約以該比例變大時，這種膨脹就是從單一位元組舊式頁面移轉至 UTF-8 的預期成本;若檔案反而縮小或大小維持不變，則來源實際上是純 ASCII 或已經是 UTF-8。
常見的 Linux 專有陷阱與避免方式
第一個陷阱是字元集本身。在 Linux 機器上執行 locale 指令時，每個分類都可能顯示 UTF-8，這會讓人誤以為所有文字工具都已經在編碼上達成共識，但這只影響 shell 顯示檔案的方式，而非檔案原本的編碼方式。即使在 UTF-8 系統上，Windows-1252 的 CSV 仍然是 Windows-1252。第二個陷阱是輕信自動偵測工具，例如 file --mime-encoding 或 Python 的 chardet；兩者都是統計式的，對於內容較短或包含大量符號的檔案，經常會選出一個看起來合理但其實錯誤的結果。這款轉換器透過要求明確指定來源編碼來避開這個問題。第三個陷阱是 BOM：許多 Unix 工具（例如 grep、awk 和 C 前處理器）都預期檔案不含 BOM，而從 Windows 編輯器匯出的 UTF-8 BOM 可能會讓每一行的第一欄位移三個不可見位元組，導致輸出內容莫名其妙地錯位。由於這款轉換器會移除任何已辨識的來源 BOM，並在輸出 UTF-8 結果時不再附加 BOM，因此下載的檔案可以乾淨地接入標準的 Unix 管線流程。第四個陷阱是換行字元：除了解碼與重新編碼為 UTF-8 必然帶來的變化之外，這個工具不會修改換行字元，因此來自 Windows 的 CRLF 來源在轉換後，仍會是一個包含 CRLF 的 UTF-8 檔案。若您同時需要 LF 換行以便下游僅能在 Linux 上執行的工具使用，請在 Linux 上執行 sed -i 's/\r$//' output-utf8.txt，並將此視為一個獨立的步驟，而非期待轉換器代為處理。
檔案轉換完成、經過驗證並複製到定位後，就可以將原始檔案封存。在此之前，請將原始檔案與新檔案並存，這樣您就能在編輯器中逐字元比對兩者，或是在兩者皆以 iconv 重新編碼為 UTF-8 之後，使用 diff 進行比對。正是「明確指定來源」、「遇到錯誤立即中止的驗證」、「可見的預覽」以及「在 Linux 主機上額外進行的驗證步驟」這些設計的結合，讓整個作業流程能夠從頭到尾都可被稽核。
如果您正在權衡各種方案，在不憑猜測的情況下，使用 Notepad++ 將檔案轉換為 UTF-8 一文對此有詳細說明。
如果您正在權衡各種方案，Vigenere 密碼解碼器：命令列工具與線上工具的比較 一文對此有詳細說明。