常用編碼總結

本文轉自：http://www.cnblogs.com/tianguook/archive/2013/01/30/2882291.html

1.  ASCII和Ansi編碼

    字元内碼(charcter code)指的是用來代表字元的内碼.讀者在輸入和存儲文檔時都要使用内碼,内碼分為 

    單位元組内碼 -- Single-Byte character sets (SBCS),可以支援256個字元編碼. 

    雙位元組内碼 -- Double-Byte character sets)(DBCS),可以支援65000個字元編碼.

    前者即為ASCII編碼，後者對應ANSI.

    至于簡體中文編碼GB2312，實際上它是ＡＮＳＩ的一個代碼頁936

  缺點:

• 1.不能表示所有字元:
• 2.櫃同的編瑪表示的字元不一樣:比如。130在法語編碼中代表了é。在希伯來語編瑪中卻代表了字母λ.

2. Unicode

　如上，ANSI有很多代碼頁，使用不同代碼頁的内碼無法在其他代碼也正常顯示，這就是為什麼日文版／繁體中文版遊戲無法在簡體中文平台直接顯示的原因．

    Unicode也是一種字元編碼方法，不過它是由國際組織設計，可以容納全世界所有語言文字的編碼方案．它是一種２位元組編碼，能夠提供６５５３６個字元，這個數字是不夠表示所有的字元的（漢語就有５５０００多字元），是以，通過一個代理對的機制來實作附加的９１７，４７６個字元表示，以達到所有字元都具有唯一編碼．

    Unicode和BigEndianUnicode

    這兩者隻是存儲順序不同，如＂A＂的unicode編碼為65 00

    其BigEndianUnicode編碼為00 65

    Unicode的缺點:unicode隻是一個符号.集，它隻規定了符号的二進制代碼，卻沒有規定這個二進制代碼如何存儲：無法差別Unicode 和ASCII:計算機無法區分三個位元組表示一個符号還是分别表示三個符号。

  UTF-8

    這是為傳輸而設計的編碼，其系列還有UTF-7和UTF-16

    其中UTF-16和Unicode編碼大緻一樣, UTF-8就是以8位為單元對Unicode進行編碼。從Unicode到UTF-8的編碼方式如下：

　　　　　Unicode編碼(16進制)　　　　　　UTF-8 位元組流(二進制) 

　　　　　0000 - 007F　　　　　　　　　0xxxxxxx 

　　　　　0080 - 07FF　　　　　　　　　110xxxxx 10xxxxxx 

　　　　　0800 - FFFF　　　　　　　　　1110xxxx 10xxxxxx 10xxxxxx 

　　例如“漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間，是以肯定要用3位元組模闆了：1110xxxx 10xxxxxx 10xxxxxx。将6C49寫成二進制是：0110 110001 001001， 用這個比特流依次代替模闆中的x，得到：11100110 10110001 10001001，即E6 B1 89。

ANSI：系統預設的标準文字儲存格式。ANSI是American National Standards Institute的縮寫。它成立于1918年，是一個自願性的組織，擁有超過1300個會員，包括所有大型的電腦公司。ANSI專為電腦工業建立标準，它是世界上相當重要的标準。 

Unicode：世界上所有主要指令檔案的聯集，包括商業和個人電腦所使用的公用字集。當采用Unicode格式儲存檔案時，可使用Unicode控制字元輔助說明語言的文字覆寫範圍，如阿拉伯語、希伯來語。使用者在“記事本”中輸入含有Unicode字元的文字并儲存檔案時，系統會提示你必須選取“另存為”中的Unicode編碼，這些字元才不會被遺失。需要提醒大家的是，部分Windows 2000字型無法顯示所有的Unicode字元。如果發現檔案中缺少了某些字元，隻需将其變更為其它字型即可。 

