編碼與字元集

指定字元編碼重新讀取亂碼 CSV

使用工具

.csv 副檔名不能決定字元編碼。產生與開啟應用採用不同編碼時，相同位元組會顯示成不同文字。直接儲存亂碼可能覆蓋證據，應先保留原檔案。

字元編碼工具按明確選擇的編碼把文字轉位元組或反向轉換，不會自動鑑定原編碼。先用あ一字理解機制，再套用於實際檔案。

あ在各編碼下的十六進位

UTF-8       e38182
UTF-16LE    4230
UTF-16BE    3042
Windows-31J 82a0

輸入あ並切換編碼可得到這四種結果。字元未變，位元組值與長度不同。十六進位表示儲存傳輸位元組，不是變成了不可讀字元。複製時應附編碼。

e38182 按 UTF-8、82a0 按 Windows-31J 解碼可還原あ。UTF-16 的位元組順序也是規則的一部分，4230 在 LE 與 BE 中意義不同，不能互換。

往返成功只確認該例，不唯一證明整個檔案的原編碼。純 ASCII 可能在多種編碼下都正常。還應檢查代表性非 ASCII、符號、換行，並結合產生方匯出設定或規格。

不合法位元組會報錯，不會默默替成替代字元。例如 e381 是 e38182 的截斷 UTF-8。錯誤可能來自選錯編碼，也可能是輸入缺位元組，兩種都要查。

沒有錯誤也不證明讀法正確，另一編碼也可能接受這些位元組。需核對預期詞語、符號、紀錄數和產生方宣告，重點是保留預期內容，不是只要能顯示。

若只是顯示時誤解碼，原位元組可能還能按正確方式重讀。但儲存替代 ? 或 � 後，不同原字可能已變成同一替代符號，僅憑儲存文字無法唯一還原。

此時應找原匯出或備份，而非反覆轉換損壞文字。複製亂碼顯示不同於提供原位元組。求助時說明證據類型，用副本操作，不覆蓋來源。

目前支援 UTF-8、UTF-16LE、UTF-16BE 和 WHATWG shift_jis 對應的 Windows-31J 對映，不表示與舊 JIS 或所有同名產品實作完全一致。應在接收應用測試實際出問題的符號或擴充字。

Windows-31J 無法表示的字元如 😀 會編碼失敗，不默默替成 ?。接收方只能用該編碼時，需要約定字元規則、修改介面或明確替代表示，這些涉及語意，不應由工具暗自決定。

文字還原後，再用 CSV 編輯器檢查列欄。分隔符號、引號內換行、前導零與空字串是另一些問題。試算表即使修好顯示，也可能把 ID 轉數字，應核對代表性紀錄。

為防復發，應在交換規格寫明編碼、BOM、換行與 CSV 分隔符號。工具編碼結果是十六進位文字，儲存畫面內容不自動成為可匯入業務檔案。最終檔案形式和匯入步驟需按接收方要求核對。

CSV 亂碼時，先保留未經試算表軟體另存的原始位元組。錯誤解碼後儲存可能將字元換成問號或刪前導零，問題就不只編碼。每種候選都從同一原本測試，不要反覆覆蓋；分清換解碼方式重讀與用其他編碼儲存，才能追蹤資訊在哪步變化。

純英數字一行顯示正確並非強證據，因為多種編碼對這些位元組相同。應檢查檔案實際包含的非 ASCII 文字與符號，但幾字可讀也不證明整份正確。有匯出設定或提供方規格時優先確認，推測的編碼應註明推測。

可讀之後還要查列欄數、引號內換行和空欄位含義。解碼成功不保證 CSV 資料相同，應一起交代編碼、分隔符、換行和欄位型別。本工具某些操作輸出十六進位位元組文字，不能直接把那段文字當業務 CSV 儲存。