關于軟件對字符編碼方式誤判的研究

王玉++張永勝

摘 要：針對目前字符編碼方式眾多的現狀，應用軟件如何更好的判斷文件編碼屬于何種字符集，并將其正確的解碼成為不容忽視的問題。針對Windows記事本不能正常顯示“聯通”二字的Bug進行分析，利用Winhex軟件解析文件獲得16進制編碼，根據得到的編碼分析誤判原因，通過注釋記事本IsTextUTF8函數對分析得到的誤判原因進行證實，進一步找到了更多Windows記事本無法正常顯示的漢字。

關鍵詞：編碼方式；字符集；UTF-8；記事本；誤判

中圖分類號：TP391.1 文獻標識碼：A

1 引言（Introduction）

在Windows操作系統環境下，新建一個記事本文檔，輸入“聯通”二字，保存并退出，再次打開該文件時，會發現“聯通”二字顯示為亂碼。該現象普遍存在于中文WIN2000、2000 Pro、2000Server、XP、WIN7、WIN8、WIN8.1等系統中，這是Windows記事本自身存在的一個Bug，至今仍未解決。到底是什么原因導致了該現象的存在呢？

這是計算機編碼方式問題導致的。Windows記事本保存文件有4種編碼類型，分別為ANSI、Unicode、Unicode big endian、UTF-8，默認保存編碼類型為ANSI。輸入“聯通”二字后，記事本通過ANSI編碼方式對其進行存儲，再次打開該文件時，記事本錯誤的判斷該文件是由UTF-8進行編碼的，便通過對應的解碼方式進行解碼（Decoding）。由于ANSI和UTF-8編碼方式和所屬字符集的差異，最終呈現出人們看到的亂碼。本文針對該問題進行研究。

2 各種編碼方式特點及其發展（Characteristics and

development of various encoding）

2.1 關于ASCII碼與擴展字符集

ASCII碼是在1947年由美國國家標準學會（American National Standard Institute，ANSI）制定的美國標準信息交換代碼（American Standard Code for Information Interchange，ASCII），使用7個二進制位（占一個字節，首位補0），共128種組合表示所有大小寫字母[1]。包括數字0到9，標點符號以及在美式英語中使用的特殊控制符號，屬單字節字符編碼系統。

ASCII碼無法表示一些歐洲國家的常用字符，如英鎊符號（￡）。因此，1981年在標準ASCII碼的基礎上，使用沒有用到的最高碼位，共8個二進制位，擴展了128到255（0x80-0xff）共128種狀態的字符，稱為擴展字符集。

2.2 關于GB2312、GBK、GB18030編碼

標準ASCII碼和擴展字符集仍然不能滿足世界各地的需要，所以不同國家制定了自己特有的字符集。如中國，以ASCII碼為基礎制定了GB2312編碼集。GB2312規定小于127的沿用ASCII碼，當兩個大于127的字符連在一起時表示一個漢字，這樣組合出6763個簡體漢字、682個符號[2]。同時將數字、標點、字母都重新編排了占兩個字節的編碼，這就是半角全角的問題。1995年又以GB2312為基礎擴展制定了GBK標準。GBK沿用GB2312的標準，但要求連在一起的兩個字符只要第一個大于127就表示一個漢字。為了方便少數民族，后又制定了GB18030編碼。

從ASCII、GB2312到GBK再到GB18030，都是向下兼用的，即同一個字符在這些方案中總有相同的編碼，后來的標準支持更多的字符，從ANSI派生出的字符集都稱為ANSI字符集。

2.3 關于Unicode編碼

世界各地不同語言都制定了自己的字符集，種類繁多，國際交流中需要轉換字符集極其不便[3]。因此，國際標準化組織（International Organization for Standardization，ISO）開展了ISO/IEC 10646項目，全稱“Universal Multiple-Octet Coded Character Set”，簡稱UCS（雙字節稱為UCS-2，四字節稱為UCS-4），俗稱Unicode字符集。Unicode字符集使用16bits表示一個字符，0—127的ASCII碼也擴展為兩個字節，用0-0x10FFFF來映射這些字符，可表示65536個字符，幾乎將世界上所有語言的常用字符收錄其中。標準的Unicode編碼稱為UTF-16，為了能使雙字節的Unicode在單字節處理的系統上正確傳輸，便使用類似MBCS的方式對Unicode進行編碼，利用保留字符制定了三套編碼方式，分別為UTF-8、UTF-16、UTF-32。