Unicode big endian：在Big-endian處理器（如蘋果Macintosh電腦）上建立的Unicode檔案中的文字位元組（存放機關）排列順序，與在Intel處理器上建立的檔案的文字位元組排列順序相反。最重要的位元組擁有最低的位址，且會先儲存文字中較大的一端。為使這類電腦的使用者能夠存取你的檔案，可選擇Unicode big-endian格式。 

UTF-8：UTF意為通用字集轉換格式(Universal Character Set Transformation Format)，UTF-8是Unicode的8位元格式。如果使用隻能在同類位元組内支援8個位元的重要資料一類的舊式傳輸媒體，可選擇UTF-8格式。

Unicode是一種字元編碼規範 。

先從ASCII說起。ASCII是用來表示英文字元的一種編碼規範，每個ASCII字元占用1個位元組（8bits） 

是以，ASCII編碼可以表示的最大字元數是256，其實英文字元并沒有那麼多，一般隻用前128個（最高位為0），其中包括了控制字元、數字、大小寫字母和其他一些符号 。

而最高位為1的另128個字元被成為“擴充ASCII”，一般用來存放英文的制表符、部分音标字元等等的一些其他符号

這種字元編碼規範顯然用來處理英文沒有什麼問題 。（實際上也可以用來處理法文、德文等一些其他的西歐字元，但是不能和英文通用），但是面對中文、阿拉伯文之類複雜的文字，255個字元顯然不夠用于是，各個國家紛紛制定了自己的文字編碼規範，其中中文的文字編碼規範叫做“GB2312-80”，它是和ASCII相容的一種編碼規範，其實就是利用擴充ASCII沒有真正标準化這一點，把一個中文字元用兩個擴充ASCII字元來表示。 

但是這個方法有問題，最大的問題就是，中文文字沒有真正屬于自己的編碼，因為擴充ASCII碼雖然沒有真正的标準化，但是PC裡的ASCII碼還是有一個事實标準的（存放着英文制表符），是以很多軟體利用這些符号來畫表格。這樣的軟體用到中文系統中，這些表格符就會被誤認作中文字，破壞版面。而且，統計中英文混合字元串中的字數，也是比較複雜的，我們必須判斷一個ASCII碼是否擴充，以及它的下一個ASCII是否擴充，然後才“猜”那可能是一個中文字 。

總之當時進行中文是很痛苦的。而更痛苦的是GB2312是國家标準，台灣當時有一個Big5編碼标準，很多編碼和GB是相同的，是以……，嘿嘿。 

這時候，我們就知道，要真正解決中文問題，不能從擴充ASCII的角度入手，也不能僅靠中國一家來解決。而必須有一個全新的編碼系統，這個系統要可以将中文、英文、法文、德文……等等所有的文字統一起來考慮，為每個文字都配置設定一個單獨的編碼，這樣才不會有上面那種現象出現。 

于是，Unicode誕生了。 

Unicode有兩套标準，一套叫UCS-2(Unicode-16)，用2個位元組為字元編碼，另一套叫UCS-4(Unicode-32)，用4個位元組為字元編碼。 以目前常用的UCS-2為例，它可以表示的字元數為2^16=65535，基本上可以容納所有的歐美字元和絕大部分的亞洲字元 。

UTF-8的問題後面會提到 。

在Unicode裡，所有的字元被一視同仁。漢字不再使用“兩個擴充ASCII”，而是使用“1個Unicode”，注意，現在的漢字是“一個字元”了，于是，拆字、統計字數這些問題也就自然而然的解決了 。

但是，這個世界不是理想的，不可能在一夜之間所有的系統都使用Unicode來處理字元，是以Unicode在誕生之日，就必須考慮一個嚴峻的問題：和ASCII字元集之間的不相容問題。 

我們知道，ASCII字元是單個位元組的，比如“A”的ASCII是65。而Unicode是雙位元組的，比如“A”的Unicode是0065，這就造成了一個非常大的問題：以前處理ASCII的那套機制不能被用來處理Unicode了 。

