一种复合的自动检测语言或编码的方法

来源:互联网 发布:软件开发人员招聘 编辑:程序博客网 时间:2024/05/21 10:22

原文地址:http://www-archive.mozilla.org/projects/intl/UniversalCharsetDetection.html


1. 概述

这篇文章介绍了三种在没有指明字符集的前提下检测文本编码的自动探测方法。我们将讨论这些方法的优点和缺点,并提出一种混合这三种方法的新方法从而提升检测的精度和强度。使用这种方法后,用户将不需要频繁地在浏览器菜单中选择字符编码,而字符编码选择的菜单也最终将很少使用。我们希望字符编码的转换对于用户而言是不可见的,用户不需要知道怎样选择字符编码,因为字符总是正确显示出来的,无论这些字符是一种本地编码还是Unicode 编码。研究出一个好的自动探测服务在这方面是有很大意义的,因为用户可以不用去关注大多数的字符编码问题了。

 

2. 背景

自从计算机时代的来临,人们创建了很多编码规范来显示众多的用来计算的手写符号。随着全球化的趋势以及互联网的发展,跨越区域和语言交换信息显得越来越重要。然而多种多样的编码规范就成了一个主要的障碍。Unicode提供了一种全球化的统一编码标准,但是由于许多原因,它仍然不能完全替换现有的诸多区域编码标准。比如,许多W3C 和IETF 标准要求使用UTF-8 作为默认的编码,例如XML,XHTML,RDF 等。因此,如今的应用程序除了要支持Unicode 之外还需要正确处理其它多种编码方式。

如今大多数工作都在网页浏览器的内容体上进行。人们为了解决网络上多种多样的语言和编码已经付出了非常大的努力。为了能正确显示字符,浏览器只能通过服务器提供编码信息,或者网页本身提供编码信息,或者用户通过编码菜单选择编码信息。不幸的是,实际中编码信息在许多服务器和网页中都无法获取。并且,大多数用户并不知道如何去选择一个正确的编码信息。没有字符集信息,网页最终将显示一堆乱码,用户也将无法正常获取需要的信息。进一步,用户自然而然就会觉得自己用的浏览器一点也不好用。

随着越来越多的互联网标准协议将Unicode 设置为默认编码,互联网最终将走向一个使用Unicode 的时代。一个好的自动探测器可以避免用户使用编码菜单,这必将为互联网走向Unicode 的进程做出极大的贡献。在这个前提下,转换成Unicode 对于网络用户而言将不再痛苦,用户不用做任何事情页面就能正确显示。这样的一个转变可以帮助用户逐渐摆脱字符编码的困扰。自动检测毫无疑问是这个方案的一个重要环节。

 

3. 问题研究

3.1 总体方案

让我们从总体设计开始。对于大多数程序而言,一个通用的自动检测框架如下:

 

输入数据-> 自动探测-> 返回结果

 

应用程序可以将自动探测器获得结果用于很多用途,比如转码,显示,或传递给其它程序等等。

本文中讨论的自动探测方法是以浏览器作为例子的。但是本文所讨论的自动探测方法可以很方便地移植到其它程序中。

 

3.2 浏览器及自动探测

浏览器会用某些算法来自动检测网页的编码。一个程序可以对一段文字用很多种不同的编码进行展示,但是除了某些极个别的情况,页面的作者只希望用其中的某一种编码展示。这就是用户总能看到页面正确显示特定语言的原因。

为了设计自动探测编码的算法,我们对输入文本做出一些假设,以网页为例:

 

1.      输入文本对于读者而言是可读的,它是由一些单词和句子组成的(数据一定是有意义的而不是无用信息)。

2.      输入文本是从互联网上获取的典型的网页(数据不是一些没人用的或者是很古老的语言)。

3.      输入文本中可能包含一些和编码无关的外来干扰信息,比如 HTML 标签,或者非本地词汇(比如中文文档中的一些英文单词),空格或者其它格式控制字符串。

