c在保存一篇新建的文檔時，如果沒有指定編碼類型，會使用缺省的ANSI類型（對于中文版來說，對應(yīng)的就是GB碼）。
而在打開一篇已創(chuàng)建的文檔時，它會分析文檔的編碼類型，它首先判斷文檔頭部有無BOM（Byte Order Mark，字節(jié)序標(biāo)記，長
度為(２-３字節(jié))，如有則根據(jù)其內(nèi)容判斷編碼類型，F(xiàn)F、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8)
因為事實上有很多非ANSI編碼的文檔是沒有任何BOM的“純文本”，所以對這些文檔不能簡單的判斷為ANSI編碼。
而需要使用一系列的統(tǒng)計學(xué)算法根據(jù)文檔內(nèi)容來猜測文檔編碼。記事本使用了 IsTextUnicode 函數(shù)來判斷是否為
Unicode/Unicode big endian 編碼，使用 IsTextUTF8 判斷是否為 UTF8 編碼。但既然是統(tǒng)計學(xué)算法，就難免存在誤判
，尤其在文檔內(nèi)容過短時，由于樣本的容量太小，這種誤判的概率會顯著增大。比如那個有名的微軟與聯(lián)通有仇的笑話，
就是記事本在打開只有"聯(lián)通"二字的ANSI編碼文檔時，IsTextUTF8 函數(shù)將其誤判為UTF8編碼[2]；同樣的誤判也發(fā)生在
IsTextUnicode 函數(shù)上，比如具有 “this app can break”這種具有4335結(jié)構(gòu)的文檔，會被誤判為 Unicode 編碼[3][4]。
需要說明的是，這種誤判的可能性是建立在文本較短且其字節(jié)位特征不被干擾的前提上的。如果將上述的文本做稍許修改（即使只是增加一個回車），則誤判很難再發(fā)生。
而這種方法的特殊性在于，它的字節(jié)串不但具有Unicode特征，而且很長達到了1288字節(jié)，也就是說它的Unicode特征性很強，所以可以抵抗一 些較短的不具有Unicode特征串的干擾，這是由統(tǒng)計學(xué)的規(guī)律所決定的。但是在干擾串稍長時，Unicode的特征將會受到顯著干擾，直至被 IsTextUnicode 函數(shù)認(rèn)定為非 Unicode。所以，有些朋友總是無法測試成功，應(yīng)該是與附加的批處理代碼長度和內(nèi)容相關(guān)。
因為其他的編輯器（比如 Word / Wordpad / EditPlus / UltraEdit）使用了更新的編碼類型判斷算法，所以在 Unicode 判斷上改進了不少，而 UTF8 的判斷仍然不盡如人意。但因為理論上來說完全準(zhǔn)確地算法并不存在，所以我們只能依靠避免使用無BOM的非ANSI文檔，或者打開文檔時手動指定編碼類型。
另外，如果使用記事本保存了這些誤判了編碼類型的文件，則將難以恢復(fù)。如果使用誤判編碼保存，則將給原文檔加上BOM標(biāo)記，則使用其他編輯器也再無法 觀察到原文檔。如果使用 ANSI 編碼保存，則原文檔將會被當(dāng)作 Unicode 文檔而被轉(zhuǎn)換，還原的可能性接近于零