另一個更加嚴重的問題是，C語言使用'/0'作為字元串結尾，而Unicode裡恰恰有很多字元都有一個位元組為0，這樣一來，C語言的字元串函數将無法正常處理Unicode，除非把世界上所有用C寫的程式以及他們所用的函數庫全部換掉 。

于是，比Unicode更偉大的東東誕生了，之是以說它更偉大是因為它讓Unicode不再存在于紙上，而是真實的存在于我們大家的電腦中。那就是：UTF 。

UTF= UCS Transformation Format UCS轉換格式 

它是将Unicode編碼規則和計算機的實際編碼對應起來的一個規則。現在流行的UTF有2種：UTF-8和UTF-16 。

其中UTF-16和上面提到的Unicode本身的編碼規範是一緻的，這裡不多說了。而UTF-8不同，它定義了一種“區間規則”，這種規則可以和ASCII編碼保持最大程度的相容 。

UTF-8有點類似于Haffman編碼，它将Unicode編碼為00000000-0000007F的字元，用單個位元組來表示； 

00000080-000007FF的字元用兩個位元組表示 

00000800-0000FFFF的字元用3位元組表示 

因為目前為止Unicode-16規範沒有指定FFFF以上的字元，是以UTF-8最多是使用3個位元組來表示一個字元。但理論上來說，UTF-8最多需要用6位元組表示一個字元。 

在UTF-8裡，英文字元仍然跟ASCII編碼一樣，是以原先的函數庫可以繼續使用。而中文的編碼範圍是在0080-07FF之間，是以是2個位元組表示（但這兩個位元組和GB編碼的兩個位元組是不同的），用專門的Unicode處理類可以對UTF編碼進行處理。 

3.下面說說中文的問題。 

由于曆史的原因，在Unicode之前，一共存在過3套中文編碼标準。 

GB2312-80，是中國大陸使用的國家标準，其中一共編碼了6763個常用簡體漢字。Big5，是台灣使用的編碼标準，編碼了台灣使用的繁體漢字，大概有8千多個。HKSCS，是中國香港使用的編碼标準，字型也是繁體，但跟Big5有所不同。 

這3套編碼标準都采用了兩個擴充ASCII的方法，是以，幾套編碼互不相容，而且編碼區間也各有不同

因為其不相容性，在同一個系統中同時顯示GB和Big5基本上是不可能的。當時的南極星、RichWin等等軟體，在自動識别中文編碼、自動顯示正确編碼方面都做了很多努力 。

他們用了怎樣的技術我就不得而知了，我知道好像南極星曾經以同屏顯示繁簡中文為賣點。 

後來，由于各方面的原因，國際上又制定了針對中文的統一字元集GBK和GB18030，其中GBK已經在Windows、Linux等多種作業系統中被實作。 

GBK相容GB2312，并增加了大量不常用漢字，還加入了幾乎所有的Big5中的繁體漢字。但是GBK中的繁體漢字和Big5中的幾乎不相容。 

GB18030相當于是GBK的超集，比GBK包含的字元更多。據我所知目前還沒有作業系統直接支援GB18030。 

談談Unicode編碼，簡要解釋UCS、UTF、BMP、BOM等名詞

這是一篇程式員寫給程式員的趣味讀物。所謂趣味是指可以比較輕松地了解一些原來不清楚的概念，增進知識，類似于打RPG遊戲的更新。整理這篇文章的動機是兩個問題：

問題一：

使用Windows記事本的“另存為”，可以在GBK、Unicode、Unicode big 

endian和UTF-8這幾種編碼方式間互相轉換。同樣是txt檔案，Windows是怎樣識别編碼方式的呢？

我很早前就發現Unicode、Unicode big 

endian和UTF-8編碼的txt檔案的開頭會多出幾個位元組，分别是FF、FE（Unicode）,FE、FF（Unicode big 

