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