要让自动探测算法支持所有已知的语言和编码几乎是不可能的。在本文中,我们尽可能去支持东亚地区语言中所有流行的编码,同时提供一种通用的模型来处理单字节编码。我们选择俄罗斯语的编码作为后面实现的例子。

4.      多字节编码也在我们考虑的范围内,包括 UTF8,Shift-JIS,EUC-JP,GB2312,Big5,EUC-TW,EUC-KR,ISO2022-XX,HZ。

5.      提供一种通用的模型用来处理单字节编码。俄罗斯语的编码作为实现的例子(KOI8-R,ISO8859-5,window1251,Mac-cyrillic,ibm866,ibm855)。

 

4. 自动检测的方法

4.1 概述

在这一节中,我们将讨论3 种不同的方法来实现对一段文本的编码方式进行探测,这3 种方法分别是:

1) 编码方案法;

2) 字符分布法;

3) 双字符序列分布法。

每种方法都有其强项和弱势之处,但是如果我们将三种方法结合起来,处理结果就会非常令人满意。

 

4.2 编码方案法

这种方法是非常显而易见的方法,并且是在测试多字节编码的时候最常使用的一种方法。在任何一种多字节编码方案中,并不是所有的字节码都被使用了的。如果在测试某一种编码的时候遇到了非法的字节或者字节序列的时候,我们就可以马上把这种字节编码给排除了。有时候一小部分的字节序列可以唯一确定一个编码,如果出现这些序列的话我们就可以马上得出一个准确的结论。FrankTang 研究了一种利用字符编码方案的平行状态机来检测字符编码的非常有效的一种方法。他的主要思路如下:

对于每一种编码方案,都有一个实现判定一个字节序列是否属于该编码的状态机。检测程序会将自己收到的每一个字节分发给每一个可用的活动状态机,每次发一个字节。状态机根据自己原先的状态和收到的字节改变自己的状态。探测程序关心的有以下三种状态:

 

·        开始状态:这是状态机起初的状态,或者是刚检测到一个合法的字节序列的状态。

·        接受状态:这种状态表明状态机成功地识别了一个字节序列为当前状态机所检测的字符编码,并且这个字节流不可能是其它的编码。这个状态可以让检测程序马上返回检测结果。

·        错误状态:这个状态意味着状态机在字节序列中检测到了当前编码中的非法序列。这个状态可以推到出检测的字节序列不可能是当前编码。探测程序将排除这种编码并不再尝试这种编码。

 

在一个典型的例子中,只有一个状态机会返回一个肯定的结果,而其他所有状态机都会返回否定的结果。

当前使用的PSM(平行状态机)是对Frank Tang 研究的方法的一种改进版本。无论什么时候,当一个状态机达到开始状态,就意味着这个状态机检测到一个合法的字符,我们就去查询状态机这个字符占多少字节。这个数据通常有着以下两种用途:

 

·        第一个用途,用于 UTF-8 编码,如果检测到一些多字节字符,那么要检测的字符串就非常不可能是其它的编码了。所以我们需要统计UTF-8 状态机检测出来的多字节字符的个数,当字符数达到一个临界值的时候,就可以认为这个字节流的编码是UTF-8。

·        第二个用途,用于其他多字节编码,匹配字符数需要用于字符分布分析器,详情见下文。

 

4.3 字符分布法

在任何一种给定的语言中,某些字符使用的频率会远远大于其它字符。我们可以利用这个特性来为每一种语言设计一个数据模型。这种方法对于含有大量单字的语言(比如中文,日文和韩文)有着很不错的效果。虽然我们经常听到关于这个分布的传闻,但是从来没有见过任何公开的统计结果。所以,在接下来的讨论中,我们主要依赖于我们自己收集的数据。

 

4.3.1 简体中文

我们统计了GB2312 编码中的6763 个中文字符数据,分布结果如下:

 

出现频率最高的字符数

累积频率

10

0.11723

64

0.31983

128

0.45298

256

0.61872