endian）,EF、BB、BF（UTF-8）。但這些标記是基于什麼标準呢？

問題二：

最近在網上看到一個ConvertUTF.c，實作了UTF-32、UTF-16和UTF-8這三種編碼方式的互相轉換。對于Unicode(UCS2)、GBK、UTF-8這些編碼方式，我原來就了解。但這個程式讓我有些糊塗，想不起來UTF-16和UCS2有什麼關系。

查了查相關資料，總算将這些問題弄清楚了，順帶也了解了一些Unicode的細節。寫成一篇文章，送給有過類似疑問的朋友。本文在寫作時盡量做到通俗易懂，但要求讀者知道什麼是位元組，什麼是十六進制。

0、big endian和little endian

big endian和little 

endian是CPU處理多位元組數的不同方式。例如“漢”字的Unicode編碼是6C49。那麼寫到檔案裡時，究竟是将6C寫在前面，還是将49寫在前面？如果将6C寫在前面，就是big 

endian。還是将49寫在前面，就是little endian。

“endian”這個詞出自《格列佛遊記》。小人國的内戰就源于吃雞蛋時是究竟從大頭(Big-Endian)敲開還是從小頭(Little-Endian)敲開，由此曾發生過六次叛亂，其中一個皇帝送了命，另一個丢了王位。

我們一般将endian翻譯成“位元組序”，将big endian和little 

endian稱作“大尾”和“小尾”。

1、字元編碼、内碼，順帶介紹漢字編碼

字元必須編碼後才能被計算機處理。計算機使用的預設編碼方式就是計算機的内碼。早期的計算機使用7位的ASCII編碼，為了處理漢字，程式員設計了用于簡體中文的GB2312和用于繁體中文的big5。

GB2312(1980年)一共收錄了7445個字元，包括6763個漢字和682個其它符号。漢字區的内碼範圍高位元組從B0-F7，低位元組從A1-FE，占用的碼位是72*94=6768。其中有5個空位是D7FA-D7FE。

GB2312支援的漢字太少。1995年的漢字擴充規範GBK1.0收錄了21886個符号，它分為漢字區和圖形符号區。漢字區包括21003個字元。2000年的GB18030是取代GBK1.0的正式國家标準。該标準收錄了27484個漢字，同時還收錄了藏文、蒙文、維吾爾文等主要的少數民族文字。現在的PC平台必須支援GB18030，對嵌入式産品暫不作要求。是以手機、MP3一般隻支援GB2312。

從ASCII、GB2312、GBK到GB18030，這些編碼方法是向下相容的，即同一個字元在這些方案中總是有相同的編碼，後面的标準支援更多的字元。在這些編碼中，英文和中文可以統一地處理。區分中文編碼的方法是高位元組的最高位不為0。按照程式員的稱呼，GB2312、GBK到GB18030都屬于雙位元組字元集 

(DBCS)。

有的中文Windows的預設内碼還是GBK，可以通過GB18030更新包更新到GB18030。不過GB18030相對GBK增加的字元，普通人是很難用到的，通常我們還是用GBK指代中文Windows内碼。

這裡還有一些細節：

GB2312的原文還是區位碼，從區位碼到内碼，需要在高位元組和低位元組上分别加上A0。

在DBCS中，GB内碼的存儲格式始終是big endian，即高位在前。

GB2312的兩個位元組的最高位都是1。但符合這個條件的碼位隻有128*128=16384個。是以GBK和GB18030的低位元組最高位都可能不是1。不過這不影響DBCS字元流的析：在讀取DBCS字元流時，隻要遇到高位為1的位元組，就可以将下兩個位元組作為一個雙位元組編碼，而不用管低位元組的高位是什麼。

2、Unicode、UCS和UTF

前面提到從ASCII、GB2312、GBK到GB18030的編碼方法是向下相容的。而Unicode隻與ASCII相容（更準确地說，是與ISO-8859-1相容），與GB碼不相容。例如“漢”字的Unicode編碼是6C49，而GB碼是BABA。

