在 Notepad++ 中轉換為 UTF-8 實際上代表什麼
在 Notepad++ 中轉換為 UTF-8 不只是在選單列上點選「Encoding → Convert to UTF-8」。這個操作只會重新解碼檔案中既有的位元組，因此可能會保留亂碼、在沒有任何警告的情況下替換名稱和符號，或者加入下游工具拒絕接受的 UTF-8 BOM。經過驗證的檔案工作流程會將此轉換視為兩個獨立的決定：實際上產生該檔案的編碼為何，以及目的應用程式是否預期會有 BOM。UTF-8 轉換工具會強制做出這兩項決定：您可以明確選擇 UTF-8、UTF-16LE、UTF-16BE 或 Windows-1252 作為來源編碼，瀏覽器會以嚴格的錯誤處理機制進行解碼，使格式錯誤的位元組失敗而不是產生替代的菱形符號，而下載結果則是不含 BOM 的標準 UTF-8。檔案完全不會離開您的電腦，會在讀取前先檢查 10 MB 的限制，而預覽功能可讓您在儲存前檢查名稱、標點符號、貨幣符號和表情符號。請保留原始檔案，直到目的工具正確讀取轉換後的檔案為止。
為什麼 Notepad++ 的內建轉換功能可能會失敗
Notepad++ 不會自動偵測未知的編碼。當您開啟檔案時，編輯器會套用其目前的預設編碼或您上次選定的編碼，並呈現它所找到的位元組。如果該選擇錯誤，則每個重音字母、彎引號、歐元符號或 CJK 字元都會顯示為不同的字元或問號。「Encoding → Convert to UTF-8」指令只會以 UTF-8 規則重新編碼目前記憶體中的文字並寫入新檔案。它不會檢查位元組歷史記錄、不會驗證原始檔案，而且在某些版本中還會加入 BOM。一旦檔案被儲存，原始位元組就會消失。
常見的三種失敗模式。第一，來源錯誤：在編輯器仍將檔案解讀為 ANSI 時點選選單，可能只會將損毀的文字原封不動地來回轉換，並以 UTF-8 的形式寫出，保留了所有錯誤。第二，靜默替換：未經驗證的解碼會將無效的位元組替換為替代字元，因此產生的檔案看起來很乾淨，但已遺失資訊。第三，BOM 不符：許多命令列工具、編譯器和 JSON 解析器會拒絕含有 BOM 的 UTF-8，而某些 Windows 應用程式仍會預期它存在。如果您的目的工具對 BOM 敏感，錯誤的選擇會使其中斷，但不會出現明確的錯誤訊息。
對於來自 Windows 工具、Linux 伺服器、資料庫匯出或 Mac 應用程式的檔案，僅憑文字外觀幾乎無法判斷其來源編碼。兩個位元組流可能都能顯示為文字，但實際上代表不同的字元，因此自動猜測的結果可能看似合理，卻仍會損毀名稱、標點符號或符號。如果檔案已出現明顯的亂碼，修復 Notepad 中毀損 UTF-8 的指南會逐步說明如何先比對來源編碼。可稽核的轉換作業永遠從選擇實際產生該檔案的編碼開始，而不是讓編輯器自行決定。
來源編碼的選擇並非可有可無
編碼選擇是任何轉換作業之前最重要的步驟，而且無法安全地跳過。代表 Windows-1252 中歐元符號 €（單位元組 0x80）的相同位元組，在 ISO-8859-1 中則是控制字元；而代表某個名稱的同一個 UTF-16 位元組對，若以大端序解讀則會變成亂碼。只有產生該檔案的應用程式、檔案規格或可靠的元資料能告訴您哪個是正確的。
這就是為什麼此轉換工具拒絕猜測。它支援四種明確的來源編碼：UTF-8、UTF-16 little-endian、UTF-16 big-endian 和 Windows-1252。每種編碼都使用 WHATWG 定義的標籤和嚴格的錯誤處理機制進行解碼。無效的後續位元組、截斷的序列、未配對的代理對和禁止的字碼點都會被回報為失敗，而不是被靜默替換。UTF-16 模式會識別相符的 BOM 並在解碼過程中將其移除；輸出的 UTF-8 檔案由瀏覽器的 UTF-8 編碼器產生，不會加入 BOM。Windows-1252 模式使用標準定義的 Windows-1252 解碼器，因此 0x80 至 0x9F 的位元組會在重新編碼前變成可列印的標點符號和符號，例如 € 和彎引號。
如果您真的不知道來源編碼，請勿隨意猜測。請詢問產生該檔案的團隊、檢查匯出選項，或使用十六進位檢視器查看檔案開頭是否為 UTF-8 BOM（EF BB BF）、UTF-16LE BOM（FF FE）或 UTF-16BE BOM（FE FF）。位元組數量的變化是正常的：Windows-1252 的歐元符號位元組 80 會變成三個 UTF-8 位元組 E2 82 AC，而 CJK 字元通常會從兩個 UTF-16 位元組擴展為三個 UTF-8 位元組。不同的數量是可預期的，本身並不代表資料遺失。
如何從 Notepad++ 將檔案轉換為 UTF-8
- 從產生該檔案的應用程式、檔案規格或前幾個位元組的十六進位檢視結果中識別來源編碼。請勿依賴 Notepad++ 中文字的外觀。
- 在您用於下載的同一瀏覽器中開啟 UTF-8 轉換工具。
- 從選擇器中挑選相符的來源編碼：UTF-8、UTF-16LE、UTF-16BE 或 Windows-1252。
- 選擇來源檔案。瀏覽器會在讀取前根據 10 MB 的限制檢查檔案大小，因此意外過大的檔案會以明確的訊息被拒絕。
- 點選轉換。瀏覽器會以嚴格的驗證機制解碼位元組，並在預覽窗格中顯示產生的文字，以及來源和輸出的位元組計數。
- 檢查預覽中的名稱、標點符號、貨幣符號、智慧型引號和任何非 ASCII 行。如果任何內容看起來像替代的菱形符號、方塊或「é」之類的亂碼，請變更來源編碼並重新轉換。
- 下載 UTF-8 檔案。檔名會加上 -utf8 後綴，且位元組在輸出時不含 BOM。先前的物件 URL 會被撤銷，因此舊有結果的連結將無法使用。
- 在 Notepad++ 或目的應用程式中開啟下載的檔案，確認讀取正確後，再取代原始檔案。
如果檔案超過 10 MB，或您的工作流程已在建置管線中執行，請改用具備明確來源和目的編碼的可信任串流轉換工具。瀏覽器內的方法是為單一人員可驗證的檔案大小和審查循環所設計，並非用於 GB 等級的記錄檔。
適用於快速單檔轉換的 Notepad++ 選單步驟
對於您已知來源編碼的小型檔案，Notepad++ 的選單方式非常快速。開啟檔案，然後使用 Encoding → Character Sets → [正確的舊版編碼] → Convert to [編碼]。「Convert to」分支會重新編碼記憶體中的文字，並以該名稱寫入新檔案。「Encode in」分支只會變更編輯器解讀磁碟上位元組的方式。儲存後，請檢查 Notepad++ 的右下角：它會顯示目前的檔案編碼。
如果目標是不含 BOM，您需要在儲存前先將其停用。在 Settings → Preferences → New Document → Encoding 底下，取消勾選「Apply to opened ANSI files」，或將預設值設為「UTF-8 without BOM」。使用 Encoding → Save with Encoding → UTF-8（非 UTF-8 with BOM）儲存會輸出純粹的 UTF-8 位元組。使用 UTF-8 with BOM 儲存則會在檔案開頭輸出三個位元組 EF BB BF，這正是會讓 GCC、Python 的 csv 模組和許多 JSON 解析器發生問題的部分。
選單方式雖然方便但有其限制。它不會驗證來源、不會預覽轉換後的字元，也不會告訴您哪些位元組已變更。當選單轉換後名稱或符號看起來稍有異常時，請切換至轉換工具工作流程並明確選擇來源編碼。結果是可稽核的：您知道來源為何、解碼器做了什麼、編碼器產生了什麼。
在取代原始檔案之前測試結果
在轉換後的副本已通過每個將使用它的應用程式讀取之前，請勿覆寫來源檔案。轉換工具中的預覽能捕捉明顯的選擇錯誤，但它無法測試目的解析器的換行字元期望或 BOM 處理。請以新檔名儲存轉換後的檔案，在目標工具中開啟它，並確認名稱、標點符號和非 ASCII 字元都如預期般顯示。
對於 shell 管線和編譯器，請使用您手邊最嚴格的工具進行測試。具有拒絕重複鍵功能的 JSON 解析器、能顯示編碼錯誤的 CSV 讀取器，以及帶有 -Wall charset -warnings 的編譯器都是良好的最終檢查。如果有任何工具回報錯誤，請返回轉換工具，若預覽看起來錯誤則選擇不同的來源編碼，然後重新轉換。在目的應用程式驗證完成之前，磁碟上的原始檔案是唯一安全的回復來源。
| 步驟 | Notepad++ 選單轉換 | UTF-8 轉換工具（瀏覽器） |
|---|---|---|
| 來源編碼選擇 | 手動選單選擇，無驗證 | 明確選擇器，嚴格解碼 |
| 無效位元組處理 | 可能靜默替換 | 硬性失敗並顯示訊息 |
| 輸出中的 BOM | 除非在偏好設定中切換，否則會加入 BOM | 永遠不含 BOM |
| 下載前預覽 | 無 | 含位元組計數的解碼文字 |
| 檔案大小限制 | 編輯器記憶體限制 | 讀取前檢查 10 MB |
| 網路上傳 | 無（本機編輯器） | 無（瀏覽器本機） |
| 最適用於 | 編碼已知的較小檔案 | 可稽核的轉換與驗證 |
這兩種方法互補。Notepad++ 可在現有專案中處理快速編輯。轉換工具則處理您需要證明來源編碼正確且輸出確實為不含 BOM 的 UTF-8 的情況，根據 RFC 3629。