512

0.79135

1024

0.92260

2048

0.98505

4096

0.99929

6763

1.00000

 

4.3.2 繁体中文

研究基于台湾的国语推行委员会,繁体中文编码是Big5,调查结果和简体中文类似:

 

出现频率最高的字符数

累积频率

10

0.11713

64

0.29612

128

0.42261

256

0.57851

512

0.74851

1024

0.89384

2048

0.97583

4096

0.99910

 

4.3.3 日文

我们自己收集了日文数据,并编写了一个工具来分析结果如下:

 

出现频率最高的字符数

累积频率

10

0.27098

64

0.66722

128

0.77094

256

0.85710

512

0.92635

1024

0.97130

2048

0.99431

4096

0.99981

 

1.00000

                                                                                               

4.3.4 韩文

和日文类似,我们从互联网上搜集了韩文数据并利用我们自己写的工具来统计结果如下:

 

出现频率最高的字符数

累积频率

10

0.25620

64

0.64293

128

0.79290

256

0.92329

512

0.98653

1024

0.99944

2048

0.99999

4096

0.99999

 

4.4 字符分布结果的共同特征

从上面4 种语言的统计结果中,我们发现在我们应用的范围内,很小的一个字符集涵盖了很大的一个显著的百分比。此外,仔细检查那些经常使用的字符编码,可以发现他们分散在一个相当宽的编码范围。这个特性可以帮助我们解决字符编码方案分析器的一些共同问题,比如,不同的国际编码规范可能有着重叠的编码范围。有了上面讨论的字符出现频率集,不同编码重叠的问题在字符分布方法中可能变得微不足道了。

 

4.5 分析算法

有了字符分布频率的统计结果,为了识别一个语言的特性,我们需要一种能够计算输入流分布特性值的算法。这个分布特性值展示了输入字节流属于某一种字符编码的可能性。一种自然的想法就是通过各个字符的出现频率进行加权。但是我们的研究发现,这种做法没有必要,而且这种做法太耗内存和CPU 资源。有一种很简单但是效果也很不错的方法,并且速度更快且占用更少的资源。

在目前的方法中,在一个给定的字符编码的字符集中,所有字符都被分成两类:经常使用的和非经常使用的。如果一个字符在频率分布表的前512 个字符当中,这个字符就被认为是经常使用的字符。之所以选择512 这个数是因为它在4 种语言中都涵盖了一个很显著的累积百分比,却只占用了一小部分的编码。我们统计输入文字的字符在这两类中的字符个数,并将计算得到的浮点值作为分布率(DistributionRatio)。

 

分布率的定义如下:

 

分布率= 出现在经常使用集中的字符个数/ 出现在不常使用集中的字符个数

 

每一个测试过的多字节编码都表现出一个明确的分布率。通过这个分布率,我们可以计算一个随机文本对于一个给定编码的置信等级。下面将通过对各个编码的讨论更清晰地说明这个过程。

 

4.6 分布率和置信等级

接下来,让我们通过4 种语言的数据来比较分布率的不同。注意,我们用分布率这个词来表示两种意思。理想分布率定义在语言字符集上而不是编码上。如果一门语言可以用多种编码来表示,那么对于每一种编码,我们通过将其输入数据按照出现次数进行排序,计算其真实分布率,并将其归类进常使用集和不常使用集中。然后,将这个值与基于语言字符集的理想分布率进行比较。基于这个比较的结果,我们能够对下面描述的输入集计算置信等级。

 

4.6.1 简体中文(GB2312)

GB2312编码包括两种等级的中文字符。等级1包括 3755 个字符,等级2包括 3008 个字符。等级1的使用频率要远高于等级2的使用频率。并且,毫无疑问,最常使用集中的512 个字符都在等级1当中。因为等级1中的字符都按照读音进行了排序,这512 个字符最终散落在3755 个编码上。这些字符占了等级1中字符的13.64%,但是在一篇传统的中文文章中却覆盖了79.135% 的篇幅。在理想的情况下,一段包含足够字符个数的中文文本计算结果应该如下:

 

