在 Windows 中變更 UTF-8 通常意味著將以其他編碼儲存的本地文字檔，轉換為格式正確且不含 BOM 的 UTF-8 位元組。Windows 仍內建許多舊版應用程式、主控台腳本和 PowerShell 管線，這些工具預設使用 Windows-1252 或 GBK 等單位元組字碼頁，甚至舊版記事本預設會產生 UTF-16 little-endian 檔案。當這類檔案在伺服器、網路服務或其他嚴格要求 UTF-8 的應用程式中開啟時，名稱、標點符號和非 ASCII 符號可能會在不知不覺中變成替換字元或亂碼。可靠的解決方式並非重新輸入文字，而是以實際產生該檔案的編碼來解碼位元組，然後將結果重新編碼為 UTF-8。UTF-8 轉換器正是執行這項作業：它在瀏覽器中本地讀取您的檔案，依您選擇的編碼解碼位元組，使用嚴格錯誤處理進行驗證，然後輸出一個可下載的 UTF-8 檔案，該檔案會吸收任何來源位元組順序標記，而不是將其原封不動地複製過去。
為何在 Windows 上猜測來源編碼會失敗
Windows 文字檔是一個特別容易出錯的陷阱，因為相同的位元組序列依產生它的字碼頁不同，可能代表不同的字元。位元組 0x80 在 ISO-8859-1 中是不可列印的控制字元，但在 Windows-1252 中則代表歐元符號 (€)。一對在 UTF-16 little-endian 中看起來像可讀字母的位元組，一旦位元組順序倒，在 UTF-16 big-endian 中就可能變成亂碼，即使這些位元組本身仍落在可列印的 ASCII 範圍內。那些聲稱能偵測編碼的工具依賴對位元組流的統計啟發式方法，而這些啟發式方法是機率性的：對於短檔案、以 ASCII 為主的檔案，或混合 ASCII 標點與少數帶重音名稱的檔案，它們可能會回傳一個看似肯定但錯誤的答案。猜錯的代價是無聲的損毀，而且通常沒有替換字元的警告來提醒您，某個 Windows-1252 的歐元符號位元組（例如 0x80）已被轉換為不可列印的控制字元。安全的工作流程是根據產生該檔案的應用程式設定或可靠的元數據來確定來源編碼，然後向轉換器明確聲明該編碼。保持明確的選擇可使轉換過程可稽核：若預覽顯示正確的字元，您就知道是哪個解碼器產生了這些字元，轉換過程日後也能重現或反轉。
轉換器接受的編碼
UTF-8 轉換器接受四種來源編碼，並在所有情況下重新輸出 UTF-8，因此您選擇的模式必須符合檔案本身，而非文字的外觀。下表概述每種支援的來源編碼、它在 Windows 中典型的來源檔案類型，以及當它與其他編碼混淆時會產生的特定問題。
| 來源編碼 | Windows 中典型的來源 | 需要注意的細節 |
|---|---|---|
| UTF-8 | 現代編輯器、網頁匯出檔、經驗證的資料庫 | 使用此模式來驗證位元組序列並去除不需要的 BOM |
| UTF-16 little-endian | PowerShell Out-File、舊版記事本組建、Windows 剪貼簿文字 | 前兩個位元組為 FF FE；若與 UTF-16BE 交換，每個字元都會變成亂碼 |
| UTF-16 big-endian | Windows 上的跨平台匯出檔和 Java 工具 | 前兩個位元組為 FE FF；僅在選擇相同的位元組順序時才能無損往返轉換 |
| Windows-1252 | 舊版西歐文字、傳統 ANSI 檔案、區域主控台輸出 | 位元組 80 至 9F 包含歐元符號和花式引號，而 ISO-8859-1 將這些位元組留為未定義 |
最簡單的情況就是 UTF-8 本身：一個已經是 UTF-8 的檔案可以透過轉換器來驗證其位元組序列並去除多餘的位元組順序標記。UTF-16 little-endian 是 PowerShell Out-File 和許多舊版記事本組建預設產生的格式，其前兩個位元組通常依序為 FF FE。UTF-16 big-endian 則將這對位元組交換為 FE FF，主要出現在從非 Windows 系統或跨平台工具匯出的檔案中。Windows-1252 是舊版 Windows 應用程式中常被誤標為 ISO-8859-1 的舊式西歐字碼頁；在 ISO-8859-1 中屬於不可列印的 0x80 至 0x9F 範圍位元組，在 Windows-1252 中則包含歐元符號和花式引號，瀏覽器提供的符合標準的 Windows-1252 解碼器會在重新編碼為 UTF-8 之前先套用這些對應。
如何在 Windows 上將檔案轉換為 UTF-8
一旦知道來源編碼，將 Windows 文字檔轉換為 UTF-8 便只是選擇檔案、挑選正確的解碼器，並在下載前檢查預覽的過程。
- 根據產生該檔案的應用程式或任何可靠的檔案元數據來識別來源編碼。
- 在瀏覽器中開啟 UTF-8 轉換器。
- 選擇與檔案相符的來源編碼（UTF-8、UTF-16LE、UTF-16BE 或 Windows-1252）。
- 使用檔案選擇器從本機磁碟選擇文字檔案（最大 10 MB）。
- 轉換檔案並檢查預覽，特別留意名稱、標點符號和涉及非 ASCII 範圍的貨幣符號。
- 下載產生的 UTF-8 檔案。瀏覽器會在檔名後附加 -utf8，並以不含 BOM 的純文字 UTF-8 檔案形式提供。
- 在目標應用程式中開啟下載的檔案，並確認字元正確顯示。
- 在完整工作流程端對端驗證完成之前，保留原始檔案。
讀取位元組順序、BOM 與代理對
有三個小細節可以解釋為何一個 UTF-16 檔案即使其位元組看起來可列印，最終仍會變成亂碼，以及為何轉換器會謹慎處理它們而非進行猜測。
位元組順序對每個 UTF-16 檔案都很重要，因為每個字元都以兩個特定順序的位元組儲存。UTF-16LE 先儲存低位元組，UTF-16BE 則先儲存高位元組；若位元組順序顛倒，即使位元組對在 ASCII 範圍內仍看似可讀，檔案中的字母仍可能變成亂碼。讀取時會識別相符的位元組順序標記，並由符合標準的解碼器將其吸收，因此來源 BOM 不會出現在下載的 UTF-8 輸出中，也不會新增任何 BOM。由 WHATWG 編碼標準定義的瀏覽器端編碼器會從解碼後的字元輸出乾淨的 UTF-8 位元組。
表情符號或歷史文字等輔助字元位於基本多語言平面之外，並以 UTF-16 代理對進行編碼。解碼器會將有效的高位代理與低位代理組合成單一 Unicode 純量值，再產生 UTF-8 輸出。未配對或格式錯誤的序列會在嚴格解碼模式下被拒絕，而非以替換符號的形式靜默輸出，因此不完整的 UTF-16 檔案會產生明確的失敗，而非「成功」下載到損毀的文字。無效的後續位元組、截斷的序列以及禁止使用的編碼都會發同樣的嚴格行為，這使轉換過程保持誠實。
在替換原始檔案之前驗證已轉換的檔案
成功下載並不等同於正確轉換。請將下載的 UTF-8 檔案視為一個候選檔案，在刪除原始檔案之前，確認它確實能在目標應用程式中正常運作。
頁面會在轉換後並列顯示來源位元組數與輸出位元組數，因此任何擴增或縮減都一目了然。不同的數量是預期中的情況，並不單獨代表資料遺失：Windows-1252 的歐元符號位元組 0x80 會變成三個 UTF-8 位元組 E2 82 AC，而以 ASCII 為主的檔案大小則幾乎不變。預覽有助於在下載前抓出明顯錯誤的選擇，但它可能無法顯示每個控制字元或每個正規化差異，因此請手動檢查具代表性的名稱、標點符號、貨幣符號和非 ASCII 行。若來源檔案內含混合編碼，單一解碼器無法可靠修復，應針對每個乾淨的區段重複執行轉換。更改檔案或來源編碼會取消可見的結果並使先前的下載 URL 失效，因為每個新選擇都會獲得自己的工作識別，而先前的物件 URL 會被撤銷。這種行為是有意為之：它能防止較慢的舊檔案讀取在不知不覺中取代較新的選擇。
當 10 MB 限制與混合編碼迫使您另尋他途
轉換器在瀏覽器中使用 File 與 Encoding 介面於記憶體緩衝區上執行，並在讀取前檢查大小以避免載入意外的大型檔案。10 MB 的上限涵蓋典型的組態檔、腳本、CSV 匯出檔、日誌摘錄以及需要變更編碼的電子郵件封存檔。對於資料庫傾印檔或數 GB 的日誌，您應改用具備明確來源與目標編碼的可信串流轉換工具，因為將這類檔案載入瀏覽器分頁只會直接失敗。
在同一緩衝區內結合多種編碼的檔案也超出範圍：因為沒有單一的來源編碼可以聲明，任何單一解碼器都會損毀那些並非由它產生的區段。請沿著您能識別的邊界分割檔案，使用相符的來源編碼將每個區段分別執行轉換，然後再將各部分重新合併。下載的檔名會加上 -utf8 並使用純文字 UTF-8 的媒體類型，這正是大多數網頁伺服器和現代編輯器所預期。底層實作中使用了八個外部測試案例，涵蓋 ASCII UTF-8、多位元組 UTF-8、UTF-8 BOM 處理、含表情符號的兩種 UTF-16 位元組順序、兩種 UTF-16 BOM，以及 Windows-1252 標點符號；測試會比對精確的解碼文字與精確的重新編碼 UTF-8 位元組，而格式錯誤的 UTF-8 必須失敗。若有工具宣稱能偵測其中某個測試案例的編碼並回傳看似肯定的結果，它很可能只是在猜測而非驗證，您應改用像本工具這樣明確的解碼器。
如需更深入的說明，請參如何使用 UTF-8 編碼器轉換 Unicode 文字。
如需更深入的說明，請參ASCII 碼轉換器範例：文字與十進位互轉。