CSV 用 Excel 開啟為什麼出錯?UTF-8、引號、換行與前導零
DDEVELOPER
開發發布: 8 分鐘閱讀

CSV 用 Excel 開啟為什麼出錯?UTF-8、引號、換行與前導零

CSV 開啟後出現亂碼、同一欄位被拆成多筆紀錄,或編號的前導零消失,可能來自不同原因。字元編碼、CSV 語法和試算表的型別推斷,需要分開處理。本文依 RFC 4180 與 Microsoft 文件,整理如何保存原值並驗證匯入結果。

日文原文發布: 2026-04-22

RFC 4180 描述的是共通格式

RFC 4180 是 Informational(資訊性)文件,描述常見 CSV 格式與 text/csv 媒體型別,不是 Internet Standard,也不是所有 CSV 實作都必須遵守的唯一規格。其結構可簡述如下:

file = [header CRLF] record *(CRLF record) [CRLF]
header = name *(COMMA name)
name = field
record = field *(COMMA field)
field = escaped / non-escaped

文件以逗號分隔欄位、CRLF 分隔紀錄,最後一筆可省略結尾換行。雙引號包住的欄位可含逗號及換行;欄位內的雙引號用兩個雙引號表示。

MIME 的 charset 參數是選用的,也可指定 US-ASCII 以外的字元集。副檔名 .csv 無法決定編碼;本機檔案若沒有 MIME 宣告,應由交換流程補足編碼約定。

問題一:UTF-8 與 BOM 造成的亂碼

Microsoft 說明指出,帶有 BOM 的 UTF-8 CSV 可用一般開檔方式在 Excel 開啟。不含 BOM 時,可透過「資料」中的「取得資料」或「從文字/CSV」等入口,明確選擇 UTF-8。名稱與操作方式依版本、平台而異。

直接開啟與明確匯入使用的推斷可能不同;不能說沒有 BOM 就一定被當成 Big5 或 Shift_JIS。以下 Python 3 範例輸出 UTF-8 BOM 與 CRLF:

import csv
with open("users.csv", "w", encoding="utf-8-sig", newline="") as f:
    writer = csv.writer(f, lineterminator="\r\n")
    writer.writerows([["name", "id"], ["Renée", "0123"]])

BOM 是編碼線索,不會將 id 欄宣告成文字,也不會保護 0123 的前導零。若接收系統不需要 BOM,可將 encoding 改為 "utf-8"。保留原始檔,綜合傳送端宣告、BOM、明確設定及實際內容判斷,不要在不確定時直接覆寫。

問題二:欄位內也可能有換行

流通中的檔案可能使用 CRLF、LF 或舊式 CR。應先約定紀錄分隔方式,而不是只看作業系統;若連引號內的換行一起取代,會改變欄位內容。

id,姓名,備註
1,小林,"請參閱
下一行"
2,小陳,無備註

這段看起來有四行,實際是三筆 CSV 紀錄:標題列加兩筆資料。只用 split("\n") 會切斷含換行的欄位;逐行再用逗號切割也不是完整解析器。請使用理解約定分隔符號與引號規則的 CSV 解析器。

問題三:雙引號如何跳脫?

欄位含有逗號、雙引號或換行時,必須正確套用引號規則。例如原值包含逗號與被引號包住的 CSV:

"已參加, 詢問了 ""CSV"""

外層雙引號包住整個欄位,內部連續兩個雙引號還原為一個。反斜線加引號不是 RFC 4180 的跳脫規則,單引號也不能取代雙引號作為欄位定界符號。全形標點與 ASCII 逗號是不同字元。

輸出時可選擇所有欄位都加雙引號,但這不會宣告儲存格型別,也不保證阻止公式解讀。語法跳脫與 CSV 公式注入防護必須分開處理。

問題四:前導零、長編號與日期被轉換

表格若超出畫面寬度,可左右捲動。

原值可能的解讀風險
0123數值 123編號前導零消失
3E2數值 300文字表示被改變
3/4日期月日順序與假定年份依設定而異
12345678901234567數值超過 Excel 的 15 位有效數字精度,可能遺失尾端數字

這些是可能結果,不是每個環境的固定結果。匯入識別碼或像日期的代碼時,應先將欄設為文字(Text)。若 Power Query 已套用型別轉換,檢查該步驟並視需要從原檔重新匯入。事後改顯示格式,無法找回已遺失的數字。

前置 Tab 會改變資料。="0123" 是公式,不是文字型別宣告;把不可信輸入包進公式,不是通用解法。改用 xlsx 時,也要明確建立文字儲存格,不能只換副檔名。

地區設定與匯入入口都要確認

Excel 可能依 Windows 地區設定等條件使用分號作為清單分隔符號。小數符號與欄位分隔符號不是同一件事;先確認接收程式究竟按逗號還是其他符號讀取。

不要以一張表斷言 Excel、Google 試算表或 LibreOffice Calc 一律符合 RFC。請依實際版本、平台與匯入入口,測試編碼、引號、換行、分隔符號及型別推斷。用副本和少量已知資料比對匯入及再次匯出的結果。

什麼時候改用其他格式?

  • TSV:以 Tab 分隔,欄位內的 Tab 與換行仍需約定處理方式。
  • JSON/JSON Lines:可表達字串、數字、布林值、null、陣列與物件,大整數與日期仍需共同約定。
  • xlsx:支援明確的儲存格型別、公式與多張工作表。
  • Parquet:適合分析工作流程的欄式二進位格式。
  • SQLite:可透過 SQL 查詢的資料庫檔案。

依接收端支援、型別保存、資料量與編輯需求選擇。換格式不會自動讓資料交換安全或無損。

匯出與匯入檢查清單

  • 約定編碼與 BOM;重視 Excel 直接開啟時,可考慮 UTF-8 加 BOM。
  • 交換 RFC 4180 所描述的格式時,以 CRLF 分隔紀錄。
  • 一致處理引號,測試逗號、雙引號與欄位內換行。
  • 需要保留的編號、長代碼與類似日期的字串,匯入時指定為文字。
  • 公式處理與一般 CSV 跳脫分開評估。
  • 保留原檔,在覆寫之前比對匯入值與再次匯出的內容。

二進位編輯器可用來檢查 EF BB BF 或 CRLF 等位元組,但不能取代 CSV 解析器與試算表型別設定。

重點整理

  • 將編碼、CSV 語法與型別推斷分開診斷。
  • RFC 4180 描述常見格式,不決定每個接收程式的行為。
  • BOM 可協助 Excel 辨識 UTF-8,不能保護前導零或長編號。
  • 明確匯入為文字並保存原檔,才能核對自動轉換前後的差異。

參考資料與來源

編輯說明

本文使用 AI 協助編輯,並於發布前由編輯確認。內容仍可能包含事實、解讀或時效上的錯誤;進行重要判斷前,請查閱所列的一手資料或官方文件。

相關工具

相關文章