分布率= 0.79135 / (1-0.79135) = 3.79

 

同时对于一段相同编码的随机文本,如果等级2中的字符没有被用到的话,这个比例应该在512 / (3755-512) = 0.157 左右。

如果考虑到等级2中的字符,我们假设等级1中的字符平均出现概率为p1,等级2的为 p2.那么计算过程如下:

 

512*p1 / (3755*p1 + 3008*p2 - 512*p1) = 512 / (3755 +3008*p2/p1 - 512)

 

很显然,这个值是非常小的,在后面的分析中,我们直接使用最坏结果来作比较。

 

4.6.2 Big 5

Big5 和EUC-TW(比如CNS 字符集)编码有着一段非常相似的历史。Big5编码对于中文字符也有2 个等级。最常用的512 个字符平均地分配在5401 个等级1的字符集中。我们从Big5 编码的文本中计算得到的理想分布率为:

 

分布率= 0.74851 / (1-0.74851) = 2.98

 

同时,对于随机生成的文本其分布率接近于:

 

512 / (5401-512) = 0.105

 

由于Big5 等级1的字符集和CNS 的等级1字符集几乎完全相同,所以EUC-TW 的分析和Big5 是一样的。

 

4.6.3 日语的Shift-JIS 和EUC-JP

对于日语而言,片假名和平假名使用的要比日文汉字要多。由于Shift-JIS 和EUC-JP 将平假名和片假名编码在不同的编码区域,所以我们仍然可以用这种方法来分辨这两种编码。

而那些最常使用512字符中的日文汉字均匀地分布在2965 个JIS 等级1的日文汉字集中。所以,分布率可以用同样的方法进行分析:

 

分布率= 0.92635 / (1-0.92635) = 12.58

 

对于随机生成的日文文本数据,分布率至少为:

 

512 / (2965+63+83+86-512) = 0.191

 

计算值中包括全角片假名(63),平假名(83),片假名(86)。

 

4.6.4 韩语EUC-KR

在EUC-KR 编码中,韩语汉字(中文字符)在实际的韩语文字中使用量是微不足道的。2350个朝鲜文字符是按照其读音进行排序编码的。在频率表中我们通过大量的韩国文字来分析数据,发现最常用的字符集平均分布在这2350 个编码中。使用同样的方法分析,在一个理想的情况下,我们可以得到:

 

分布率= 0.98653 / (1-0.98653) = 73.24

 

对于随机文本,其分布率应该为:

 

512 / (2350-512) = 0.279

 

4.6.5 置信等级计算

通过前面对每种语言文字的讨论,我们可以定义置信等级的计算步骤如下:


置信检测(输入文本){for each 多字节字符 in 输入文本{字符总数++;if (多字节字符 in 512个常用字符集)常用字符数++;}分布率 = 常用字符数 / 字符总数;置信等级 = 分布率 / 理想分布率;return 置信等级;}

 

 

置信等级的值实际上就是输入文本的实际分布率除以前面预先得到的理想分布率计算得到的。

 

4.7 双字符序列分布法

对于一些只使用少量字符的语言,我们要做的不仅仅是计算每个字符出现的次数,我们需要更多能够揭露语言特性的信息。我们定义双字符序列特征,即一个字符紧跟着另一个字符的概率。在这种情况下,这两个字符的顺序也是一个重要的特征。因为一门语言中所有字符使用的频率都不一样,所以双字符序列分布就更能作为决定一门语言的特征。这种特性可以用作语言的判定。这可以更好地检测一个字符的编码,尤其是在检测单字节语言编码的时候。