2.4 關于UTF-8編碼

UTF-8是用1到4個字節編碼Unicode的可變長度字符編碼，又稱萬國碼。UTF-8用一個字節來表示字母和一些鍵盤上的符號，當用多字節表示時UTF-8設定了標志位。

當要表示的內容是7位的時候就用一個字節存儲，形如0xxxxxxx。首位0為標志位，剩下碼位正好可以表示ASCII碼0—127的內容。當要表示的內容在8到11位的時候就用兩個字節存儲，形如110xxxxx 10xxxxxx。第一個字節的110和第二個字節的10為標志位。當要表示的內容在12到16位的時候就用三個字節存儲，形如1110xxxx 10xxxxxx 10xxxxxx。第一個字節的1110和第二、三個字節的10為標志位，其余的碼位用來表示漢字。

UTF-8以8位為單元對UCS-2編碼模板，詳見表1。

表1 UTF-8對UCS-2編碼模板

Tab.1 UTF-8 to UCS-2 encoding templateendprint

UCS-2編碼值（H） UTF-8編碼結構（B）

0000-007F 0xxxxxxx

0080-07FF 110xxxxx 10xxxxxx

0800-FFFF 1110xxxx 10xxxxxx 10xxxxxx

UTF-8以8位為單元對UCS-4編碼模板，詳見表2。

表2 UTF-8對UCS-4編碼模板

Tab.2 UTF-8 to UCS-4 encoding template

UCS-4編碼值（H） UTF-8編碼結構（B）

0000 0000-0000 007F 0xxxxxxx

0000 0080-0000 07FF 110xxxxx 10xxxxxx

0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx

0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

0400 0000-7FFF FFFF 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

2.5 關于BOM問題

新建空文本文檔分別以ANSI、Unicode、Unicode big endian、UTF-8編碼格式存儲，通過軟件Winhex解析文件，發現除ANSI編碼外，其他編碼方式都存在標志頭字符，即根據不同的編碼方式在其文件頭添加規定的標志字符用以區分。Unicode規范中稱該標志字符為字節順序標志（Byter Order Mark，BOM），俗稱標簽。Winhex解析各種編碼類型的BOM，詳見表3。

表3 各種編碼類型BOM

Tab.3 BOM of various encoding types

編碼方式 BOM

ANSI 無

UTF-16（Unicode）/UCS-2 little endian FF FE

UTF-16（Unicode）/UCS-2 big endian FE FF

UTF-8 EF BB BF

3 軟件對文件編碼方式誤判的研究（Research

software for document encoding misjudgment）

在上述編碼知識的基礎上，下面針對記事本不能正常顯示“聯通”二字進行分析。

3.1 記事本不能正常顯示“聯通”二字的研究

新建文本文檔1，輸入“聯通”二字，保存后退出，記事本是以默認存儲的編碼方式（即ANSI）進行保存的。再次打開后會發現顯示為亂碼，點擊文件-另存為，發現該文件編碼方式顯示為UTF-8，說明記事本認為這是一個UTF-8編碼的文件。如果再新建一個文本文檔2，文件-打開，選中文本文檔1后，編碼方式選擇ANSI，打開后便能正確顯示“聯通”二字，或者在新建文本文檔1中輸入“聯通”二字后，另存時編碼選擇為UTF-8，保存后退出，再次打開也能正常顯示“聯通”二字。由此可以推斷這是編碼問題導致的。

新建文本文檔，輸入“聯通”二字保存后，將文件導入Winhex查看其十六進制編碼，發現為C1 AA CD A8（H），由此可以確定記事本是將“聯通”二字按照ANSI編碼方式進行存儲的，因此再次打開時選擇ANSI編碼，記事本將按照對應方式解碼，“聯通”二字便可以正常顯示了。因此，若首次將“聯通”二字保存為UTF-8編碼方式，記事本按照UTF-8解碼（Decoding）時便能正確顯示了。

