1樓：
這就好比交通規則：紅燈停，綠燈行。
你說你有急事兒不想浪費時間，看到沒車輛經過就闖紅燈了，這沒問題，但你不能說等綠燈的人都是弱智！
Unicode標準中說BOM是可選的可加可不加，Windows出於相容性原因加了BOM，而Linux的做法呢：不支援加BOM的Unicode，只要加BOM就爆掉。
誰更弱智？不言而喻！
2樓：
說句公道話，我覺得記事本用帶BOM的UTF-8儲存文字檔案很聰明啊，因為BOM可以幫助記事本自動識別檔案的編碼，保證顯示的內容不是亂碼，對使用者是極其友好的。又不是所有windows的使用者都是程式設計師，再說記事本又不是不可以選擇儲存的編碼格式，你程式設計師被BOM坑了，那是你自己學藝不精，不了解編碼，怎麼還把責任怪到人家記事本的頭上呢。
3樓：喵激凌
記事本是按unicode的官方標準做法新增3個位元組的bom字首儲存文件的。目的是為了自動識別編碼，不是弱智行為。utf16同樣也會新增兩個位元組的字首。
專業點的文字工具，都可以自己設定是否新增bom，但是記事本，大家都懂的，只要求簡單，這些有的沒的的功能都省掉了。
4樓：
第一點 UTF-8 With BOM 是符合標準的。
第二點，對於微軟來說乙個是相容，另乙個是本地化，這些都是微軟要考慮的。
實際上在 Windows 系統上，中文環境中記事本預設編碼就是 GBK（CP936），如果 UTF-8 使用沒有 BOM 的編碼，就意味著需要去分析檔案中的內容來檢測編碼，否則就會和本地化編碼衝突，導致亂碼。記事本作為乙個簡單的，歷史悠久的工具自然沒有高階編碼檢測的功能。直接使用 UTF-8 With BOM，可以檢測檔案前三個位元組判斷檔案編碼判斷是否是 UTF-8，前兩個位元組判斷是否是 UTF-16，剩下的就是本地編碼了。
通過分析文字內容來判斷編碼有 Mozilla 的 universalchardet， 這個工具實際上使用了統計學做編碼識別，即判斷某些編碼中的高頻字，進行統計加權，計算權重，選擇最有可能的編碼，這就意味著檢測不一定準確。這個庫被 Notepad++ uchardet 等一系列開源工具使用。
IE 也有編碼檢測的 COM 介面： IMultiLanguage 但準確率不高。
記事本的歷史源遠流長，切記不要被一些錯誤的文章忽悠了因果關係。
5樓：胖胖小
notepad我記得也可以設定成不要bom頭啊，你要不喜歡存成不要bom的txt好了
話說，notepad確實功能不如notepad++，但有沒有bom不是換的理由
另外，題主這本什麼破部落格，一股山寨味
6樓：
bom頭這個問題我遇到過。
之前我在測試介面的時候，用記事本寫了乙個模擬資料，就是因為這個不可見的字元，讓我除錯了好久，怎麼調都報錯，最後才在chrome控制台裡發現了乙個小紅點。
從那以後，為了避免產生不可預期的問題，基本沒有用記事本開啟過檔案。
弱智倒也不見得，事物既然存在，基本都有其道理，但bom頭確實是我徹底放棄記事本的原因之一。
7樓：
不知道你們這些說BOM是標準的在扯什麼鬼Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature
結論，是弱智
8樓：
用過Windows XP之前的notepad嗎？只能開啟64K以內的txt檔案，那個才是真正的痛苦。
BTW， 微軟應該把vscode作為windows預設的文字編輯器得了，省得老是有人說notepad的事。
9樓：Louis Tong
麻煩先看看Unicode的官方文件是怎麼說的：UTF-8, UTF-16, UTF-32 & BOM。
Q: Is the UTF-8 encoding scheme the same irrespective of whether the underlying processor is little endian or big endian?
A: Yes. Since UTF-8 is interpreted as a sequence of bytes, there is no endian problem as there is for encoding forms that use 16-bit or 32-bit code units.
Where a BOM is used with UTF-8, it is only used as an encoding signature to distinguish UTF-8 from other encodings — it has nothing to do with byte order. [AF]
中文意思大致是：UTF-8的BOM不是用來標註大小端序（因為從程式設計角度看UTF-8本來就好比是個BYTE型的陣列，而不像UTF-16好比WORD、UTF-32好比DWORD那樣每個元素超過乙個位元組，所以不存在大小端序的問題），而是用來將它與其他編碼區分開來。
所以UTF-8加BOM是符合標準的。
連官方的文件看都不看就敢出來黑屁？
插科打諢，得得瑟瑟，東拉西扯，像個民科。
題主御焱問完問題就跑，別人來回答也不見他有半點回覆，難不成問完問題就斷網了？
題主絕對是在引戰釣魚，你們信不信？
10樓：Belleve
樓下不要亂扯，NT 開發的 1991 年哪來的 UTF-8？90 年代初但凡支援 Unicode 的軟體都是 16 位，也會很自然地引入 Endianness Mark。Unicode 1.
0 的時候，官方的 8 位表示形式只有 UTF-1，一種相容 ISO 2022 的變長編碼，你估計沒聽說過對吧。
後來為了使用者體驗、二進位制相容性（這條要求相當難但對使用者很重要，誰叫 PC 軟體是二進位制分發呢）的要求保留了 BOM 作為區分 UTF-8 和遺留編碼的方法。
11樓：秩序教長
我用python次次執行中文re都報錯
連我自定義字串測試都報錯
內容大概是非gbk不支援
可是我不知道在編譯器輸入的字元是什麼編碼啊於是我廢了老大勁去找了一套
猜編碼的東西，猜了半天也沒猜對
後來我直接把東西寫進記事本
然後儲存時的ansi改成gbk就能用了
直接讀記事本內容，全程無bug
由此可見
一般正常的open函式都會自動過濾掉前面的頭除非你是自己寫個流，還不寫過濾
那就不能怪記事本了
12樓：張公
那不是自作聰明，也不是亂碼，只是Unicode標準中規定的BOM而已。雖然事實上大家都不遵守這個標準，但是也不能說遵守了這個標準就是弱智的行為。Windows程式一般都能很好的處理這個BOM，主要是跨平台的時候才會發生衝突。
但是，憑什麼要求Windows去迎合其他平台的習慣呢？
另外，Win下面程式設計就別用記事本了吧，用IDE多好，幹嘛辛苦自己。
13樓：邸強
事實上微軟在遵守Unicode規範。如果遵守規範也是弱智的話，要麼制定規範的人弱智，要麼說這話的人弱智。我傾向於後者。
PS:有問題就解決問題，bom只不過是程式設計師入門的乙個很小的問題，說什麼弱智不弱智毫無意義。
windows的記事本有存在的價值麼？
特洛諾公尺 用記事本寫個命令，儲存退出改個bat字尾。然後把這個bat繫結到鍵盤自定義快捷鍵上，解決了我win10上一鍵休眠的需求。沒有比記事本更適合寫一行批處理指令碼的工具了。 某一天Steve在自己電腦上發現了乙個FlashHelperService.exe程序，彈窗插播各種廣告新聞訊息，於是乎...
win10記事本如何設定unicode編碼？
Windows 10版本1903更新後，記事本的幾種編碼模式改了名稱 舊版的 Unicode 相當於新版的 UTF 16 LE 這是題主找不到 Unicode 選項的原因 舊版的 Unicode big endian 相當於新版的 UTF 16 BE 舊版的 UTF 8 相當於新版的 帶有BOM的U...
照現在的發展趨勢，記事本將會逐漸被淘汰嗎？
竹由 不會。它有自己獨特的功能，是電子產品不能完全替代的 它具有專門性，因此更適合從事它的 本職工作 不像電子產品一樣功用雜糅 它有著超越電子產品的質感，它有著形而上的情懷與象徵性，它在使用時具有儀式性。反正當年留聲機 膠片機 收音機 磁帶機快要淘汰的時候，都有這麼說的。好吧，說句正經的，上述機器被...