Unicode也是一種字元編碼方法，不過它是由國際組織設計，可以容納全世界所有語言文字的編碼方案。Unicode的學名是"Universal 

Multiple-Octet Coded Character Set"，簡稱為UCS。UCS可以看作是"Unicode 

Character Set"的縮寫。

根據維基百科全書(http://zh.wikipedia.org/wiki/)的記載：曆史上存在兩個試圖獨立設計Unicode的組織，即國際标準化組織（ISO）和一個軟體制造商的協會（unicode.org）。ISO開發了ISO 

10646項目，Unicode協會開發了Unicode項目。

在1991年前後，雙方都認識到世界不需要兩個不相容的字元集。于是它們開始合并雙方的工作成果，并為創立一個單一編碼表而協同工作。從Unicode2.0開始，Unicode項目采用了與ISO 

10646-1相同的字庫和字碼。

目前兩個項目仍都存在，并獨立地公布各自的标準。Unicode協會現在的最新版本是2005年的Unicode 

4.1.0。ISO的最新标準是10646-3:2003。

UCS規定了怎麼用多個位元組表示各種文字。怎樣傳輸這些編碼，是由UTF(UCS 

Transformation Format)規範規定的，常見的UTF規範包括UTF-8、UTF-7、UTF-16。

IETF的RFC2781和RFC3629以RFC的一貫風格，清晰、明快又不失嚴謹地描述了UTF-16和UTF-8的編碼方法。我總是記不得IETF是Internet 

Engineering Task 

Force的縮寫。但IETF負責維護的RFC是Internet上一切規範的基礎。

3、UCS-2、UCS-4、BMP

UCS有兩種格式：UCS-2和UCS-4。顧名思義，UCS-2就是用兩個位元組編碼，UCS-4就是用4個位元組（實際上隻用了31位，最高位必須為0）編碼。下面讓我們做一些簡單的數學遊戲：

UCS-2有2^16=65536個碼位，UCS-4有2^31=2147483648個碼位。

UCS-4根據最高位為0的最高位元組分成2^7=128個group。每個group再根據次高位元組分為256個plane。每個plane根據第3個位元組分為256行 

(rows)，每行包含256個cells。當然同一行的cells隻是最後一個位元組不同，其餘都相同。

group 0的plane 0被稱作Basic Multilingual Plane, 

即BMP。或者說UCS-4中，高兩個位元組為0的碼位被稱作BMP。

将UCS-4的BMP去掉前面的兩個零位元組就得到了UCS-2。在UCS-2的兩個位元組前加上兩個零位元組，就得到了UCS-4的BMP。而目前的UCS-4規範中還沒有任何字元被配置設定在BMP之外。

4、UTF編碼

UTF-8就是以8位為單元對UCS進行編碼。從UCS-2到UTF-8的編碼方式如下：

UCS-2編碼(16進制) UTF-8 位元組流(二進制)

0000 - 007F 0xxxxxxx

0080 - 07FF 110xxxxx 10xxxxxx

0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx 

例如“漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間，是以肯定要用3位元組模闆了：1110xxxx 

10xxxxxx 10xxxxxx。将6C49寫成二進制是：0110 110001 001001， 

用這個比特流依次代替模闆中的x，得到：11100110 10110001 10001001，即E6 B1 89。

讀者可以用記事本測試一下我們的編碼是否正确。

UTF-16以16位為單元對UCS進行編碼。對于小于0x10000的UCS碼，UTF-16編碼就等于UCS碼對應的16位無符号整數。對于不小于0x10000的UCS碼，定義了一個算法。不過由于實際使用的UCS2，或者UCS4的BMP必然小于0x10000，是以就目前而言，可以認為UTF-16和UCS-2基本相同。但UCS-2隻是一個編碼方案，UTF-16卻要用于實際的傳輸，是以就不得不考慮位元組序的問題。

5、UTF的位元組序和BOM

UTF-8以位元組為編碼單元，沒有位元組序的問題。UTF-16以兩個位元組為編碼單元，在解釋一個UTF-16文本前，首先要弄清楚每個編碼單元的位元組序。例如收到一個“奎”的Unicode編碼是594E，“乙”的Unicode編碼是4E59。如果我們收到UTF-16位元組流“594E”，那麼這是“奎”還是“乙”？

Unicode規範中推薦的标記位元組順序的方法是BOM。BOM不是“Bill Of 

Material”的BOM表，而是Byte Order Mark。BOM是一個有點小聰明的想法：

在UCS編碼中有一個叫做"ZERO WIDTH NO-BREAK 

SPACE"的字元，它的編碼是FEFF。而FFFE在UCS中是不存在的字元，是以不應該出現在實際傳輸中。UCS規範建議我們在傳輸位元組流前，先傳輸字元"ZERO 

WIDTH NO-BREAK SPACE"。

這樣如果接收者收到FEFF，就表明這個位元組流是Big-Endian的；如果收到FFFE，就表明這個位元組流是Little-Endian的。是以字元"ZERO 

WIDTH NO-BREAK SPACE"又被稱作BOM。

UTF-8不需要BOM來表明位元組順序，但可以用BOM來表明編碼方式。字元"ZERO 

WIDTH NO-BREAK SPACE"的UTF-8編碼是EF BB 

BF（讀者可以用我們前面介紹的編碼方法驗證一下）。是以如果接收者收到以EF BB 

BF開頭的位元組流，就知道這是UTF-8編碼了。

Windows就是使用BOM來标記文本檔案的編碼方式的。

系統支援 

Windows 98 ：隻支援ANSI。 

Windows 2k ：既支援ANSI又支援UNICODE。 

Windows CE ：隻支援UNICODE。 

Windows 2000整個OS系統都是基于UNICODE的，為此在windows 2000下使用ANSI是需要付出代價的，雖然在編碼上不用任何的轉換，但是這種轉化是隐藏的，是占用系統資源的（CPU，記憶體）。 

在Windows 98下必須使用UNICODE，則需要自己手動的編碼切換。

在計算機中字元通常并不是儲存為圖像，每個字元都是使用一個編碼來表示的，而每個字元究竟使用哪個編碼代表，要取決于使用哪個字元集(charset)。

　　在最初的時候，Internet上隻有一種字元集——ANSI的ASCII字元集，它使用7 bits來表示一個字元，總共表示128個字元，其中包括了英文字母、數字、标點符号等常用字元。之後，又進行擴充，使用8 bits表示一個字元，可以表示256個字元，主要在原來的7 bits字元集的基礎上加入了一些特殊符号例如制表符。

　　後來，由于各國語言的加入，ASCII已經不能滿足資訊交流的需要，是以，為了能夠表示其它國家的文字，各國在ASCII的基礎上制定了自己的字元集，這些從ANSI标準派生的字元集被習慣的統稱為ANSI字元集，它們正式的名稱應該是MBCS(Multi-Byte Chactacter System，即多位元組字元系統)。這些派生字元集的特點是以ASCII 127 bits為基礎，相容ASCII 127，他們使用大于128的編碼作為一個Leading Byte，緊跟在Leading Byte後的第二（甚至第三）個字元與Leading Byte一起作為實際的編碼。這樣的字元集有很多，我們常見的GB-2312就是其中之一

　　例如在GB-2312字元集中，“連通”的編碼為C1 AC CD A8，其中C1和CD就是Leading Byte。前127個編碼為标準ASCII保留，例如“0”的編碼是30H（30H表示十六進制的30）。軟體在讀取時，如果看到30H，知道它小于128就是标準ASCII，表示“0”，看到C1大于128就知道它後面有一個另外的編碼，是以C1 AC一同構成一個整個的編碼，在GB-2312字元集中表示“連”。

　　由于每種語言都制定了自己的字元集，導緻最後存在的各種字元集實在太多，在國際交流中要經常轉換字元集非常不便。是以，提出了Unicode字元集，它固定使用16 bits（兩個位元組、一個字）來表示一個字元，共可以表示65536個字元。将世界上幾乎所有語言的常用字元收錄其中，友善了資訊交流。标準的Unicode稱為UTF-16。後來為了雙位元組的Unicode能夠在現存的處理單位元組的系統上正确傳輸，出現了UTF-8，使用類似MBCS的方式對Unicode進行編碼。注意UTF-8是編碼，它屬于Unicode字元集。Unicode字元集有多種編碼形式，而ASCII隻有一種，大多數MBCS（包括GB-2312）也隻有一種。

　　例如“連通”兩個字的Unicode标準編碼UTF-16 (big endian）為：DE 8F 1A 90

而其UTF-8編碼為：E8 BF 9E E9 80 9A

　　最後，當一個軟體打開一個文本時，它要做的第一件事是決定這個文本究竟是使用哪種字元集的哪種編碼儲存的。軟體有三種途徑來決定文本的字元集和編碼：

　　最标準的途徑是檢測文本最開頭的幾個位元組，如下表：

開頭位元組 Charset/encoding

EF BB BF　　　　UTF-8

FE FF　　　　　UTF-16/UCS-2, little endian

FF FE　　　　　UTF-16/UCS-2, big endian

FF FE 00 00　　UTF-32/UCS-4, little endian.

00 00 FE FF　　UTF-32/UCS-4, big-endian. 

　　例如插入标記後，連通”兩個字的UTF-16 (big endian）和UTF-8碼分别為：

FF FE DE 8F 1A 90

EF BB BF E8 BF 9E E9 80 9A

　　但是MBCS文本沒有這些位于開頭的字元集标記，更不幸的是，一些早期的和一些設計不良的軟體在儲存Unicode文本時不插入這些位于開頭的字元集标記。是以，軟體不能依賴于這種途徑。這時，軟體可以采取一種比較安全的方式來決定字元集及其編碼，那就是彈出一個對話框來請示使用者，例如将那個“連通”檔案拖到MS Word中，Word就會彈出一個對話框。

　　如果軟體不想麻煩使用者，或者它不友善向使用者請示，那它隻能采取自己“猜”的方法，軟體可以根據整個文本的特征來猜測它可能屬于哪個charset，這就很可能不準了。使用記事本打開那個“連通”檔案就屬于這種情況。

　　我們可以證明這一點：在記事本中鍵入“連通”後，選擇“Save As”，會看到最後一個下拉框中顯示有“ANSI”，這時儲存。當再當打開“連通”檔案出現亂碼後，再點選“File”->“Save As”，會看到最後一個下拉框中顯示有“UTF-8”，這說明記事本認為目前打開的這個文本是一個UTF-8編碼的文本。而我們剛才儲存時是用ANSI字元集儲存的。這說明，記事本猜測了“連通”檔案的字元集，認為它更像一個UTF-8編碼文本。這是因為“連通”兩個字的GB-2312編碼看起來更像UTF-8編碼導緻的，這是一個巧合，不是所有文字都這樣。可以使用記事本的打開功能，在打開“連通”檔案時在最後一個下拉框中選擇ANSI，就能正常顯示了。反過來，如果之前儲存時儲存為UTF-8編碼，則直接打開也不會出現問題。

　　如果将“連通”檔案放入MS Word中，Word也會認為它是一個UTF-8編碼的檔案，但它不能确定，是以會彈出一個對話框詢問使用者，這時選擇“簡體中文（GB2312）”，就能正常打開了。記事本在這一點上做得比較簡化罷了，這與這個程式的定位是一緻的。