雙擊打開文件，內容顯示為亂碼，是因為記事本將ANSI編碼存儲的文件用UTF-8編碼對應的解碼方式進行了解碼，致使錯誤產生。“聯通”二字的ANSI編碼為C1 AA CD A8，如圖1所示，對應二進制代碼為1100 0001（C1），1010 1010（AA），1100 1101（CD），1010 1000（A8）。

圖1 “聯通”的ANSI編碼

Fig.1 ANSI encoding of Unicom

對于“聯”字，第一二個字節、第三四個字節的起始部分都是“110”和“10”，正好符合UTF-8規則里的雙字節模板。再次打開文件時，記事本其實根據二進制代碼錯誤判斷得出這是一個UTF-8編碼的文件，根據UTF-8規則去掉第一個字節的110和第二個字節的10，得到有效代碼為1101010，補上前導0后為0000 0000，0110 1010，即006A（H）在Unicode字符集中對應小寫字母j。同理，“通”字也按此解碼得到0368（H），在Unicode字符集中該編碼不對應任何字符，因此致使記事本顯示為亂碼。

3.2 對記事本IsTextUTF8函數的研究

那么記事本究竟通過何種方式來判斷文件的編碼方式呢？

猜測是根據有無BOM判斷的。早期一些軟件并不在文件頭添加相應的BOM文件，因此軟件不能單純通過BOM進行判斷，不得不進行模糊判斷。通過分析記事本的源代碼，可知記事本是通過nputf.c文件中的函數INT IsTextUTF8（LPSTR lpstrInputStream，INT iLen）進行判斷的，對此函數作出如下分析。

//基于UTF-8雙字節模板編碼方式進行判斷

//若為UTF-8編碼該函數返回真，若判斷只屬于前128個字符返回假，認為是ASCII碼endprint

INT IsTextUTF8（LPSTR lpstrInputStream， INT iLen）{

DWORD cOctets； //cOctets若是UTF-8，控制以10開頭位段數

UCHAR chr；//一個字節長度的字符類型chr

BOOL bAllAscii= TRUE；//若為真將按照ASCII碼標準進行編碼

INT i； cOctets= 0；

for（i=0； i < iLen； i++） {

chr= *（lpstrInputStream+i）；

if（（chr&0x80） ！= 0） bAllAscii= FALSE；//0x80對應二進制是1000 0000，因為ASCII碼只用了7位，首位為零，若是ASCII碼，該判斷值為假

if（cOctets == 0 {//當字符不全由ACSII組成時

if（chr >= 0x80）{//若大于0x80，說明在ASCII碼之外

do {

chr <<= 1；//向左移位，用以判定是否符合UTF-8開頭110 1110…的方式

cOctets++；//10開頭位段數加一

}

while（（chr&0x80） ！= 0）；

cOctets--；//臨界處理

if（cOctets == 0） return FALSE；//若不符合形式11xx xxxx返回假

}

}

else {

if（（chr&0xC0） ！= 0x80）{//若八位組編碼符合10xx xxxx形式返回真，否則返回假

return FALSE；

}

cOctets--；//處理下一個八位組編碼

}

}//文本統計判斷結束

if（cOctets >0） {

return FALSE；//若后邊的八位組與首個八位組首位1的個數不滿足UTF-8的規律返回假

}

if（bAllAscii） {return FALSE；//若全部滿足符合ASCII碼，均小于128，返回假

}

return TRUE；//若不滿足上述情況返回真

}

由此可以看出，記事本正是通過UTF-8標志位的特殊形式進行判斷的，證實了“聯通”二字不能正常顯示原因的推斷。由此，可以得出結論“聯通”二字不能正常顯示是因為誤將ANSI編碼方式判斷為UTF-8編碼，致使解碼錯誤導致無法在相應字符集找到字符，故顯示為亂碼。