以俄罗斯语为例。我们下载了大约20MB 的俄罗斯语文本,并编写了一个程序检测这些文本。程序找到了21,199,528 个双字符序列,在我们找到的这些字符序列中,有一些适合我们的研究不相干的,比如,空格-空格 这样的序列。这些序列我们将其当做噪声,并且其分布频率我们并不去考虑它。除去这些序列之后,还剩下20,134,122 个双字符序列,这几乎覆盖了95% 的文中出现的双字符序列。用于我们建立语言模型的序列能被分为4096 个不同的序列,其中有1961 个序列在我们的20,134,122 个样例中出现不到3 次。我们将这1961 个序列称作这门语言的拒绝序列集。

 

4.7.1 置信等级的算法

对于单字节编码的语言,我们定义其置信等级的算法如下:

 

置信等级(输入文本){for each 字符 in 输入文本{if (字符 not in 合法字符集)总字符数++;在频率表中查找这个字符的频率顺序号;if (频率序号 < 样本大小){频率字符数++;if (上个字符不存在){上个字符 = 字符;continue;}if (上个字符 in 样本区域 && 字符 in 样本区域){序列总数++;if (序列(上个字符, 字符) in 拒绝序列集)拒绝序列数++;}}}置信等级 = (序列总数 - 拒绝序列数) / 序列总数 * 频率字符数 / 字符总数;return 置信等级;}


 

上面的算法中,有几点需要解释下:

1.      这个序列分析并没有针对所有字符进行。我们可以建立一个 256 * 256 的矩阵来遍历所有的序列,但是这当中有很多序列和语言编码分析是不相干的,同时也是没必要的。由于大多数的单字节编码语言不会使用超过64 个字母,最常用的字符使用64 个字符几乎就可以完全覆盖所有语言的特性字符。因此,这个矩阵可以减少到64 阶,比原来要小了很多。所以,我们将我们的样本大小设定为64。我们是基于频率统计选择建立模型的64 个字符的,并且允许一些调整。一些字符,比如0x0d 和0x0a,在我们的观点中和空格(0x20)是差不多的,所以在我们的样本中被排除掉了。

2.      对于这个 64 阶模型中,一些序列也是和决定语言编码是不相干的。几乎所有的单字节语言编码都将ASCII 编码作为子集,并且在其它语言中经常可以见到英文单词,尤其是在网页上。同样,很明显空白对对于所有语言编码都没有任何关联。这些序列都被当成噪声而过滤掉。

3.      在计算置信等级的同时,我们也需要计算每个在我们样本空间中的字符的出现次数,而没有出现的不做统计。如果在小样本数据中有大量的字符并没有落到采样区间中,这种情况下,该序列分布可能仍然会返回一个很高的置信等级值,因为这种情况下会发现非常少的拒绝序列。过滤之后,如果测试文本符合当前编码的话,将会有大量的字符落在样本空间,因此计算置信等级所需的拒绝序列需要经过这个数字的调整。

 

总结下前面的内容:

 

·        我们只使用一个子集来进行字符集的识别,这使得我们的模型变小。我们也通过减少噪声来提高检测准确率。

·        每一个语言模型都是通过脚本或工具生成的。

·        对于处理拉丁字母:

o  如果语言没有使用拉丁字母,则字母序列要被当成噪声移除(比如,其他语言的网页中经常会出现英语单词)。

o  如果语言确实使用了拉丁字母,那么这些序列仍然要进行分析。

·        在计算置信等级时同样要使用到落在样本空间的字符数和没有被统计的数量。

 

5. 三种方法的比较

5.1 编码方案法

对于大多数单字节编码,编码使用得非常均匀。虽然这些编码中会有一些不使用的编码,但是这些不使用的编码在其它的编码方案中也几乎是不使用的,这对于编码识别而言是非常不利的。

对于一些多字节编码方案,这种方法就会展现出非常强烈的优势。但是,由于一些多字节编码(比如EUC-CN 和EUC-KR)使用了几乎同样的编码区域,此时采用这个方法就很难区分出这些编码。考虑到浏览器通常获取不到大量的文本信息,我们不得不求助于其它方法来判定字符编码。

