檔案編碼轉換工具（UTF-8 帶BOM・Shift_JIS）
轉換CSV或文字檔的字元編碼。為UTF-8檔案加上BOM讓Excel正確開啟，或轉換為Shift_JIS。自動判斷原編碼，支援換行字元轉換，全部在瀏覽器內處理。
依用途推薦的設定
該存成哪種編碼取決於接收方。以下為參考。
| 需求 | 推薦設定 |
|---|---|
| 用Excel直接開啟UTF-8的CSV | UTF-8 ＋ 加上BOM（Excel可正確判斷編碼） |
| 匯入舊業務系統・會計軟體 | Shift_JIS ＋ CRLF（面向Windows的傳統組合） |
| 由程式（Python・PHP等）讀取 | UTF-8（無BOM）＋ LF（BOM會混入第一個欄位名） |
| 用Mac版Excel開啟 | UTF-8 ＋ 加上BOM |
| 匯入Google試算表 | UTF-8（BOM可有可無）（BOM會被自動忽略） |
| 準備舊郵件環境的內文 | JIS（ISO-2022-JP） |
各編碼的特點
本工具支援的編碼及注意事項。
| 編碼 | 特點 |
|---|---|
| UTF-8 | 目前的通用標準，可表示各國文字與表情符號。 |
| UTF-8（帶BOM） | 檔案開頭附加3位元組標記，使Excel不會誤判編碼。 |
| Shift_JIS | Windows日文環境長期使用的編碼，無法表示表情符號與部分異體字。 |
| EUC-JP | 主要用於UNIX系統的日文編碼，現在很少新採用。 |
| ISO-2022-JP（JIS） | 郵件中使用的編碼，無法表示半形片假名。 |
CSV 的亂碼為何會發生
以 Excel 開啟 CSV 時文字崩壞的原因，多半是檔案的字元編碼與 Excel 所假定的字元編碼不一致。Windows 版的 Excel 在 CSV 檔案沒有任何標記時，會假定其內容為當地既有的字元編碼（日文環境即 Shift_JIS）來讀取。然而近來的網路服務或程式所輸出的 CSV 多為 UTF-8，將 UTF-8 的位元組序列當作 Shift_JIS 解讀的結果，便會顯示出「譁�蟄怜喧縺�」這類崩壞的字串。
解決方式有兩種。一是將檔案轉換為 Shift_JIS，二是維持 UTF-8 並在檔案開頭加上 BOM（Byte Order Mark，3位元組的標記）。有 BOM 時 Excel 便能判斷「這是 UTF-8」，因此可在不改動內容的情況下避免亂碼。本工具支援兩種轉換，原始檔案的字元編碼會自動判定。處理全部在瀏覽器內進行，檔案不會送往伺服器。
字元編碼轉換的使用方法
- 選擇檔案 將 CSV 或文字檔拖放進來，或點擊選擇。讀入後會自動判定原本的字元編碼與換行字元。
- 以預覽確認判定結果 若預覽的文字能正確閱讀，即表示判定成功。若看起來崩壞，可能選到了文字檔以外的檔案。
- 選擇轉換目標 若要以 Excel 開啟，請選「UTF-8」＋「加上 BOM」；若要匯入舊的業務系統，請選「Shift_JIS」。
- 下載 按下「轉換並下載」，便會儲存為在原檔名加上字元編碼後綴（_utf8bom、_sjis 等）的檔案。
用好本工具的小技巧
- 若只是想用Excel開啟，UTF-8加上BOM最安全，內文字元完全保留。
- 轉換為Shift_JIS時無法表示的字元會變成「?」。本工具會先列出將要遺失的字元。
- 由程式讀取的檔案請勿加上BOM，否則BOM會成為第一個欄位名的一部分。
這些時候可以使用
從網路服務輸出的 CSV 在 Excel 中亂碼
以 UTF-8 輸出營收資料或會員名單的服務很多，直接以 Excel 開啟便會亂碼。只要加上 BOM 即可解決。
無法匯入會計軟體或薪資系統
舊的業務系統有時只接受 Shift_JIS 的 CSV。將 UTF-8 檔案轉換為 Shift_JIS 即可順利匯入。
以程式讀取帶 BOM 的 CSV 時首欄異常
BOM 是看不見的3個位元組，直接讀取時會混入第一個欄位名稱中。轉換為去除 BOM 的 UTF-8 即可解決。
換行字元（CRLF/LF）的差異導致被視為一行
在 Mac 上以 LF 建立的檔案，若以舊的 Windows 應用程式開啟，換行可能被忽略而整份看起來只有一行。轉換為 CRLF 後再交付即可解決。反之，在 Windows 建立的 CRLF 檔案通過 Unix 系指令時行尾會殘留 ^M，此時請轉換為 LF。
想確認亂碼檔案的內容
由於會自動判定字元編碼並正確重新讀取，即使原本開啟後無法閱讀的檔案，也能以預覽確認其內容。
與字元編碼相關的術語
- 字元編碼
- 將文字與電腦內部的位元組序列相互對應的規則。輸出時與讀取時的規則不同，便會發生亂碼。
- BOM
- Byte Order Mark 的縮寫，是置於檔案開頭的3個位元組（EF BB BF）標記。具有告知應用程式「這是 UTF-8」的作用，但以程式讀取時可能被視為多餘的字元。
- 換行字元
- 表示一行結束的位元組。Windows 使用 CRLF（2位元組），Mac 與 Linux 使用 LF（1位元組），因此跨環境時可能看起來只有一行，或多出額外的行。
- Shift_JIS
- 在 Windows 的日文環境中長期廣泛使用的字元編碼。收錄字數少於 UTF-8，無法表現表情符號與部分異體字。
- 亂碼（mojibake）
- 以與原本不同的字元編碼讀取後，排列出不具意義文字的狀態。「譁�蟄怜喧」這類排列是將 UTF-8 當作 Shift_JIS 讀取時的典型例子。
常見問題
閒話 ― 亂碼的形狀會告訴你原因
亂碼有可辨認的規律。出現一串互不相關的漢字，通常是把UTF-8的位元組當作Shift_JIS讀取所致——UTF-8中一個日文字元佔3位元組，按2位元組重新切分自然會得到完全不同的字。反之把Shift_JIS當作UTF-8讀取時，由於位元組序列本身無效，會出現一排替換字元。
BOM原本是為UTF-16標示位元組順序而設計的。UTF-8不存在位元組順序問題，因此Unicode標準並不推薦為UTF-8加上BOM。但在Windows生態中它依然廣泛使用，因為只能靠猜測判斷編碼的應用確實需要一個明確的標記。