Outlook 對外寄出的郵件使用在「檔案 → 選項 → 進階 → 國際選項」中選擇的字元編碼；對於重音字母、貨幣符號和 CJK 字元，若要正確往返轉換，該選項必須設定為 Unicode (UTF-8)。單獨設定郵件用戶端並不總是足夠：簽名檔 .htm 檔、通訊錄 .csv 匯出檔，以及儲存在磁碟上的範本檔都必須是有效的 UTF-8 位元組，因為 Outlook 會根據檔案內部聲明或從檔案位元組推斷的編碼，將這些檔案當作文字讀取。當檔案實際上是 Windows-1252 或 UTF-16，但卻被標示為 UTF-8 時，Outlook 會在應出現的字元位置上，顯示替換用的菱形、混亂的重音，以及看似 CJK 的方塊。當轉寄的 .msg 檔案使用舊式字碼頁儲存時，也會出現同樣的問題。可靠的解決方法是讓 Outlook 本身以 UTF-8 寄件，並確保你餵給 Outlook 的每個檔案都是真正的、不含 BOM 的 UTF-8 —— 而工作流程中關於檔案那一端，正是 UTF-8 轉換器設計要處理的部分。
為何 Outlook 會顯示亂碼字元
Outlook 將收發的郵件視為一個位元組串流，以及一個標示這些位元組遵循何種編碼的標籤。當標籤與位元組不一致時，在純 ASCII（A–Z、0–9、基本標點）中看起來相同的字元能夠在這種錯誤配對中存活下來，而所有使用 127 以上位元組值的內容 —— 重音、歐元符號、彎引號、表情符號、CJK 表意字元 —— 則會被重新對應到錯誤編碼對那些位元組的解讀上。結果就是經典的亂碼模式：José 變成 José、€ 變成 ⬬，而 你好 可能會顯示為 ä½ å¥½。
在 Outlook 中有兩種情況會造成這個問題。第一種是郵件用戶端本身的編碼選擇。如果 Outlook 設定為西方字碼頁（例如 Windows-1252），而你撰寫了一封包含非 ASCII 字元的郵件，Outlook 就會使用該字碼頁（而非 UTF-8）來編碼那些字元。在預期使用 UTF-8 的系統上，即使你的寄件備份看起來正常，收件者也會看到損壞。第二種情況是 Outlook 匯入檔案時 —— 無論是簽名檔、通訊錄 .csv 檔或信紙範本 —— 而該檔案本身的編碼與 Outlook 的假設不同。Outlook 無法修正檔案的位元組；它只能選擇套用哪一個解碼器，選錯了就會把名字與符號弄得一團亂。
在 Outlook 中將外寄郵件編碼設定為 UTF-8
若要讓 Unicode 字元在 Outlook 中正確往返轉換，外寄郵件編碼器必須設定為 Unicode (UTF-8)。該選項的位置在多個版本中曾經更動，但選項本身並未改變。在 Windows 桌面版 Outlook 中，路徑如下：
- 開啟檔案 → 選項。
- 選擇進階索引標籤。（在 Outlook 2007 中，對應的控制項位於郵件格式索引標籤。）
- 捲動至國際選項並點選它。
- 開啟外寄郵件的慣用編碼下拉式選單。
- 選擇Unicode (UTF-8)並點選確定。
重新啟動 Outlook，讓新編碼對已排隊的草稿生效。同一個面板也提供一個內送郵件的慣用編碼下拉式選單；將它設定為 Unicode (UTF-8) 可協助 Outlook 在內送郵件省略明確字元集時，選擇 UTF-8 解碼器，這在企業轉送伺服器中很常見。Microsoft 記載了 Outlook 網頁版的對應路徑（設定 → 郵件 → 撰寫與回覆），其新郵件在設計上即以 UTF-8 編碼，使用者無須選擇字碼頁。
當檔案本身需要是 UTF-8 時
將 Outlook 的外寄郵件編碼器設定為 UTF-8，僅涵蓋你撰寫並寄出的郵件。它並不涵蓋你載入 Outlook 的檔案，而這些檔案正是最常造成明顯亂碼的來源：
- 簽名檔 —— 將 rich-text 的 .htm 簽名檔以及純文字的 .txt 簽名檔都從磁碟讀取，因此若 Outlook 要正確呈現簽名內的彎引號、重音或 CJK 姓名，其位元組必須是真正的 UTF-8。
- 通訊錄 .csv 匯出檔 —— Outlook 可以匯入那些由匯出程式以 Windows-1252 或 UTF-16 儲存位元組的 .csv 檔；當這些位元組被當作 UTF-8 解讀時，含有重音、亞洲字元或符號的姓名會在匯入步驟就損壞。
- 信紙範本 —— 自訂的 .htm 信紙由 Outlook 作為文字載入，並以檔案所聲明的編碼呈現。
- Quick Parts 與 AutoText 的 .htt 檔 —— Outlook 從磁碟讀取這些檔案，並套用與信紙相同的文字解碼規則。
對上述每一種情況，正確的作法是在 Outlook 開啟前，先將磁碟上的檔案轉換為真正的 UTF-8 位元組，而不是告訴 Outlook 重新解讀錯誤的位元組。
將檔案轉換為 UTF-8 以供 Outlook 使用
使用 UTF-8 轉換器將簽名檔、通訊錄匯出檔或信紙範本轉為不含 BOM 且經過驗證的 UTF-8 檔案。轉換完全在瀏覽器中進行；來源位元組不會被上傳。
- 確認檔案實際的來源編碼。查看產生該檔案的應用程式，或任何可靠的詮釋資料 —— 從較舊的 Windows 工具匯出的 .csv 幾乎一定是 Windows-1252；以 Notepad 的「Unicode」選項儲存的檔案是 UTF-16LE；以「UTF-8 with BOM」儲存的檔案是 UTF-8。不要從字元的外觀去猜測，因為相同的位元組序列在不同的舊編碼下可能代表不同的內容。
- 開啟 UTF-8 轉換器並選擇相符的來源編碼。轉換器支援 UTF-8（含驗證）、UTF-16 little-endian、UTF-16 big-endian 以及 Windows-1252。
- 從磁碟選擇檔案。接受最大 10 MB 的檔案；超過的會在讀取前遭到拒絕，因此瀏覽器絕不會意外載入數 GB 級的記錄檔。
- 轉換並檢視預覽結果。閱讀解碼出的內容，檢查姓名、標點、貨幣符號以及任何重要的非 ASCII 行列。若來源模式為 UTF-8 且檔案中含有無效的後續位元組、截斷的序列或禁止的編碼，轉換會以明確錯誤失敗，而不是靜默地輸出替換字元。
- 下載結果。下載的檔案使用原始檔名加上 -utf8 後綴，並採用純文字的 UTF-8 媒體類型。不會加入 BOM；辨識到的來源 BOM 會被符合標準的解碼器消化掉。
- 在 Outlook 中測試該檔案。在刪除原始檔案之前，先將 Outlook 指向新的簽名檔，或匯入轉換後的 .csv。轉換器的工作識別可防止較慢的舊檔案讀取取代較新的選擇；一旦你變更選擇，過時的物件 URL 會被撤銷。
轉換器無法替你偵測編碼，因此若來源編碼確實未知，上述工作流程必須從在產生該檔案的應用程式或任何已儲存的詮釋資料中找出答案開始 —— 否則轉換只是對位元組進行任意的重新標示。
轉換器可處理的來源編碼
轉換器中的每個模式都有其特定用途。下表概述每個模式的目的，以及它傾向於解決哪些 Outlook 問題。
| 來源模式 | 典型的 Outlook 情境 | 關鍵行為 |
|---|---|---|
| UTF-8 | 從現代編輯器、網頁匯出檔或另一個 UTF-8 Outlook 簽名儲存的檔案。 | 以致命錯誤處理進行驗證，使格式錯誤的序列失敗，而不是被靜默替換。檔首的 UTF-8 BOM 會被消化掉。 |
| UTF-16 little-endian (UTF-16LE) | 由 Notepad 的「Unicode」選項及許多 Windows 匯出工具儲存的檔案。 | 以低位元組優先解碼；會辨識並移除相符的 BOM。 |
| UTF-16 big-endian (UTF-16BE) | 從某些 Unix、大型主機或較舊的 Mac 工具匯出的檔案。 | 以高位元組優先解碼；若選成 LE 而非 BE，字母會變得毫無意義，雖然位元組仍可讀。 |
| Windows-1252 | 舊式的西方 .csv 匯出檔，以及從較舊的 Word 文件複製出來的 .htm 簽名檔。 | 瀏覽器中依標準定義的 Windows-1252 解碼器，為 80–9F 的位元組提供可列印的標點與符號對應，包括歐元符號與彎引號。 |
Outlook 桌面版與 Outlook 網頁版的編碼控制項
兩個 Outlook 用戶端暴露編碼設定的方式截然不同，而轉換器只在桌面端才有作用。下表說明每個控制項實際位於何處。
| 面向 | Outlook 桌面版 (Windows) | Outlook 網頁版 |
|---|---|---|
| 外寄郵件編碼 | 使用者可選擇；在國際選項中設定為 Unicode (UTF-8)。 | 郵件內文一律為 UTF-8；使用者無法控制。 |
| 內送郵件解碼覆寫 | 針對編碼模糊的郵件提供使用者可選擇的下拉式選單。 | 由寄件者所聲明的字元集決定。 |
| 簽名檔編碼 | 從磁碟讀取；若使用非 ASCII 字元，必須是真正的 UTF-8。 | 不適用 —— 簽名檔是在「設定」中設定。 |
| 通訊錄 .csv 匯入編碼 | 從所聲明的字元集推斷；UTF-8 匯入檔可正確呈現。 | 不適用 —— 通訊錄是透過「人員」進行管理。 |
Testing the Converted File in Outlook
After downloading the converted file, point Outlook at it before deleting the original. For a signature, open File → Options → Mail → Signatures, click New, browse to the new file, and confirm the preview pane shows every accented name, every curly quote, and every symbol you care about. For a .csv import, use File → Open & Export → Import/Export → Import from another program or file → Comma-Separated Values, choose the converted file, and map each column. Spot-check imported names and notes rather than trusting the import to finish without warnings.
Watch the source and output byte counts the converter reports. Different encodings use different byte lengths for the same characters, so a correct UTF-8 conversion very often changes file size — the Windows-1252 euro byte 80, for example, becomes the three UTF-8 bytes E2 82 AC. A different count is expected and does not by itself indicate data loss; what matters is whether the preview's characters match what the file is supposed to contain.
Retain the original file until the complete workflow is verified. If the converter's preview looked fine but Outlook still shows corruption, the source encoding was probably identified incorrectly the first time; re-export from the producing application with a known encoding label or metadata, then run the converter again with that mode. Files containing a mix of encodings inside one document cannot be repaired reliably by a single decoder — split the file by source first if that situation applies.
If the file you are feeding into Outlook is a plain text snippet whose source encoding is already UTF-8 but the file has become corrupted, the change UTF-8 in Notepad when the file looks broken workflow walks through the same validation approach from the editor side.
For a deeper look, see UTF-8 Browser Tools: Privacy and Round-Trip Verification.