摘要
自從進入計算機時代後，人們創造了許多編碼，來表示各國的語言文字。這些編碼從一開始設計時，就沒有考慮到要和其它編碼兼容，它們只是爲某個國家或某種語言來服務的。
隨着Internet的發展，各國間的聯繫更加緊密，出現在人們視野中的不再是單純某個國家的文字，越來越多其他國家的文字出現在了本地的計算機上。再加上由於歷史原因，即使是一個國家的文字，都可能會以多種編碼形式出現。雖然，一種統一的編碼Unicode流行起來了，併成爲了發展趨勢，但在目前的環境中，仍然存在着其他各種編碼。這樣，本地的計算機上就需要處理許多種的編碼。
以錯誤的編碼打開一個文本會導致亂碼，人們需要知道文本具體的編碼信息。人們需要手動選擇各種編碼，直到能夠正確顯示文本爲止，這是個痛苦的過程。字符編碼猜測工具能使人們從這種繁瑣的過程中解脫出來。
現在已經有了一些字符編碼猜測工具了，如IE和Mozilla都有這種功能。本文提出了另一種實現該工具的方法，實踐證明，該方法具有很高的可靠性，效率也很高，並且簡單易懂，可擴展。
識別語言種類是該工具的另一個副產品，目前上述兩種瀏覽器提供了部分功能。本文提出的方法，能夠猜測出更詳細的語言信息，例如ISO-8859-1，UTF-8的語言信息。
關鍵字：
全球化，本地化，字符編碼，編碼猜測
Abstract
Since the beginning of the computer age, many encoding schemes have been created to represent various writing scripts/characters for computerized data. With the advent of globalization and the development of the Internet, information exchanges crossing both language and regional boundaries are becoming ever more important. But the existence of multiple coding schemes presents a significant barrier. The Unicode has provided a universal coding scheme, but it has not so far replaced existing regional coding schemes for a variety of reasons. Thus, today's global software applications are required to handle multiple encodings in addition to supporting Unicode.
The text can not be shown correctly if we open it with wrong encoding. It takes pains to choose all the encoding till the text is shown correctly. The encoding detection tool can help us.
Such tools exist in some browser like Mozilla and IE. This article is about a new and simple way to implement the tool. It is proved to be stable, efficient and extendable.
One additional function provided by this tool is to guess the language of the text. It can show the language information in more detail than Mozilla and IE. For example: language information for encoding UTF-8 and ISO-8859-1.
Keywords：
Globalization, Localization, Charset, Encoding detection
目錄
3.2 字符分佈方法（Character Distribute）... 11
3.3 雙字符序列分佈方法（2-Char Sequence Distribute）... 12
第一章 引言
1.1 背景
自從進入計算機時代以來，人們創造了許多使用計算機數據表示的編碼方案來表達不同的文字/字符集。隨着全球化和Internet的發展，跨語言和區域的信息交換越來越重要。但是現存的多種編碼方案對此是一個屏障。Unicode提供了通用的編碼解決方案，但是，迄今爲止，各種各樣的因素使它並沒有代替現存的區域編碼方案。除了W
以錯誤的編碼打開一個文本會導致亂碼的出現，人們需要知道文本具體的編碼信息。網絡上傳播的HTML文件有時會通過標籤指定編碼，但這不是必需的，在實際情況中，能找到大量不帶編碼信息的HTML文件。即使是帶有編碼信息的HTML文件，也有可能因書寫的錯誤，導致了錯誤的編碼信息。
一種低效但是可行的方法是，可以逐個以每種編碼來打開文本，直到能正常顯示文本，不出現亂碼爲止。但人們會厭倦這種方法，因爲那需要花費大量的時間。
一個自動猜測字符編碼的工具能夠把人們從這種瑣碎的工作中解救出來，它能夠自動猜測文本的編碼形式，從而正確地顯示文本。
看起來有些不可思議，但目前確實有了一些已經實現的工具，如IE，Mozilla等瀏覽器。它們提供一個自動選擇編碼的菜單，當遇到一個未指定編碼的HTML文件時，便會自動調用這個工具，得出最可能的編碼，然後正確顯示網頁。
之所以能實現這樣的工具，是因爲文本中會包含很多的編碼信息，一些數據會在某些編碼中經常出現，而有些則永遠不會出現。還有一些編碼會有一些標記的符號（字符序列），如UTF的BOM（字節順序標記），ISO-2022的ESC序列，通過這些標記，能夠準確地定位到該編碼。
本文提供了實現這種工具的另一個方法，實踐證明，該方法具有很高的可靠性，效率也很高，並且簡單易懂，可擴展。
1.2 論文的主要工作
本論文從討論各種編碼的內部原理開始，從中找出猜測一部分編碼可用的方法。如ISO-2022編碼特殊的ESC序列，UTF的BOM，這些可以作爲判斷該種編碼的一個依據。在分析各種編碼中，可以看出大部分編碼ASCII 0-127部分的代碼點相同，這樣可以去除一部分噪聲數據。
接下來介紹了Mozilla字符編碼猜測工具的實現。這樣就能瞭解到其他工具是如何實現的，通過比較，可以看出本文實現的優越性以及不足，從而爲他人選擇本文實現作爲一個依據。
最重要的部分，詳細介紹了本實現。介紹了算法組間方差以及組間差，以及實現方法的概要。重點是放在可行性分析上，要讓人們知道這個方法確實行的通，需要有大量的數據來說明。該 部分會有許多試驗數據組成的表，來說明該方法是可靠的。最後，通過與Mozilla實現的比較，說明了該方法的優越性。
1.3 論文的組織
第一章：簡要字符編碼猜測工具出現的背景，以及實現該工具的可行性並介紹了作者的工作和論文的結構。
第二章：簡單介紹了各種編碼，包括ASCII碼，ISO-2022編碼，Unicode編碼。
第三章：介紹了Mozilla實現字符編碼猜測工具的方法。
第四章：詳細介紹了作者提出的實現方法，包括主要算法，實現的方法要點。還給出了該方法的可信性分析，以實驗數據說明該方法具有很高的可靠性。最後比較了本文實現和Mozilla的實現，從中可以看出本文實現的優越性。
第二章 各種編碼介紹
2.1 ASCII碼
ASCII（American Standard Code for Information Interchange），它的全稱是“美國信息交換標準代碼”。每個ASCII碼以1個字節（Byte）儲存，從0到數字127代表不同的常用符號，例如大 寫A的ASCII碼是65，小寫a則是97。由於ASCII字節的七個位，最高位並不使用，所以後來又將最高的一個位也編入這套內碼中，成爲八個位的延伸 ASCII（Extended ASCII）碼，這套內碼加上了許多外文和表格等特殊符號，成爲目前常用的內碼[2]。
2.2 ISO-8859系列
ISO-8859字符集系列上世紀80年代中期由歐洲製造商協會（ECMA）設計並被ISO所接受，是一整套關於字母語言的8位圖形字符集，現已有至少15種字符集存在該系列中。下面列舉了其中10種，並指出了其對應的地區或語言[3]：
表2-1 字符集語言對應表
|
字符集名稱 |
語系 |
語言或國家 |
|
ISO-8859-1 |
拉丁1（西歐） |
法語，西班牙語，葡萄牙語，意大利語，德語，荷蘭語，丹麥語，瑞典語，挪威語，英語，愛爾蘭語，斯瓦西里語，班圖語．．． |
|
ISO-8859-2 |
拉丁2（東歐） |
捷克語，匈牙利語，波蘭語，羅馬尼亞語，克羅地亞語，斯洛伐克語．．． |
|
ISO-8859-3 |
拉丁3（南歐） |
世界語，馬耳他語，土耳其語．．． |
|
ISO-8859-4 |
拉丁4（北歐） |
格陵蘭語，拉普蘭語，愛沙尼亞語，拉脫維亞語，立陶宛語．．． |
|
ISO-8859-5 |
斯拉夫語 |
保加利亞語，俄語，馬其頓語，塞爾維亞語，烏克蘭語．．． |
|
ISO-8859-6 |
阿拉伯語 |
阿拉伯語．．． |
|
ISO-8859-7 |
希臘語 |
希臘語．．． |
|
ISO-8859-8 |
希伯來語 |
希伯來語，依地語．．． |
|
ISO-8859-9 |
拉丁5（土耳其） |
土耳其語．．（用一些土耳其字符代替拉丁１中很少使用的冰島字符）． |
|
ISO-8859-10 |
拉丁6（北歐Nordic） |
整個北歐地區．．．（重新組織了拉丁４） |
注意：
1. 一個字符集可能用於多個地區，如ISO-8859-1，可以用於西歐，也可用於澳洲，北美等地區。
2. 一種語言不一定只能被一種編碼表示，如拉丁１到拉丁６都能表示德語。
每個字符集有256個字符，其中0-127部分與擴展ASCII碼對應部分相同，128-159是一些很少被使用的控制字符，在ISO 6429中被稱爲C1集。區別在於160-255部分。下圖爲ISO-8859編碼的結構圖。
0 128 160 255
|
ASCII |
C1集 |
區別部分 |
圖2-1 ISO-8859編碼結構圖
圖2-2和圖2-3列舉了2種字符集160-225部分的字符。
圖2-2 ISO-8859-1（拉丁1）
圖2-3 ISO-8859-7（希臘）
2.3 ISO-2022系列
對於像中文，日文，韓文這樣的文字，無法只用8位來表示所有的字符。ISO 2022提供了這樣一種技術，它能在一種字符編碼中支持多種字符集，可以用8位或16位來表示一個文字（字符），是一種變長的編碼，這樣，就能表示所有的上述東亞字符了。該編碼還有個顯著的特點，就是所有的字節都是以0開始（ASCII的0-127部分），有效位數是7，所以在網絡傳輸中，可以只傳7位。但同時出現了一個問題，如何區分哪些是ACSII部分的字符，哪些是東亞字符？ISO 2022用到的是標號（designations ）和變換函數（shift functions）。
標號又稱ESC序列（escape sequence），是一串以ASCII的ESC（ox1B）開頭的字符串，特定的字符串指明所用的字符集。
變換函數指明以何種方式解釋接下來的字符，包括以何種字符集解釋，解釋多長的字節（接下來的兩個字節或所有新的變換出現前的字節）。
下面介紹一下ISO-2022-CN（中文），ISO-2022-JP（日文），以及ISO-2022-KR（韓文）的實現方式。
2.3.1 ISO-2022-CN
ISO-2022-CN有3種標號：SO標號，SS2標號和SS3 標號（SS3只出現於ISO-2022-CN-EXT中）。SO標號的形式是ESC $ ) <F>，其中<F>表示終結字符，由ISO指定。SS2標號的形式是ESC $ * <F>，SS3標號的形式是ESC $ + <F>。新出現的同種標號會覆蓋前面的標號，如SO標號ESC $ ) A可以覆蓋之前出現的SO標號ESC $ ) G，接下來的出現在SO變換後的字符將由新的SO標號指定的字符集來解碼。
ISO-2022-CN有4種變換：SI，SO，SS2，SS3（SS3變換隻出現於ISO-2022-CN-EXT中）。
SI變換由一個字節ox
SO變換由一個字節ox0E指定，表明接下來的字節由SO標號指定的字符集來解釋。
SS2變換由兩個字節ox1B4E指定，表明接下來兩個字節由SS2標號指定的字符集來解釋，之後的字節又將由之前定義的變換來解釋（SI或SO）。
SS3變換由兩個字節ox1B
該編碼支持的字符集有ASCII，GB2312，CNS 11643-plane-1和CNS 11643-plane-2。
ISO-2022-CN所用的標號，變換函數，以及支持的字符集如表2-2所示，標號含義如表2-3所示。
表2-2 ISO-2022-CN 字符集變換函數對應表
|
字符集 |
變換函數 |
|
ASCII |
SI |
|
GB 2312, CNS 11643-plane-1 |
SO |
|
CNS 11643-plane-2 |
SS2 |
表2-3標號含義
|
ESC $ ) A |
表明在SO變換後的字節是由GB2312編碼的漢字字符，直至出現另一個SO標號。 |
|
ESC $ ) G |
表明在SO變換後的字節是由CNS 11643-plane-1編碼的漢字字符，直至出現另一個SO標號。 |
|
ESC $ * H |
表明緊接在SS2變換後的兩個字節是由CNS 11643-plane-2編碼的漢字字符，直至出現另一個SS2標號。 |
ISO-2022-CN-EXT是對ISO-2022-CN的一個擴展，支持漢字字符集：GB，Big5和CNS 11643，詳見RFC 1922[5]。
2.3.2 ISO-2022-JP
ISO-2022-JP比ISO-2022-CN出現更早，與ISO-2022-CN類似，但更簡單些，因爲它沒有用到變換函數，只用到了標號。標號（ESC序列）與字符集之間的對應關係如表2-4所示。
表2-4 ISO-2022-JP標號字符集對應表
|
ESC 序列 |
字符集 |
|
ESC ( B |
ASCII |
|
ESC ( J |
JIS X 0201-1976 ("Roman" set) |
|
ESC $ @ |
JIS X 0208-1978 |
|
ESC $ B |
JIS X 0208-1983 |
JIS X 0201與ASCII基本相同，除了兩個字符：反斜線符號（backslash）和tilde (~)。backslash被日元符號代替，tilde被overline代替。
JIS X 0208 字符集包括日本漢字，平假名，片假名和其它一些符號和字符。
若一行中含有JIS X 0208字符集，則在該行結束前，需要轉換到ASCII或JIS X 0201字符集，這個轉換指明瞭下一行開始所用的字符集。文本必須以ASCII結束，關於ISO-2022-JP的形式語法，詳見RFC 1468[6]。
2.3.3 ISO-2022-KR
ISO-2022-KR也有標號和變換函數，如表2-5所示：
表2-5 ISO-2022-KR變換函數字符集對應關係及標號意義表
|
SO |
KSC 5601 |
|
SI |
ASCII |
|
ESC $ ) C |
在第一個SO變換出現前的某一行的開始出現一次 |
KSC 5601字符集包括Hangul，Hanja，圖形和一些其它外來字符，每個字符由兩個字節組成。
ESC $ ) C標號的出現表明將要出現KSC 5601字符集中的字符，至多出現一次。若未出現，表明所有的字符都是ASCII。關於ISO-2022-KR的形式語法，詳見RFC 1557[7]。
2.4 Unicode
2.4.1 簡介
從ISO-2022字符集的實現方式中，可以看到一種處理CJK（中文，日文，韓文）的方式，就是使用ESC序列和控制字符，這樣就可以處理包含很多字符的語言了。Unicode標準使用了另一種方式，並且能處理更廣泛的字符，包含了世界上所有被廣泛使用的字符集。下面，來看一下這種編碼方式。
Unicode是被Unicode協會開發和維護的一套工業標準字符集，在1988年被提出。Unicode字符集能夠支持超過100萬的字符，其開發的最終目的是能夠支持所有語言的字符以及許多現在和過去世界上經常使用的符號。
最初，Unicode的設計目標是把每個字符設計成16位，不管該16位的字符出現於數據的何處，都能表示同一個字節。這樣，最多能表示65,536個字符。
之後，Unicode就處於不斷髮展之中。這時候就不得不提與之關係密切的另一個標準：ISO/IEC 10646。這個標準的工作組成立於1984年，其目標與Unicode極其相似，就是設計一個國際字符標準，以使能夠支持世界上所有的書寫系統。這就是人們現在熟悉的通用字符集（UCS brief for Universal Character Set）。
1991年前後，兩個項目的參與者都認識到，世界不需要兩個不同的單一字符集。它們合併雙方的工作成果，併爲創立一個單一編碼表而協同工作。兩個項目仍都存在並獨立地公佈各自的標準，但Unicode協會和ISO/IEC JTC1/SC2都同意保持Unicode和ISO 10646標準的碼錶兼容，並緊密地共同調整任何未來的擴展[10]。
Unicode的設計者很快發現65,536個字符對於中文這樣的象形文字來說是不夠的，所以他們對16位編碼作了改進，提出了UTF-16，允許超過100萬的字符。ISO/IEC標準使用31位的代碼空間（codespace），允許超過20億的字符，但100萬多的字符足夠了，所以永久保留了一部分代碼空間。
Unicode又提出了兩種編碼形式UTF-8和UTF-32，下面會作一些簡介。
2.4.2 UTF-16
Unicode的代碼空間是從U+0000到U+10FFFF，共分爲17個面板，第0個面板是從U+0000到U+FFFF，稱爲基本多語言面板（BMP brief for Basic Multilingual Plane），包含了大多數常用的字符。其它16個面板稱爲輔助面板（Supplementary Planes），其中許多還未被分配到。
代碼空間中有些代碼點（codepoints）是永久不分配的，有些是保留作非字符用的。如每個面板的最後兩個代碼點U+nFFFE 和 U+nFFFF不能被編碼成字符，軟件設計者可以在內部處理中使用它們。還有許多保留的私有用途代碼點，詳見參考文獻[11]。
有2048個特殊的保留代碼點：U+D800到U+DFFF，這些點在UTF-16中被用作特殊用途——代理代碼單元（surrogate code units或surrogates）。這2048個保留代碼點被均分爲兩組，每組1024個代碼點。0xD800–0xDBFF被稱爲高位代理（high surrogates），0xDC00–0xDFFF被稱爲低位代理（low surrogates）。一個高位代理加上跟在後面的一個低位代理組成一個代理對，一共有1,024×1,024 = 1,048,576種可能，正好包括了所有在輔助面板中的代碼點，這樣就能表示超過100萬個字符了。
因爲是用兩個字節來表示一個字符或代理，所以涉及到字節序的問題。大端是以最重要的字節開始，次重要的字節結束，小端則相反。編碼形式和字節序對應一個字符編碼模式（character encoding scheme）。
UTF-16有3種字符編碼模式，UTF-16BE（大端），UTF-16LE（小端），UTF-16（未指定端）。指定端的就非常容易處理了，對於未指定端的，一種方法是同時試兩種字節序，若解析出的字符從一種語言跳向了另一種語言，就說明很大可能不是以該字節序編碼的。
爲了解決這個問題，代碼點U+FEFF被指定爲字節序標記（BOM brief for byte order mark）。字節序標記被放在文件或數據流的開始，兩個相鄰的字節oxFE和oxFF只有在一種字節序中能表示字符，因爲U+FFFE是被保留的。oxFE+oxFF表明是大端，oxFF+oxFE表明是小端。字符U+FEFF還有另一個意思--ZERO WIDTH NO-BREAK SPACE，在未指定字節序的UTF-16編碼文件開始的U+FEFF只會被解釋爲字節序標記。
字節序標記還有另一個用處：暗示字符編碼。在絕大多數現存編碼中，文件以0xFE 0xFF或 0xFF 0xFE開頭是不太可能的，這個文件以UTF-16形式編碼的可能性非常大。
2.4.3 UTF-8
UTF-8的設計是爲了兼容現存的軟件，這些軟件被設計爲處理8位的文本數據。所以有必要使Unicode字符集中ASCII 0x00至0x
UTF-8用一個到四個的字節序列來表示整個Unicode代碼空間（理論上最多可有六個字節長）。
表2-6展示了UTF-8編碼的方式以及對應Unicode代碼點的區間。
表2-6 UTF-8編碼方式表
|
U-00000000 - U |
0xxxxxxx |
|
U-00000080 - U-000007FF: |
110xxxxx 10xxxxxx |
|
U-00000800 - U-0000FFFF: |
1110xxxx 10xxxxxx 10xxxxxx |
|
U-00010000 - U-001FFFFF: |
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
|
U-00200000 - U-03FFFFFF: |
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx |
|
U-04000000 - U-7FFFFFFF: |
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx |
xxx的位置由字符編碼數的二進制表示的位填入，越靠右的x具有越少的特殊意義，只用最短的那個足夠表達一個字符編碼數的多字節串。注意在多字節串中，第一個字節的開頭“
UTF-8沒有字節序的問題，因爲它是一個一個字節的處理數據的。但它也有BOM：EF BB BF，只是用來指示它是用UTF-8來編碼的。
2.4.4 UTF-32
UTF-32用32位來表示一個字符，和Unicode代碼空間中的字符是一一對應的。
UTF-32也有字節序的問題，用字節序列0x00 0x00 0xFE 0xFF和 0xFF 0xFE 0x00 0x00來表明大小端。
2.5 本章小結
本章介紹了ASCII碼，ISO-8859編碼，ISO-2022編碼，以及Unicode。瞭解這些編碼的內部實現原理，是本文實現的需要。後面章節會介紹識別ISO-2022編碼的狀態機，用到的就是這邊的編碼知識。用BOM來識別UTF編碼也需用到Unicode編碼的知識。本章是本文實現的理論基礎。
第三章 Mozilla字符編碼猜測實現方法
Mozilla使用的是三種不同的檢測文本數據編碼方法的綜合：編碼模式方法，字符分佈方法，雙字符序列分佈方法。
3.1 編碼模式方法
對每一個編碼模式，都有一個相應的狀態機被用來驗證這種特定編碼的字節序列。對檢測器收到的每一個字節，它將會被輸入到每一個可用的，活動的狀態機中，每次一個字節。狀態機基於前一個狀態和它所收到的字節來改變它的狀態。自動檢測器對狀態機的三種狀態感興趣[1]：
l START狀態：這種狀態代表兩種情形，初始化，或是代表字符集的一個合法字節序列已被驗證。
l ME狀態：這種狀態代表狀態機驗證到了字符集特有的一個字節序列，並且其它可能的字符集不包含這個字節序列。這會導致檢測器立即返回一個確定的回答。
l ERROR狀態：這種狀態代表狀態機驗證了字符集的一個非法字節序列。這會立即導致對這種字符集的否定回答。檢測器從此將會排除這種編碼方式，不作考慮。
3.2 字符分佈方法（Character Distribute）
無論哪種語言，總有一些字符比其它字符更常用。利用這個事實，我們可以對每種語言建立起相應的數據模式。對那些字符數較多的語言，比如漢語，日語和韓語，尤其有用。
判斷是否屬於某個編碼的度量是分佈率和可信度。一個給定編碼中的所有字符會被分到兩個類別中，“經常使用的”和“非經常使用的”。如果一個字符是出現在出現頻率分佈表中的前512個字符中，它會被分類到“經常使用”。之所以選擇512，是由於它在上述字符較多語言的輸入文本中都覆蓋了很大一部分的百分比，同時僅佔據一小部分的代碼點。
分佈率的定義如下：
分佈率=出現在512個最常用的字符中的字符數量/出現在剩下字符中的字符數量
可信度的定義如下：
可信度 = 實際分佈率 / 理想分佈率
實際分佈率是對於待測文本應用分佈率公式計算得來的值，理想分佈率是事先得到的，一般是對於該編碼的大量樣本應用分佈率公式得到的，而且這個值是和語言相關的。
可信度越大，說明越有可能是該編碼。若對於很大的文本來說，在該編碼上的可信度應該接近於1。如何判斷是不是該編碼，要用到兩個閾值，一個是可信的閾值，一個是不可信的閾值。高於可信的閾值，說明是該編碼，低於的話，說明不是該編碼[1]。
3.3 雙字符序列分佈方法（2-Char Sequence Distribute）
對僅使用很少一部分字符的語言來說，我們需要比統計單字元出現率更進一步。字符組合揭示了更多的語言-字符特性。我們定義雙字符序列爲在輸入文本中 接連出現的2個字符，在這種情況中，順序是非常重要的。由於在一種語言中，並不是所有字符都具有相同的出現率，雙字符序列分佈非常傾向於與語言/編碼相關。這種特性可以用在語言檢測上。在檢測字符編碼的時候，這會導致更好的可信度，在檢測單字節編碼上很有用處。
序列分析沒有對所有的字符都進行。我們當然可以通過建立一個256×256的矩陣來包含所有的那些字符序列，但是，其中的許多對語言/編碼分析來說是無關的。由於絕大多數的單字節語言僅使用數量不多於64個的字母，而最常 使用的64個字符幾乎包含了所有語言中都有的字符。因此，矩陣可以縮減成爲更小的64×64。所以我們使用64作爲我們工作中的採樣大小[1]。
計算分佈率和可信度的方法類似字符分佈方法。
3.4 複合方法
雙字符序列分佈方法可用來檢測所有的單字節編碼。編碼模式方法可以用在UTF-8，ISO-2022-xx和HZ檢測上。在UTF-8檢測 中，對現有的狀態機作了一點修改。UTF-8檢測器的成功檢測是在對多個多字節序列驗證之後作出的。編碼模式方法和字符分佈方法一起作用在了對主要東亞字符編碼進行檢測上，例如GB2312，Big5，EUC-TW， EUC-KR，Shift_JIS和EUC-JP。
對日語編碼，如Shift_JIS和EUC-JP，雙字符序列分佈方法同樣也能用於檢測，這是由於它們包含許多具有明顯特徵的平假名字符，這些平假名字符和單字節語言中的字母很相似。雙字符序列分佈方法在很少文本的情況下也能得到精確的結果。
上層的控制算法從ASCII驗證開始。如果所有字符都是ASCII的，除了ISO-2022-xx和HZ編碼外，其它檢測器就無需使用了。
ISO-2022-xx和HZ檢測器在遇到ESC或"~{"時會被載入，並且，在遇到8bit字節的時候，它們會被立即拋棄。
在驗證UCS2編碼的時候，會搜索BOM是否出現。我們發現有些網站在http流中發送0x00，但是，使用這個字節來驗證UCS2編碼被證明是不可信的。
如果任一處於啓動狀態的檢測器接收到足夠的數據並且達到了很高的可信度，整個自動檢測過程將被終止，同時字符編碼會作爲結果返回。我們稱之爲快捷模式[1]。
3.5 本章小結
本章主要介紹Mozilla字符編碼猜測工具的實現方式：編碼模式方法，字符分佈方法，雙字符序列分佈方法，以及三種方式的綜合。本章的目的在於給出本文實現的一個比較對象，在比較中，說明本文實現的優越性。
第四章 字符編碼猜測實現
4.1 理論背景
對於一段不是隨機出現，而是有實際意義的文本來說，其內部總會有一些關聯。一種很明顯的關聯是各種常用字符的出現頻率總會很高，如對於中文，“的”、“了”之類的出現頻率非常高。如同Mozilla的實現方式一樣，實現中可以統計一些（512個）常用字符的分佈率，然後同理想分佈率比較，得出可靠度，來確定可能的編碼。這種方法的一個缺陷是，它只對那些用兩個字節編碼的語言有效，如GB2312，Big5等，對於單字節的編碼，如ISO-8859-2，就只能用其變通方式，雙字符序列分佈方法。而像UTF-8那樣用不確定字節編碼的，就沒有辦法用該種頻率分析方法了，只能用編碼模式的方法來確定。
這樣，必然帶來了分析程序的複雜性，同時導致了效率的低下。一開始，程序不能夠確定用哪種方式來猜測編碼，必須逐一試用。如先用狀態機探測，接下來用單字符序列分析，接着再雙字符序列分析。當然，可能在狀態機探測時，就能得出了可信的結果，但從平均效率來講，這種方法還是很低效的。
本文的出發點，是去找一種更簡單，效率更好，但同樣可靠的方法來猜測字符編碼—單字節頻率分析。
4.2 噪聲數據
對各種字符編碼進行深入研究後，能夠發現，有一部分代碼點大多數編碼採用同一種形式來表示，那就是ASCII碼0-127部分的代碼點。除了像UTF-16，UTF-32之類的，對那部分代碼作了特殊處理，對於這兩種編碼，本實現目前只能判斷含有BOM的，還有待於擴展。
既然，本文實現所能處理的大部分編碼該部分都相同，那麼一種有效的方式，就是忽略這部分代碼點。本文把這部分代碼點稱爲噪聲數據。當然，這樣還是會忽略一些有效信息的，對於單字節編碼的語言來說，如同Mozilla那樣，可以用雙字節分佈方法，來得到更多的語言信息。在多字節編碼情況下，組成一個字符的多個字節中，屬於ASCII 0-127部分的也會被忽略掉。但在絕大多數情況下，損失的這部分信息是可以忍受的，在可行性分析中，本文將給出數據加以說明。
這樣，本文實現所要做的，就是讀入每一個字節，對於0-127部分的（字節高位是0），直接忽略，記錄的是128-255的部分（字節高位是1）。
需要注意的是，一些編碼所有的字符都是ASCII 0-127部分的，如ISO-2022-CN，ISO-2022-JP，ISO-2022-KR，HZ等，本文實現中需要對這些編碼進行特殊處理，用到的方法是狀態機識別。
4.3 主要算法
既然現在只有128個字節要考慮，本文實現可以方便地記錄每個字節的情況了。這個不同於Mozilla，需要給出512個常用字符，這些字符在轉換成int值後，不一定是連續的。這樣，對於判斷是不是屬於這512個常用字符會有些困難，簡單的方法和高效的辦法難以兩得。但本文實現的128個字符屬於一個連續的區間，這樣就很容易處理了，效率也很高。
主要的思想就是用到了數學統計的方法，本文提供兩種方法，來計算待測文本和各種編碼的關聯度。
方法一：組間差
組間差定義爲：組間差=
方法二：組間方差
這邊的方差，不同於統計學中一般的方差，由本人自己定義，暫稱爲組間方差，定義爲：
組間方差=
表4-1 直線L1
|
X1 |
X2 |
X3 |
X4 |
X5 |
X6 |
|
5 |
10 |
13 |
6 |
2 |
0 |
表4-2 直線L2
|
X1 |
X2 |
X3 |
X4 |
X5 |
X6 |
|
2 |
8 |
12 |
14 |
4 |
2 |
表4-3 直線L3
|
X1 |
X2 |
X3 |
X4 |
X5 |
X6 |
|
3 |
9 |
14 |
7 |
3 |
1 |
應用方法一：L3和L1的組間差=7，L3和L2的組間差=13
應用方法二：L3和L1的組間方差=9，L3和L2的組間方差=56
這兩種方法都說明了L3和L1更相似一些。
這兩種算法相同的地方是，都能得到一個非負值，這個值越小，就說明可信度越高。
從實驗數據來看，兩者的準確率比較相近。但組間差的效率優於組間方差，組間方差要多用到一次乘法。所以，實現中，用到的是組間差。
4.4 實現方法概要
首先需要一些編碼的樣本，這個是本實現花時間最多的地方，很多編碼還找不到。對於一個文本，逐個字節進行分析。因爲絕大部分編碼ASCII碼部分採用相同形式的編碼（UTF-16等除外），所以在分析過程中忽略byte值在0~127之間的部分，對於128-255部分的，記錄每個出現的頻率，記錄進數組（絕對值即爲下標），稱爲出現頻率數組AFA（Appear Frequency Array）。
因爲要猜測的文本的大小是不固定的，所以實現中需要有一個統一的度量來生成AFA。
實現中用到的是單位是：出現次數/一百有效字節。有效字節是指去處噪聲數據後得到的字節數。
對於所有編碼的樣本，計算出每個的出現頻率數組，寫入文件diff.table，組成出現頻率表AFT（Appear Frequency Table）。這張表可以是一開始就給定的，在發佈的版本中不需要給出編碼樣本。diff.table在必要時可以重構，如需要增加或刪除一些編碼時，本程序提供方法來重新構造diff.table。
一些編碼會對應許多不同的語言，如UTF-8，ISO-8859-1等，同一編碼的不同語言間AFA會有些差別，爲更準確的猜測，本文實現對這些編碼按語言進行分類，如UTF-8-cn，表示是中文UTF-8的編碼。（域名和國家的對照表見附錄）
有了AFT，再計算出待猜測文本的AFA，然後與AFT表中的每個AFA進行組間差或組間方差計算，取最小差對應的那個編碼爲猜測結果。
對於編碼：ACSII，ISO-2022-CN，ISO-2022-KR，ISO-2022-JP，所有的byte值都在0~127之間，無法得到AFA。在第一遍對整個樣本的遍歷中，可以得到信息，是否該文件byte值在0~127間，然後進行第二遍遍歷。此時用到的方法是設計一個有窮狀態自動機DFA，依據的是各自的ESC序列：:
ISO-2022-CN : ESC $ ) A
ESC $ ) G
ESC $ * H.
ISO-2022-KR : ESC $ ) C
ISO-2022-JP : ESC $ B
ESC $ @
由ESC序列得到的DFA如圖4-1所示：
4.5 樣本的獲得
本文實現需要大量的樣本，包括許多的測試樣本。這裏所有的樣本都是在Internet上獲得。根據各國的域名來訪問各種網站，如：要訪問法國的網站，則可以搜索www.*.fr。當然，在有一些該編碼的文本後，就可以從中取一些作爲關鍵字搜索，如：用“مروز”來搜索阿拉伯文字。
到達某個網頁後，如何查看編碼？有兩個方法，一個是在頁面源代碼中查找關鍵字“charset”，可能會找到行：<meta http-equiv="Content-Type" content="text/html; charset=utf-8">，說明該頁面是以utf-8爲編碼的。但並不是所有的源代碼中都會提供該關鍵字的。另一個方法，就是使用瀏覽器的功能，在IE中爲菜單：查看->編碼，Firefox中是：查看->字符編碼。Firefox提供的信息會更詳細一些。
如何保存網頁？用複製-粘貼的方法是不可取的，這樣，大部分情況下，這不會以想要的編碼來保存，除非原來的編碼是UTF-8等。需要保存的是整個HTML文件（Ctr-S保存），只有這樣，原始的信息纔不會丟失或轉換成其它格式。但複製-粘貼方式提供了保存UTF-8編碼的一種方式。如，一個網頁若是以EUC-JP編碼的，按此方式保存到文本文件時，選擇以UTF-8爲編碼，這樣就能得到以UTF-8爲編碼的日文樣本了。
4.6 可行性分析
下面，將用一些數據來說明該方法的可行性。所有測試樣本都來自Internet，所有的測試文本都是隨機取得的。本文實現提供了方法，可以批量測試某個文件夾下的所有文件，這樣就能有效提高工作效率。由於時間精力所限，無法進行詳盡的分析，收集的樣本並不是很多。但從這些數據中，可以看出該方法的準確性是很高的。
表4-4是所有編碼應用兩種方法的結果，這裏每個都只測一個文本：
表4-4 所有編碼運用兩種方法得到的統計結果
|
編碼 |
組間差 |
組間方差 |
||
|
最小值 |
次小值 |
最小值 |
次小值 |
|
|
GB2312 |
26 |
77 |
34 |
187 |
|
UTF-8-de |
45 |
72 |
321 |
794 |
|
UTF-8-fr |
38 |
74 |
204 |
1178 |
|
UTF-8-ir |
18 |
125 |
24 |
1286 |
|
UTF-8-it |
85 |
113 |
761 |
1016 |
|
UTF-8-cn |
25 |
94 |
25 |
322 |
|
UTF-8-ru |
26 |
109 |
46 |
1601 |
|
UTF-8-gr |
10 |
113 |
10 |
1160 |
|
UTF-8-no |
19 |
95 |
79 |
1321 |
|
UTF-8-es |
24 |
61 |
52 |
459 |
|
UTF-8-pt |
36 |
71 |
150 |
499 |
|
UTF-8-lt |
37 |
76 |
123 |
731 |
|
UTF-8-pl |
13 |
85 |
19 |
505 |
|
UTF-8-th |
1 |
124 |
1 |
1777 |
|
UTF-8-si |
18 |
79 |
44 |
767 |
|
UTF-8-jp |
41 |
98 |
125 |
932 |
|
UTF-8-il |
8 |
128 |
8 |
2541 |
|
UTF-8-cz |
13 |
86 |
21 |
856 |
|
UTF-8-vn |
24 |
110 |
32 |
782 |
|
UTF-8-tr |
55 |
121 |
379 |
1017 |
|
UTF-8-ro |
82 |
126 |
628 |
1210 |
|
UTF-8-am |
10 |
104 |
10 |
1430 |
|
UTF-8-se |
11 |
54 |
21 |
682 |
|
UTF-8-kr |
13 |
112 |
13 |
507 |
|
Big5 |
33 |
69 |
63 |
164 |
|
Shift-JIS |
22 |
90 |
26 |
1090 |
|
EUC-KR |
28 |
72 |
30 |
166 |
|
EUC-JP |
28 |
80 |
184 |
662 |
|
ISO-8859-1-de |
33 |
105 |
201 |
2225 |
|
ISO-8859-1-fr |
38 |
121 |
238 |
2849 |
|
ISO-8859-1-es |
57 |
97 |
451 |
910 |
|
ISO-8859-1-pt |
37 |
110 |
123 |
768 |
|
ISO-8859-1-se |
30 |
102 |
274 |
2410 |
|
ISO-8859-1-is |
45 |
94 |
365 |
1219 |
|
ISO-8859-1-ge |
17 |
81 |
25 |
393 |
|
ISO-8859-2 |
29 |
101 |
133 |
1164 |
|
ISO-8859-2-pl |
31 |
138 |
117 |
1362 |
|
ISO-8859-2-si |
9 |
139 |
19 |
2833 |
|
ISO- |
32 |
50 |
132 |
298 |
|
ISO-8859-2-ro |
85 |
119 |
1543 |
3299 |
|
ISO-8859-7 |
13 |
80 |
17 |
426 |
|
ISO-8859-9 |
72 |
144 |
704 |
1451 |
|
ISO-8859-10 |
65 |
137 |
1391 |
2331 |
|
Windows-874 |
8 |
81 |
8 |
209 |
|
Windows-1250-cz |
28 |
56 |
102 |
316 |
|
Windows-1250-si |
122 |
136 |
2512 |
2613 |
|
Windows-1251 |
13 |
18 |
17 |
26 |
|
Windows-1255 |
23 |
85 |
41 |
341 |
|
Windows-1256 |
19 |
117 |
51 |
562 |
|
Windows-1257 |
77 |
104 |
637 |
962 |
|
ARMSCII-8 |
16 |
112 |
24 |
594 |
|
KOI8-R |
5 |
73 |
5 |
374 |
表中加粗（紅色）的數據表示猜測錯誤的情況（編碼正確，但猜測語言錯誤），其餘的都是表示猜測正確的情況。所有的編碼都猜測正確了，除了猜測語言會有部分錯誤。這可能是由於這兩種語言非常相近，也有可能是得到的樣本非典型。即使是可能性最高的那個猜測錯誤，第二可能性的都是正確的結果。
組間差的最小值一般在100以內，組間方差在500內。最小值越小，說明可信度越高。次小值指名了第二可能性的編碼。次小值和最小值之間的比例組間差一般超過1.5，組間方差超過3。比例越大，說明可信度越高。
從表中，可以看出準確編碼的差值和最接近準確編碼的那個值差距很大，這個說明了猜測結果是其它錯誤編碼的可能性很小。
這些樣本所含的數據都比較多，所以得到很高的準確率也不足爲奇。若只含有少量的數據，準確率如何呢？下面這些表說明了這個問題。
表4-5到表4-16是兩種方法在不同數據量的情況下各種編碼的準確率情況：
表4-5 猜測GB2312的準確率
|
樣本大小 |
組間差 |
組間方差 |
||
|
|
最小值準確率 |
次小值準確率 |
最小值準確率 |
次小值準確率 |
|
10字符 |
50% |
70% |
70% |
100% |
|
30字符 |
100% |
100% |
100% |
100% |
表4-6 猜測UTF-8-jp的準確率
|
樣本大小 |
組間差 |
組間方差 |
||
|
|
最小值準確率 |
次小值準確率 |
最小值準確率 |
次小值準確率 |
|
10字符 |
90% |
100% |
100% |
100% |
|
30字符 |
100% |
100% |
100% |
100% |
表4-7 猜測UTF-8-ru的準確率
|
樣本大小 |
組間差 |
組間方差 |
||
|
|
最小值準確率 |
次小值準確率 |
最小值準確率 |
次小值準確率 |
|
10字符 |
100% |
100% |
100% |
100% |
|
30字符 |
100% |
100% |
100% |
100% |
表4-8 猜測Windows1251的準確率（和Windows1250-si較相似）
|
樣本大小 |
組間差 |
組間方差 |
||
|
|
最小值準確率 |
次小值準確率 |
最小值準確率 |
次小值準確率 |
|
10字符 |
80% |
100% |
70% |
100% |
|
30字符 |
100% |
100% |
80% |
100% |
表4-9 猜測Big5的準確率（和EUC-JP較相似）
|
樣本大小 |
組間差 |
組間方差 |
||
|
|
最小值準確率 |
次小值準確率 |
最小值準確率 |
次小值準確率 |
|
10字符 |
90% |
100% |
80% |
100% |
|
30字符 |
100% |
100% |
90% |
100% |
表4-10 猜測UTF-8-kr的準確率（和EUC-JP較相似）
|
樣本大小 |
組間差 |
組間方差 |
||
|
|
最小值準確率 |
次小值準確率 |
最小值準確率 |
次小值準確率 |
|
10字符 |
100% |
100% |
100% |
100% |
|
30字符 |
100% |
100% |
100% |
100% |
表4-11 猜測UTF-8-cn的準確率
|
樣本大小 |
組間差 |
組間方差 |
||
|
|
最小值準確率 |
次小值準確率 |
最小值準確率 |
次小值準確率 |
|
10字符 |
100% |
100% |
100% |
100% |
|
30字符 |
100% |
100% |
100% |
100% |
表4-12 猜測UTF-8-ir的準確率
|
樣本大小 |
組間差 |
組間方差 |
||
|
|
最小值準確率 |
次小值準確率 |
最小值準確率 |
次小值準確率 |
|
10字符 |
100% |
100% |
100% |
100% |
|
30字符 |
100% |
100% |
100% |
100% |
表4-13 猜測Shift-JIS的準確率
|
樣本大小 |
組間差 |
組間方差 |
||
|
|
最小值準確率 |
次小值準確率 |
最小值準確率 |
次小值準確率 |
|
10字符 |
50% |
100% |
40% |
40% |
|
30字符 |
90% |
100% |
90% |
100% |
表4-14 猜測UTF-8-fr的準確率
|
樣本大小 |
組間差 |
組間方差 |
||
|
|
最小值準確率 |
次小值準確率 |
最小值準確率 |
次小值準確率 |
|
10單詞 |
100% |
100% |
100% |
100% |
|
30單詞 |
100% |
100% |
100% |
100% |
表4-15 猜測UTF-8-de的準確率
|
樣本大小 |
組間差 |
組間方差 |
||
|
|
最小值準確率 |
次小值準確率 |
最小值準確率 |
次小值準確率 |
|
30單詞 |
90% |
100% |
90% |
100% |
|
60單詞 |
100% |
100% |
100% |
100% |
表4-16 猜測ISO-8859-1-fr的準確率
|
樣本大小 |
組間差 |
組間方差 |
||
|
|
最小值準確率 |
次小值準確率 |
最小值準確率 |
次小值準確率 |
|
10單詞 |
100% |
100% |
100% |
100% |
|
30單詞 |
100% |
100% |
100% |
100% |
表中最小值準確率是指一次性猜碼正確的比率，次小值準確率是最小值和次小值中有一個猜碼準確的比率。
這裏測試的樣本都很小，實際情況的文本數據量都要比這個大多了。樣本大小分爲兩個精度級，字符數和單詞數。對於CJK等象形文字，精度爲字符數，即以每一個文字爲單位。因爲這些編碼ASCII 0-127部分出現的頻率比較少，即噪聲數據較少，所以測試中能用相對較少的數據作爲樣本。但對於法語，德語這些語言，噪聲數據的比例非常大，所以需要相對多一點的數據量，精度爲單詞數。
從這張表能看出，對於極少量的數據（30個字符或單詞），本實現都能有接近100%的準確率，次小值準確率達到了100%。實際情況下的數據量會比這個大的多，這樣，得到的AFA會更接近於理想的AFA，得到的結果就會更準確。對於這些數據，同樣在IE6.0和Mozilla Firefox 1.5中測試過，得到的準確率結果是：
IE6.0<本文實現< Mozilla Firefox 1.5
這些數據表明，這個實現方法是可行的，在實際應用中有很高的準確率。
4.7 與Mozilla的比較
4.7.1 功能
從能夠識別的編碼來說，兩種實現能識別數量相當的編碼。
本文實現能夠識別的編碼：GB-2312，Big5，ISO-2022-CN，EUC-KR，ISO-2022-KR，Shift-JIS，EUC-JP，ISO-2022-JP，ASCII，UTF-8，ISO-8859-1，ISO-8859-2，ISO-8859-7，ISO-8859-9（土耳其），ISO-8859-10（挪威），Windows874（泰國），Windows1250，Windows1251（西里爾語），Windows1255（希伯來語），Windows1256（阿拉伯語），Windows1257（波羅的海），ARMSCII-8（亞美尼亞），KOI8-R（西里爾語）。
Mozilla能夠識別，而本文實現不能識別的編碼：EUC-TW，MacCyrillic，IBM855， IBM866，ISO-8859-5，Windows-1252，Windows-1253，TIS-620 (Thai)。
本文實現能識別，Mozilla不能識別的編碼：ISO-8859-1，ISO-8859-9，ISO-8859-10，Windows874，Windows1256，Windows1257，ARMSCII-8。
不能夠識別的那部分編碼，絕大多數情況是由於在Internet上未能找到該編碼的網頁，缺少樣本，如：EUC-TW，MacCyrillic，IBM855，IBM866，TIS-620 (Thai)，未找到這些編碼的樣本。
本文實現較Mozilla的一大優點在於能夠更精確的定位語言。雖然Mozilla能夠定位一些語言信息，特別是那種一個編碼只對應一種語言的情況，如Shift-JIS一定爲日文，但對於一種編碼對應多種語言的情況，便不能給出語言信息了，如UTF-8，ISO-8859-1（Mozilla中用的是Window1252）。但本實現能夠細化到語言層面，即便是一種編碼對應多種語言，也能知道其具體語言的種類。
本文實現能夠識別的語言：漢語（簡體，繁體），日語，韓語，英語（ASCII），德語，法語，意大利語，土耳其語，挪威語，泰國語，西里爾語（俄語），阿拉伯語，波羅的海語，亞美尼亞語，希臘語，西班牙語，葡萄牙語，波蘭語，斯洛文尼亞語，捷克語，越南語，羅馬尼亞語，瑞典語。
4.7.2 準確率
在可行性分析中，對於較小的數據量，給出了準確性的比較，本實現的準確率小於Mozilla Firefox 1.5。因爲Mozilla運用了多種方法，來確定編碼，而本方法較簡單，忽略了一部分有效信息。但即便是很少的數據，本實現也能達到接近100%的準確率。對於大量的數據，兩者的準確率基本沒有區別，都達到了100%。
4.7.3 效率與複雜性
Mozilla的實現需要用多種方法來判斷字符編碼：編碼模式方法，字符分佈方法，雙字符序列分佈方法。其中編碼模式方法會用到許多的狀態機，而且每個狀態機都會被運行到。
相比之下，本實現只用到兩種方法，單字節分佈法和狀態機識別方法，其中狀態機識別方法中只存在一個狀態機，用來識別ISO-2022編碼和ASCII碼。不同於Mozilla的實現，這裏只需用到其中一種方法，在第一遍掃描樣本後，就能得到信息，確定用哪種方法。計算最小組間差或方差的時間複雜度也是O（n），其中n爲能猜測編碼的總數。AFT是預先生成的，節約了大量的時間。空間複雜度也很小，這裏沒有讀入整張的AFT，而是每次只讀入其中的一個AFA，而Mozilla的實現需要讀入大量的表。
本文實現的複雜性也低於Mozilla。直觀來說，本文實現的代碼量遠低於Mozilla，只有500行左右。Mozilla用到很多狀態機，而本文實現只用到一個。本文實現用的是單字節分佈方法，所有的文本都統一處理，而Mozilla對多字節語言和單字節語言分開處理，並且對於每一種編碼，需要單獨的表。雙字節編碼用512個常用字符，單字節編碼用到64×64的常用雙字節序列表。
4.7.4 擴展性
Mozilla的實現方式具有很大的可擴展性，但這種擴展性是建立在對新加編碼有一定深度瞭解的基礎上。有了這個基礎，才能寫出判別這個編碼的狀態機，才能找出這個編碼常用的字符集。至少從代碼量上來說，會增加許多。
本文實現的擴展比起Mozilla更方便，對於一個新的編碼，只需要有足夠的樣本，即使對它的編碼原理一點都不瞭解，都能夠很方便地加入到本實現所支持的編碼中去。所做的只是在編碼列表中加入該編碼，然後重新生成AFT，存入diff.table即可。這個過程只是增加一行代碼而已。
4.8 本章小結
本章是本文的重點，介紹了本文的實現方式。其中介紹了兩種算法，組間差和組間方差，用來判斷兩種編碼的相似性。在可行性分析中，給出了詳細的數據，來說明本文實現猜測編碼具有很高的準確率。最後是和Mozilla實現的比較，從功能，準確率，效率，複雜性，擴展性等方面來說明本文實現的優越性。
第五章 總結與展望
字符編碼猜測工具在實際中有很廣泛的應用，因爲本地的計算機需要處理多種多樣的編碼。該工具能夠使用戶從繁瑣的手動選擇編碼的過程中解脫出來，從而大大提高了生產效率。
雖然目前已經有了一些該種工具的實現，如Mozilla等，但這些工具一般實現都比較複雜。本文的一大創新是提出了一種簡單的實現該工具的方法，單字節分佈方法和狀態機識別方法的結合。該方法具有很高的準確率，並且比起Mozilla有更高的效率，更好的擴展性，程序也更簡單易懂。該實現能夠判別的編碼種類同Mozilla不相上下，並且在語言識別方面，功能更強大。
本文實現還有一些不完善的地方，如：可以添加可視化的界面，可以增加一些編碼。將來的工作，就是完善這些地方，並推廣這種方法，使之與一些流行的軟件結合，運用到實際中去。
參考文獻
[1] Shanjian Li、Katsuhiko Momoi，中文翻譯來自http://blog.i5un.com/item/21，A composite approach to language/encoding detection，19th International Unicode Conference，November 2002
[2] ASCII碼簡介，http://www.pep.com.cn/200406/ca478658.htm
[3] The ISO 8859 Alphabet Soup，
http://www.unicodecharacter.com/charsets/iso8859.html
[4] ISO Latin 9 as compared with ISO Latin 1，
http://www.cs.tut.fi/~jkorpela/latin9.html#euro
[5] HF. Zhu、DY. Hu、ZG. Wang、TC. Kao、WCH. Chang、M. Crispin，RFC 1922 ： Chinese Character Encoding for Internet Messages，Network Working Group，March 1996
[6] J. Murai、M. Crispin、E. van der Poel，RFC 1468 Japanese Character Encoding for Internet Messages，Network Working Group，June 1993
[7] U. Choii、K. Chon、H. Park，RFC 1557 Korean Character Encoding for Internet Messages，Network Working Group，December 1993
[8] ISO 2022 (Encyclopedia)，
http://www.absoluteastronomy.com/enc3/iso_20222
[9] www.unicode.org
[10] Peter Constable，Understanding Unicode™ A general introduction to the Unicode Standard (Sections 1-5)，Computers & Writing Systems ，June 2001
[11] Markus Kuhn，中國LINUX論壇翻譯小組xLoneStar譯，UTF-8 and Unicode FAQ
[12] Mozilla字符編碼猜測源碼，
http://lxr.mozilla.org/seamonkey/source/extensions/universalchardet/src/base/
[13] Universal Encoding Detector，http://chardet.feedparser.org/docs/
[14] A tutorial on character code issues，http://www.cs.tut.fi/~jkorpela/chars.html
致謝
首先要感謝我的父親和母親，是你們默默地在背後支持我的學業，是你們在我最失意的時候給我以鼓勵，你們是我動力的源泉，我的一切成就都屬於你們。
也要感謝我的導
還要感謝IBM上海CDL的同事們，在將近半年的實習中，我真的學到了很多很多。感謝你們對我的悉心指導，讓我對自己有了新的認識。這段經歷，是我人生的一大筆財富。
感謝我的舍友以及同學。在學習中，你們給了我很多支持與幫助，在生活中，你們給了我很多快樂。
感謝南京大學軟件學院的所有老師，有了你們辛勤的勞動，纔會有我們美好的未來。能在軟件學院學習，真的是我的榮幸，在這裏遇見那麼多的好老師，學到那麼多的知識。
附錄：部分域名國家（地區）對照表
|
域名 |
國家（地區） |
域名 |
國家（地區） |
|
cn |
中國 |
vn |
越南 |
|
tw |
中國臺灣 |
si |
斯洛文尼亞 |
|
hk |
中國香港 |
hr |
克羅蒂亞 |
|
fr |
法國 |
il |
以色列 |
|
de |
德國 |
lr |
利比里亞 |
|
se |
瑞典 |
pl |
波蘭 |
|
is |
冰島 |
jp |
日本 |
|
ru |
俄羅斯 |
kr |
韓國 |
|
ge |
格魯吉亞 |
it |
意大利 |
|
am |
亞美尼亞 |
th |
泰國 |
|
ro |
羅馬尼亞 |
pt |
葡萄牙 |
|
tr |
土耳其 |
cz |
捷克 |
|
ir |
伊朗 |
gr |
希臘 |
|
sy |
敘利亞 |
no |
挪威 |
|
es |
西班牙 |
lt |
立陶宛 |