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