若要將 Excel 檔案轉換為 UTF-8，請先識別產生這些位元組的編碼——標準「CSV (逗號分隔)」匯出為 Windows-1252，「Unicode Text」為 UTF-16LE，若使用「CSV UTF-8 (逗號分隔)」則本身就是 UTF-8——然後使用基於檔案的轉換器，將這些位元組重新編碼為不含 BOM 的 UTF-8。Excel 並未提供單一的「另存為 UTF-8 無 BOM」指令，而在 Excel 中重新開啟檔案再存檔，可能會悄悄改寫日期、數字與前導零。基於檔案的轉換會保持原始位元組不變，並在瀏覽器中產生一個可下載的 UTF-8 檔案，無需上傳，方便您在替換前於目標工具中先行驗證。
這之所以重要，是因為 Excel 是「亂碼」(mojibake) 最常見的來源——例如 Müller 或 Łódź 這類名稱，在其他程式中會顯示為 Müller 或 Åódź。之所以會產生這種損壞，是因為 Excel 寫入了 Windows-1252 位元組，而下游工具卻將其當作 Latin-1 或 UTF-8 來解讀。將原始的 Windows-1252 位元組透過符合標準的 Windows-1252 解碼器重新編碼，可將位元組 0x80 (歐元符號) 轉為三個 UTF-8 位元組 E2 82 AC，所有現代工具都能將其讀回 €。同樣的邏輯也適用於彎引號、長破折號，以及 ISO-8859-1 中未定義、Windows-1252 中位於 0x80 至 0x9F 範圍內的字元。
為何 Excel 檔案需要轉換為 UTF-8
Excel 的 CSV 匯出功能早於 UTF-8 的普及，因此其預設文字編碼為 Windows-1252——一種西歐字碼頁，涵蓋大部分帶腔調的拉丁字母，但不含希臘文、西里爾文、希伯來文、阿拉伯文、中日韓表意文字或表情符號。UTF-8 是開放網路、現代資料庫匯入指令碼，以及幾乎所有資料管線所使用的編碼，因此一旦 Excel CSV 離開您的電腦，下游程式碼便預期收到 UTF-8。若檔案中仍含有 Windows-1252 位元組，這些位元組可能會被重新解讀 (進而產生亂碼)，或直接無法通過驗證。
Excel 提供了一系列容易混淆的「另存新檔」選項，雖然聽起來都像 UTF-8，但實際上會產生不同的位元組配置：
| Excel「另存新檔」選項 | 產生的位元組編碼 | 位元組順序記號 | 欄位分隔符號 |
|---|---|---|---|
| CSV (逗號分隔) | Windows-1252 | 無 | 逗號 |
| CSV UTF-8 (逗號分隔) | UTF-8 | EF BB BF (含有 BOM) | 逗號 |
| Unicode Text | UTF-16LE | FF FE | Tab |
| Text (Tab 分隔) | Windows-1252 | 無 | Tab |
「CSV UTF-8」是 Excel 中唯一會寫入 UTF-8 的選項，且必定會加上 BOM。許多指令碼——例如 Python 的 open(..., encoding='utf-8')、awk、shell 的 while read 迴圈，以及大多數 Linux 工具——會拒絕或錯誤處理前導 BOM，因此不含 BOM 的檔案通常才是您真正想要的。
為 Excel 匯出檔案選擇正確的來源編碼
在轉換之前，請先確認檔案實際內容。兩種可靠的判斷方法都無需憑外觀猜測：
- 查看 Excel 的儲存對話方塊。您所選擇的確切「存檔類型」即代表來源編碼。僅「CSV」等同於 Windows-1252。「CSV UTF-8」等同於含 BOM 的 UTF-8。「Unicode Text」等同於含 BOM 的 UTF-16LE。「Text (Tab 分隔)」等同於 Windows-1252。
- 使用十六進位檢視器讀取前幾個位元組。位移 0 處出現 FF FE 表示 UTF-16LE。FE FF 表示 UTF-16BE。EF BB BF 表示含 BOM 的 UTF-8。若無 BOM 且為其他內容，幾乎可以確定是西文版 Excel 匯出的 Windows-1252。
此轉換器不會自動偵測編碼。若您選錯來源，它會直接失敗，而不會產生一個看似正常但已損壞的檔案。這是刻意的設計：相同的位元組序列在多種舊式編碼下可能皆為合法，但代表不同字元，因此自動猜測可能會在檔案其他部分看似正常的情況下，悄悄損壞姓名、標點符號或貨幣符號。嚴格的驗證機制特別適用於 UTF-8 模式——無效的後續位元組、截斷的序列以及禁止的編碼方式，都會導致明確的失敗，而非產生替換字元。
將 Excel 匯出的檔案轉換為 UTF-8
- 根據上表識別來源編碼 (純 CSV 為 Windows-1252，CSV UTF-8 為 UTF-8，Unicode Text 為 UTF-16LE)。
- 開啟 UTF-8 轉換器，並從清單中選擇該來源編碼。
- 點選檔案選擇器，選擇您從 Excel 匯出的檔案。此工具在讀取前會拒絕任何超過 10 MB 的檔案，因此過大的檔案會顯示明確的訊息，而非讓分頁卡住。
- 執行轉換並仔細查看預覽結果。捲動至包含已知非 ASCII 字元的資料列——例如含腔調的客戶姓名、含 € 的貨幣欄位，或含 é 或 ñ 的標頭——確認其顯示正確後再下載。
- 下載結果。檔名會加上 -utf8 後綴，且輸出的位元組為不含 BOM 的 UTF-8，媒體類型為純文字。在您於目標應用程式中驗證新檔案之前，請勿動動原始的 Excel 檔案。
相同的工作流程亦適用於 Tab 分隔的文字匯出檔：選擇 Windows-1252 作為來源，Tab 字元在解碼過程中將原封不動地通過。此工具不會轉譯換行符號；若您的 Excel 檔案使用 CRLF 而目標環境預期 LF，請先解碼，再使用明確指定換行符號的工具重新編碼。
轉換後會產生哪些變化
不同的編碼方式對相同的字元使用不同的位元組長度，因此檔案大小幾乎必然會改變。ASCII 字母在任一編碼下都保持一個位元組，但帶腔調的字元會擴展：
| 字元 | 來源位元組 (Windows-1252) | 輸出位元組 (UTF-8) | 大小變化 |
|---|---|---|---|
| é (U+00E9) | 1 位元組 (0xE9) | 2 位元組 (C3 A9) | 每出現一次增加 1 位元組 |
| € (U+20AC) | 1 位元組 (0x80) | 3 位元組 (E2 82 AC) | 每出現一次增加 2 位元組 |
| 中 (U+4E2D) | 無法表示 | 3 位元組 (E4 B8 AD) | UTF-8 中新增 |
| 🚚 (U+1F69A) | 無法表示 | 4 位元組 (F0 9F 9A 9A) | UTF-8 中新增 |
一個 5 MB、包含歐洲姓名資料的 Windows-1252 CSV，在正確轉換為 UTF-8 後，檔案大小通常會增加約 10–20%，因為每個帶腔調的字母都會多佔用一個位元組；純 ASCII 的匯出檔案則大小完全不變。轉換器會回報來源與輸出的位元組數，讓擴增幅度一目了然，您可以確認其符合編碼變更應有的結果。不同的數字屬預期現象，單憑數字差異並不代表資料遺失。
在取代原始檔案前驗證 UTF-8 輸出
下載並非最後一步。請在實際會使用該檔案的應用程式中——例如 Python 指令碼、資料庫載入器、網頁表單、Notepad 視窗——開啟新的 UTF-8 檔案，並確認以下三點：
- 非 ASCII 的範例字元顯示方式與在 Excel 中相同，包括帶腔調的姓名、貨幣符號，以及任何形式的彎曲標點。
- 若您的下游工具會拒絕 BOM，則前三個位元組不應為 EF BB BF。此轉換器預設即輸出不含 BOM 的 UTF-8。
- 欄數、列數與欄位分隔符號皆未改變。解碼與重新編碼會逐位元組保留來源編碼原本能表示的內容；絕不會合併或拆分欄位。
若預覽畫面出現替換用的菱形 (�)，表示所選的來源編碼至少對檔案中的某部分並不正確。請更換來源並重新轉換，而非試圖「修補」損壞的輸出。更換檔案或來源編碼會清除目前可見的結果，並使先前的下載連結失效，因此重新轉換後請務必重新取得新的下載檔案。
此方法不適用的情境
瀏覽器版的轉換器會將整個檔案載入記憶體，且在達到 10 MB 時停止運作，因此資料庫傾印、多 GB 等級的記錄檔匯出，以及另存為 Unicode Text 的大型 Excel 活頁簿，皆需要具備明確來源與目標編碼的串流轉換工具——例如 Linux 上的 iconv、PowerShell 中的 Get-Content -Encoding 搭配 Out-File -Encoding utf8，或 Python 的 open(..., encoding='cp1252') 接著 open(..., encoding='utf-8', newline='')。此轉換器也無法修復在單一欄位內混合編碼的檔案——一旦兩種編碼的位元組並排出現，沒有任何單一解碼器能同時產生正確的文字，且此工具會以嚴重的解碼錯誤中斷運作，而非悄悄匯出替換字元。未配對或格式錯誤的 UTF-16 代理對 (surrogate) 會因相同原因遭到拒絕：在聲稱轉換成功的同時靜默產生替換菱形，正是符合標準的嚴格解碼機制設計用來預防的失敗模式。
對於已經是合法 UTF-8 但含有前導 BOM 的檔案，移除 UTF-8 BOM 的檔案型指南 說明了選擇 UTF-8 作為來源編碼的相同轉換流程；符合標準的 UTF-8 解碼器會消化掉 BOM，而編碼器則會輸出乾淨的檔案。
若想深入了解，請參閱 PowerShell 將十六進位轉換為文字：安全的 UTF-8 方法。