对于7 位多字节编码方案,比如ISO-2022-xx 和HZ,这些编码使用了非常容易辨认的偏移序列,通常使用该方法会有比较令人满意的结果。总结一下,编码方案法的特点如下:

 

·        对于 7 位多字节编码方案有着非常好的效果,比如ISO-2022-xx 和HZ。

·        对于某些多字节编码方案比如 Shift-JIS 和 EUC-JP有着很好的效果,但是对于一些其它多字节编码比如EUC-CN 和EUC-KR 效果就不理想。

·        对于单字节编码没有什么效果。

·        能应用于任何文本。

·        非常快速有效。

 

5.2 字符分布法

对于多字节编码,尤其是那些编码方案法无法很好区分的字符编码,字符分布法可以用一种简单的方法达到较好的效果。但是对于单字节编码,由于输入数据量通常不大,并且可能的编码方案太多,除了某些特殊情况外,判定的结果往往不太好。因为双字节分布法可以很好地解决这个问题,所以字符分布法如何处理单字节编码的情况就不再深入研究了。总结起来如下:

 

·        对于多字节编码有着很好的效果。

·        只能用于常规的文本。

·        非常快速有效。

 

5.3 双字符分布法

在这种方案中,我们使用了更多的信息来探测编码,这使得即使在很小的数据样本中也能得到较好的结果。但是由于我们的是序列而不是单词,如果应用于多字节编码的话探测使用的矩阵将会非常大。总结该方法特点如下:

 

·        对于单字节编码非常有效。

·        不适用于多字节编码。

·        即使样本量很小也能获取较好的识别效果。

·        只能应用于常规的文本。

 

6. 一种复合方法

6.1 组合这3 种方法

我们的字符编码探测器想要适用于很多单字节编码和多字节编码。前面列出了这三种的方法的缺点,所以这三种方法没有一种可以真正得到一个令人满意的结果。所以,我们提出了一种复合的方法来同时解决单字节编码和多字节编码。

双字符分布法可以应用于多有单字节编码的检测。编码方案法可以用于UTF-8,ISO-2022-xx和HZ 的检测。在UTF-8 的检测中,对于当前存在的状态机需要有一些小小的改动。UTF-8的检测器在成功识别到一定数量的字符序列之后就可以认为识别成功了。编码方案法和字符分布法都可以用于识别东亚的主要编码,比如GB2312,Big5,EUC-TW,EUC-KR,Shift-JIS,EUC-JP。

对于日文编码,比如Shift-JIS 和EUC-JP,双字符序列分布法也可以使用,因为平假名数量不多,效果就像单字符编码中的字母。双字符分布法可以在小量样本中获得较高的准确率。

我们同时尝试两种方法——使用双字符分布的方法和不使用双字符分布的方法。这两种方法都能得出令人满意的效果。但是仍然存在一些包含大量汉字和片假名但是只包含很少量平假名的网页,为了取得最好的效果,对于日文编码检测,我们同时使用字符分布和双字符分布方法。

下面是一个结合3 种检测方法的例子,最外层的控制模块(自动探测器)的算法如下:

 

字符集自动探测(输入文本){if (all 字符 in 输入文本 is ASCII){if (输入文本 contains ESC 或 偏移序列){调用 ISO-2022 和 HZ 检测代码;if (ISO-2022 或 HZ 检测成功)return 检测成功的编码;elsereturn ASCII;}elsereturn ASCII;}else if (输入文本以 BOM 开头){return UCS2;}else{调用多字节探测器和单字节探测器;return 置信等级最高的字符编码;}}


 

总结下上面的代码段:

 

·        大部分的网页仍然采用 ASCII 进行编码。最外层的算法从 ASCII 编码开始检测。如果所有字符都是ASCII 字符,除了ISO-2022-xx 和HZ 编码以外,没必要再去调用其它编码探测代码。

·        ISO-2022-xx 和 HZ 编码的检测器只有在遇到了 ESC 或偏移序列之后才需要启动,并且一旦遇到一个8 位字节就马上判定为失败。

