我在記事本中編輯了以下批次檔。記事本右下角顯示“UTF8”。我將文件儲存為 ANSI 格式。
現在，記事本右下角顯示「ANSI」。我關閉了文件並重新打開它。記事本右下角顯示“UTF8”。我已經多次重複上述過程，每次都得到相同的結果。
它是 ANSI 檔案還是 UTF8 檔案？
或者記事本右下角顯示的內容可能沒有任何意義？
這是在 Windows 11 Pro 23H2 上建置的 22631.3296 Windows 功能體驗套件 1000.22687.1000.0。 Windows 記事本 11.2401.26.0
[對不起！忘記添加檔案】
date /t >C:\health.txt
time /t >>c:\health.txt
sfc /scannow >>c:\health.txt
time /t >>c:\health.txt
sfc /scannow >>c:\health.txt
time /t >>c:\health.txt
答案1
它是 ANSI 檔案還是 UTF8 檔案？
兩個都
如果它只包含 ASCII 字符，那麼它既是 ANSI 又是 UTF-8。
它也是大多數其他字符集和編碼。這是因為大多數編碼都包含使用 ASCII 代碼點（數字值）的 ASCII 集。
例外的是字元編碼，例如 IBM 的 EBCDIC - 這曾經很常見。
順便說一句，微軟歷史上使用術語 ANSI 來指稱他們期望美國國家標準協會 (ANSI) 作為其眾多標準之一發布的字元集。 ANSI 沒有這樣做。更準確或更有用的名稱是代碼頁 1252。說您用 ANSI 編寫文件有點像說您用 Pantone 或 RAL 顏色粉刷廚房。
Microsoft 應用程式通常使用位元組順序標記 (BOM) 編寫 UTF-8 文件，以協助其應用程式識別各種 Unicode 編碼，例如 UTF-16LE、UTF-16BE 和 UTF-8。請注意，UTF-8 檔案中的 BOM 僅用於識別檔案內容編碼，它不能指示位元組順序，因為這不適用於 UTF-8。文字檔案中包含 BOM 可能會導致問題，例如，由於 BOM 取代了腳本可執行簽名，因此導致 Linux shell 腳本無法運作#!。
Microsoft 應用程式使用函式庫函數來猜測來自文件內容的文件編碼。這是出了名的不可靠，儘管它隨著時間的推移而有所改善。
有關的
答案2
我懷疑這並不重要。僅包含英文文本的文件通常是 ASCII，然後（未標記的）UTF-8 和 ASCII/ANSI 之間沒有區別。
如果要強製檔案為UTF-8，則需要將其儲存為帶有BOM的UTF-8。如果沒有 BOM（“字節順序標記”，文件開頭的特殊標記），編輯器必須猜測，並且當文件中沒有特殊字符時（例如非英語變音符號，如 ä、ö或ê) 這並不重要，因為所有常用字元表的前128 個字母都是相等的。
答案3
這個記事本顯示的 UTF-8 是假的。我以 ANSI 和 UTF-8 格式儲存了一個文字文件，這兩個文件完全相同。
看來記事本的UTF-8實現嚴重缺乏一致性。以UTF-8格式儲存應該添加了一個 位元組順序標記 (BOM) 到文件的開頭，但它不這樣做。
為了正確處理 ANSI 和 UTF-8（有或沒有 BOM）之間的差異，您需要一個更先進的文字編輯器，例如 記事本++。