4 更多不能被正確解碼的漢字（More characters

can not be correctly decoded）

綜上所述，是否符合研究得到形式的字符都會被錯誤解碼呢？

根據誤判原因和UTF-8雙字節模板特點，發現16進制形式漢字字符，只要第一個字符為C或D，第三個字符為A或B的，都將被誤解碼。

Code 0 1 2 3 4 5 6 7 8 9 A B C D E F

C0A0饋 愧 潰 坤 昆 捆 困 括 擴 廓 闊 垃 拉 喇 蠟

C0B0臘 辣 啦 萊 來 賴 藍 婪 欄 攔 籃 闌 蘭 瀾 讕 攬

C1A0痢 立 粒 瀝 隸 力 璃 哩 倆 聯 蓮 連 鐮 廉 憐

C1B0漣 簾 斂 臉 鏈 戀 煉 練 糧 涼 梁 粱 良 兩 輛 量

……

D0A0小 孝 校 肖 嘯 笑 效 楔 些 歇 蝎 鞋 協 挾 攜

D0B0邪 斜 脅 諧 寫 械 卸 蟹 懈 泄 瀉 謝 屑 薪 芯 鋅

……

符合上述特點的漢字組成的高頻詞語，如“笑臉”“謝謝”“兩輛”“拉力”等，它們不能正確的顯示會使人們產生困惑。在這些漢字之后繼續輸入其他漢字即可正常顯示，而全文僅由符合上述特點的漢字組成便會顯示為亂碼。這是由于INT IsTextUTF8（LPSTR lpstrInputStream，INT iLen）函數是基于統計判斷的，一篇文章只要有一組不符合UTF-8編碼形式軟件便會認為文本是ANSI編碼。

5 結論（Conclusion）

本文通過分析發現，漢字文本顯示為亂碼是軟件對文件編碼方式的錯誤判斷造成的，發現了更多記事本不能正確顯示的漢字，由這些漢字組成的高頻詞語不能正確的顯示會使人們產生困惑。對軟件如何能正確判斷文件的編碼方式，還需要具體的程序來實現。

參考文獻（References）

[1] 馮靈清，楊懷卿，劉宇晶.常用編碼方式及其轉換格式[J].計算

機時代，2012（1）：33-35.

[2] 張曉培，李祥.從Unicode到GBK的內碼轉換[J].微計算機應用，

2006，27（6）：757-759.

[3] 邱發林，李偉，周紹景.Unicode及中文到Unicode轉換[J].科技

信息，2006（3）：21-22.

作者簡介：

王 玉（1993-），男，本科.研究領域：計算機應用.

張永勝（1962-），男，教授，碩士生導師.研究領域：面向服務

計算，Web Services安全.endprint

INT IsTextUTF8（LPSTR lpstrInputStream， INT iLen）{

DWORD cOctets； //cOctets若是UTF-8，控制以10開頭位段數

UCHAR chr；//一個字節長度的字符類型chr

BOOL bAllAscii= TRUE；//若為真將按照ASCII碼標準進行編碼

INT i； cOctets= 0；

for（i=0； i < iLen； i++） {

chr= *（lpstrInputStream+i）；

if（（chr&0x80） ！= 0） bAllAscii= FALSE；//0x80對應二進制是1000 0000，因為ASCII碼只用了7位，首位為零，若是ASCII碼，該判斷值為假

if（cOctets == 0 {//當字符不全由ACSII組成時

if（chr >= 0x80）{//若大于0x80，說明在ASCII碼之外

do {

chr <<= 1；//向左移位，用以判定是否符合UTF-8開頭110 1110…的方式

cOctets++；//10開頭位段數加一

}

while（（chr&0x80） ！= 0）；

cOctets--；//臨界處理

if（cOctets == 0） return FALSE；//若不符合形式11xx xxxx返回假

}

}

else {

if（（chr&0xC0） ！= 0x80）{//若八位組編碼符合10xx xxxx形式返回真，否則返回假

return FALSE；

}

cOctets--；//處理下一個八位組編碼

}

}//文本統計判斷結束

if（cOctets >0） {

return FALSE；//若后邊的八位組與首個八位組首位1的個數不滿足UTF-8的規律返回假

}

if（bAllAscii） {return FALSE；//若全部滿足符合ASCII碼，均小于128，返回假

}

return TRUE；//若不滿足上述情況返回真

}