·        BOM 是用来标记 UCS2 编码的。我们发现一些网站会在 http 流中发送0x00 来标记这个网页是采用UCS2 编码的。

·        如果任何一个活动的探测器收到了足够多的数据并且达到了一个较高的置信水平,整个字符探测程序就会停止继续搜索,并将该探测器的结果作为结果返回。这叫做快照。

 

6.2 测试结果

为了测试本文提出的这些方法,我们测试了100 个主流的网站,这些网站均没有在网页中或者服务器上指明其使用的编码。对于所有探测器支持的编码中,我们达到了100% 的准确率。

比如,我们访问http://www.yahoo.co.jp 这个网站的时候,我们的编码探测器生成了以下的探测结果:

 

[UTF8] is inactive[SJIS] is inactive[EUCJP] detector has confidence 0.950000[GB2312] detector has confidence 0.150852[EUCKR] is inactive[Big5] detector has confidence 0.129412[EUCTW] is inactive[Windows-1251 ] detector has confidence 0.010000[KOI8-R] detector has confidence 0.010000[ISO-8859-5] detector has confidence 0.010000[x-mac-cyrillic] detector has confidence 0.010000[IBM866] detector has confidence 0.010000[IBM855] detector has confidence 0.010000


 

根据以上结果,可以得出结论,这个网站使用的是EUC-JP 编码。

 

7. 结论

混合方法使用编码方案法,字符分布法和双字符序列分布法来来识别语言或者编码,这被证明是一种非常有效的方法。我们检测的目标包括Unicode 编码,多字节编码和单字节编码。这些编码都是互联网上比较具有代表性的编码。而且,有理由相信这种方法同样适用于本文没有提及到的编码。

虽然本文主要讨论的是字符编码的识别方法,但是在大多数情况下,这种方法也可以用来识别语言。事实上,字符分布法和双字符序列分布法都是一种依赖于语言文字特征的识别方法。只有遇到UTF16 和UTF8 的时候,才会遇到检测到编码却无法检测到语言的情况。然而在这种情况下,只需要将本文提出的方法稍微进行扩展就能精确识别,这有待于进一步的研究。

本文提出的方法已经在Netscape 6.1 PR1 中实现,并且后续版本将支持检测所有编码的选项。我们希望我们的研究可以让用户摆脱编码选择的菜单。字符编码菜单(或其它编码菜单)在互联网客户端中和其它界面元素不同,因为它将国际化的后端部分暴露给普通用户了。它的存在反应了当前互联网上的网页在语言和编码的处理上是一片乱七八糟。

我们希望可以提供一个更好的默认编码以及一个全球化的自动探测器可以帮助网友们解决大部分的编码问题。我们支持推行Unicode 编码,尤其是建议将UTF8 作为默认编码。我们希望UTF8 最终能在互联网上广泛使用。这些变化不需要公开,而且越来越多的用户在浏览或阅读发送消息的时候可以从编码相关的问题中解脱出来,这部分要归功于编码自动检测。这就是我们提倡互联网客户端使用良好的默认字符编码设定并且提供良好的自动检测方法的原因。

 

8. 展望

我们的自动探测方法可以识别一门语言。字符编码的探测是语言探测的一个附属成果。对于当前的工作,我们只对单字节编码中的俄罗斯语作为样例进行实现。由于这种编码确定了一种语言,且只在使用这门语言的时候使用它,所以,如果拥有更多的语言模型,也就能有更好的编码检测结果。

要添加其它的单字节编码语言或编码,我们需要一个非常大的样本数据,并且需要对该语言有着一定的了解。目前,我们使用一个脚本来生成一个语言模型。

这项研究目前没有在Mozilla 的源码库中,但是我们希望在最近公开它。当我们公开以后,我们希望有人会在这方面做出贡献。因为我们还没有测试过许多单字节的编码,它们可能引起我们提出的模型进行微调。甚至要修改重新设计方案进而能够应用到其它语言和编码中。


1 0