在編輯編碼爲UTF-8 w/o [虛假] BOM的文件的過程中，內容可能會變成沒有ASCII或ANSI範圍之外的任何Unicode字符。在下次重新打開文件時，一些文本編輯器（Notepad ++）會將其解釋爲ASCII/ANSI編碼，並將其打開。如果不瞭解更改，用戶將繼續編輯，現在添加非ANSI Unicode字符，儘管這些字符已保存在ANSI中，但無用。可以存在一個菜單選項（Notepad ++）以ANSI文件打開爲UTF-8 w/o BOM，但導致相反的問題，即無意中使用Unicode編碼覆蓋ANSI文件。如何避免無意中將UTF-8文件編碼爲ASCII/ANSI？
一種解決方法是將ANSI範圍之外的字符添加到文件中的註釋中。根據解碼算法，它可能會強制編輯器（Notepad ++）將該文件識別爲編碼爲UTF-8 w/o BOM的文件。
在一個HTML文檔例如，你可以按照標題的字符集定義這樣一個統一意見，這裏的U + 05D0希伯來文字母ALEF： <元HTTP的當量=「Content-Type的」內容=「文本/ html; charset = utf-8「> <！ - א - >
你會如何建議編輯器告訴在沒有BOM時ASCII/ANSI和UTF-8之間的區別，相同？
如果您希望將UTF-8保證爲UTF-8，請添加BOM或強制文件包含UTF-8字符。
嗨，匿名。對不起，我沒有得到對我自己問題的答覆，上傳速度足以讓你及時看到。解決辦法就是你的建議。 – 2009-12-17 21:40:52
配置您的編輯器，如果可能的話，始終使用UTF-8，如果沒有的話，向編輯器的創建者投訴。不針對unicode的字符集是IMO，已被棄用，應該這樣對待。
無論如何，在UTF-8中只使用ASCII空格中的字符（7位字符）的文件幾乎是相同的，所以如果您必須以ASCII編碼傳送某些內容，則不要鍵入任何Unicode字符。
謝謝你的回答。我發現在這個問題上令人着迷的是，如果文件所攜帶的信息（文本）被修改（在非ASCII的Unicode範圍中的一個編輯字中使用，並且在另一個情況下僅在使用時），文件可以改變其物理狀態（編碼）由ASCII字符組成的字）。這有點像一支筆，會根據你寫的單詞突然改變它的顏色。 – 2009-12-18 06:48:20
你爲什麼說BOM是「虛假的」？ – ChrisW 2009-12-17 21:06:21
「對於UTF-8，編碼方案僅由UTF-8編碼單元（=字節）組成，因此UTF-8不存在大數據與小數據字節順序的問題。對於16位和32位編碼形式，字節串行化必須分別將代碼單元分解爲兩個或四個字節，並且這些字節的順序必須明確定義。「 （Unicode Book，第36頁，http://www.unicode.org/versions/Unicode5.0.0/ch02.pdf） 向UTF-8（UTF-8中的MS記事本）添加BOM是一種破解，它允許UTF-8內容的區別。 – 2009-12-17 21:29:50
因爲它區分UTF-8，也許它是真實有用的（不是虛假的）。 – ChrisW 2009-12-17 22:22:25