由此可以看出，記事本正是通過UTF-8標志位的特殊形式進行判斷的，證實了“聯通”二字不能正常顯示原因的推斷。由此，可以得出結論“聯通”二字不能正常顯示是因為誤將ANSI編碼方式判斷為UTF-8編碼，致使解碼錯誤導致無法在相應字符集找到字符，故顯示為亂碼。

4 更多不能被正確解碼的漢字（More characters

can not be correctly decoded）

綜上所述，是否符合研究得到形式的字符都會被錯誤解碼呢？

根據誤判原因和UTF-8雙字節模板特點，發現16進制形式漢字字符，只要第一個字符為C或D，第三個字符為A或B的，都將被誤解碼。

Code 0 1 2 3 4 5 6 7 8 9 A B C D E F

C0A0饋 愧 潰 坤 昆 捆 困 括 擴 廓 闊 垃 拉 喇 蠟

C0B0臘 辣 啦 萊 來 賴 藍 婪 欄 攔 籃 闌 蘭 瀾 讕 攬

C1A0痢 立 粒 瀝 隸 力 璃 哩 倆 聯 蓮 連 鐮 廉 憐

C1B0漣 簾 斂 臉 鏈 戀 煉 練 糧 涼 梁 粱 良 兩 輛 量

……

D0A0小 孝 校 肖 嘯 笑 效 楔 些 歇 蝎 鞋 協 挾 攜

D0B0邪 斜 脅 諧 寫 械 卸 蟹 懈 泄 瀉 謝 屑 薪 芯 鋅

……

符合上述特點的漢字組成的高頻詞語，如“笑臉”“謝謝”“兩輛”“拉力”等，它們不能正確的顯示會使人們產生困惑。在這些漢字之后繼續輸入其他漢字即可正常顯示，而全文僅由符合上述特點的漢字組成便會顯示為亂碼。這是由于INT IsTextUTF8（LPSTR lpstrInputStream，INT iLen）函數是基于統計判斷的，一篇文章只要有一組不符合UTF-8編碼形式軟件便會認為文本是ANSI編碼。

5 結論（Conclusion）

本文通過分析發現，漢字文本顯示為亂碼是軟件對文件編碼方式的錯誤判斷造成的，發現了更多記事本不能正確顯示的漢字，由這些漢字組成的高頻詞語不能正確的顯示會使人們產生困惑。對軟件如何能正確判斷文件的編碼方式，還需要具體的程序來實現。

參考文獻（References）

[1] 馮靈清，楊懷卿，劉宇晶.常用編碼方式及其轉換格式[J].計算

機時代，2012（1）：33-35.

[2] 張曉培，李祥.從Unicode到GBK的內碼轉換[J].微計算機應用，

2006，27（6）：757-759.

[3] 邱發林，李偉，周紹景.Unicode及中文到Unicode轉換[J].科技

信息，2006（3）：21-22.

作者簡介：

王 玉（1993-），男，本科.研究領域：計算機應用.

張永勝（1962-），男，教授，碩士生導師.研究領域：面向服務

計算，Web Services安全.endprint

