同一 TXT 文件記事本亂碼、寫字板正常？字符編碼與渲染引擎的深度解析

現象描述

同一個 .txt 文件，用「記事本」打開顯示亂碼/錯誤，用「寫字板」打開卻正常。字體設置相同，為何渲染結果截然不同？

核心真相：編碼檢測機制差異

為什麼「字體設置一樣」卻結果不同？

記事本的「字體設置」僅影響顯示用什麼字體畫字形，不影響編碼解碼。若文件實際為 UTF-8 無 BOM，記事本按 ANSI (CP936) 解碼 → 字節序列被誤解析 → 顯示錯誤字符 → 再用設置字體渲染錯誤字符。寫字板正確識別為 UTF-8 → 解碼正確 → 字體渲染正確。

如何確認文件真實編碼？

1. Notepad++：右下角顯示編碼，菜單「編碼」可轉換。
2. VS Code：右下角編碼標籤，支持「重新用編碼打開/保存」。
3. 命令行：file -i filename.txt (Linux/Mac) 或 chcp 65001 && type filename.txt (Win 終端)。

根治方案：統一編碼規範

最佳實踐：UTF-8 with BOM

• Windows 記事本 (Win 10 1903+) 默認保存為 UTF-8 無 BOM，但讀取時優先識別 BOM。
• 建議：保存時強制添加 BOM（Notepad++:「編碼」→「UTF-8-BOM」；VS Code: 設置 files.encoding: "utf8bom"）。
• BOM (EF BB BF) 讓所有編輯器「零歧義」識別為 UTF-8。

編程中讀寫規範

// C/C++ 寫入帶 BOM 的 UTF-8
FILE* fp = fopen("data.txt", "wb");
fwrite("\xEF\xBB\xBF", 1, 3, fp); // 寫入 BOM
fwrite(utf8_str, 1, len, fp);
fclose(fp);

// Python 3 讀取自動處理 BOM
with open('data.txt', 'r', encoding='utf-8-sig') as f: // -sig 自動剝離 BOM
    content = f.read()

總結

「記事本亂碼、寫字板正常」本質是編碼檢測能力差異導致的解碼錯誤，非字體問題。強制使用 UTF-8 with BOM 存儲、編程顯式指定編碼，可從源頭消除跨編輯器顯示不一致。