INT IsTextUTF8（LPSTR lpstrInputStream， INT iLen）{

DWORD cOctets； //cOctets若是UTF-8，控制以10開頭位段數

UCHAR chr；//一個字節長度的字符類型chr

BOOL bAllAscii= TRUE；//若為真將按照ASCII碼標準進行編碼

INT i； cOctets= 0；

for（i=0； i < iLen； i++） {

chr= *（lpstrInputStream+i）；

if（（chr&0x80） ！= 0） bAllAscii= FALSE；//0x80對應二進制是1000 0000，因為ASCII碼只用了7位，首位為零，若是ASCII碼，該判斷值為假

if（cOctets == 0 {//當字符不全由ACSII組成時

if（chr >= 0x80）{//若大于0x80，說明在ASCII碼之外

do {

chr <<= 1；//向左移位，用以判定是否符合UTF-8開頭110 1110…的方式

cOctets++；//10開頭位段數加一

}

while（（chr&0x80） ！= 0）；

cOctets--；//臨界處理

if（cOctets == 0） return FALSE；//若不符合形式11xx xxxx返回假

}

}

else {

if（（chr&0xC0） ！= 0x80）{//若八位組編碼符合10xx xxxx形式返回真，否則返回假

return FALSE；

}

cOctets--；//處理下一個八位組編碼

}

}//文本統計判斷結束

if（cOctets >0） {

return FALSE；//若后邊的八位組與首個八位組首位1的個數不滿足UTF-8的規律返回假

}

if（bAllAscii） {return FALSE；//若全部滿足符合ASCII碼，均小于128，返回假

}

return TRUE；//若不滿足上述情況返回真

}

由此可以看出，記事本正是通過UTF-8標志位的特殊形式進行判斷的，證實了“聯通”二字不能正常顯示原因的推斷。由此，可以得出結論“聯通”二字不能正常顯示是因為誤將ANSI編碼方式判斷為UTF-8編碼，致使解碼錯誤導致無法在相應字符集找到字符，故顯示為亂碼。

4 更多不能被正確解碼的漢字（More characters

can not be correctly decoded）

綜上所述，是否符合研究得到形式的字符都會被錯誤解碼呢？

根據誤判原因和UTF-8雙字節模板特點，發現16進制形式漢字字符，只要第一個字符為C或D，第三個字符為A或B的，都將被誤解碼。

Code 0 1 2 3 4 5 6 7 8 9 A B C D E F

C0A0饋 愧 潰 坤 昆 捆 困 括 擴 廓 闊 垃 拉 喇 蠟

C0B0臘 辣 啦 萊 來 賴 藍 婪 欄 攔 籃 闌 蘭 瀾 讕 攬

C1A0痢 立 粒 瀝 隸 力 璃 哩 倆 聯 蓮 連 鐮 廉 憐

C1B0漣 簾 斂 臉 鏈 戀 煉 練 糧 涼 梁 粱 良 兩 輛 量

……

D0A0小 孝 校 肖 嘯 笑 效 楔 些 歇 蝎 鞋 協 挾 攜

D0B0邪 斜 脅 諧 寫 械 卸 蟹 懈 泄 瀉 謝 屑 薪 芯 鋅

……

符合上述特點的漢字組成的高頻詞語，如“笑臉”“謝謝”“兩輛”“拉力”等，它們不能正確的顯示會使人們產生困惑。在這些漢字之后繼續輸入其他漢字即可正常顯示，而全文僅由符合上述特點的漢字組成便會顯示為亂碼。這是由于INT IsTextUTF8（LPSTR lpstrInputStream，INT iLen）函數是基于統計判斷的，一篇文章只要有一組不符合UTF-8編碼形式軟件便會認為文本是ANSI編碼。

5 結論（Conclusion）

本文通過分析發現，漢字文本顯示為亂碼是軟件對文件編碼方式的錯誤判斷造成的，發現了更多記事本不能正確顯示的漢字，由這些漢字組成的高頻詞語不能正確的顯示會使人們產生困惑。對軟件如何能正確判斷文件的編碼方式，還需要具體的程序來實現。

參考文獻（References）

[1] 馮靈清，楊懷卿，劉宇晶.常用編碼方式及其轉換格式[J].計算

機時代，2012（1）：33-35.

[2] 張曉培，李祥.從Unicode到GBK的內碼轉換[J].微計算機應用，

2006，27（6）：757-759.

[3] 邱發林，李偉，周紹景.Unicode及中文到Unicode轉換[J].科技

信息，2006（3）：21-22.

作者簡介：

王 玉（1993-），男，本科.研究領域：計算機應用.

張永勝（1962-），男，教授，碩士生導師.研究領域：面向服務

計算，Web Services安全.endprint