一尘不染

字符编码检测算法

java

我正在寻找一种检测文档中字符集的方法。我一直在这里阅读Mozilla字符集检测实现:

通用字符集检测

我还找到了一个名为jCharDet的Java实现:

JCharDet

这两个都是基于使用一组静态数据进行的研究。我想知道的是,是否有人成功使用了其他实现?您是否采用了自己的方法,如果是的话,您用来检测字符集的算法是什么?

任何帮助,将不胜感激。我既不是通过Google寻找现有方法的清单,也不是在寻找Joel Spolsky文章的链接-只是为了澄清一下:)

更新: 我对此进行了大量研究,最终找到了一个名为cpdetector的框架,该框架使用可插拔方法进行字符检测,请参阅:

CPD检测器

这提供了BOM,chardet(Mozilla方法)和ASCII检测插件。自己编写也很容易。还有另一个框架,提供了比Mozilla方法/
jchardet等更好的字符检测功能。

ICU4J

使用该框架为cpdetector编写自己的插件非常容易,该插件可提供更准确的字符编码检测算法。它比Mozilla方法更好。


阅读 265

收藏
2020-09-08

共1个答案

一尘不染

几年前,我们对邮件应用程序进行了字符集检测,然后我们推出了自己的字符集。邮件应用程序实际上是WAP应用程序,而电话期望使用UTF-8。分几个步骤:

普遍

我们可以很容易地检测到文本是否为UTF-8,因为在字节2/3 / etc的高位有一个特定的位模式。一旦发现该模式重复了一定次数,就可以确定它是UTF-8。

如果文件以UTF-16字节顺序标记开头,则可以假设文本的其余部分就是该编码。否则,除非可以检测到代理对模式,否则检测UTF-16几乎不像UTF-8那样容易:但是代理对的使用很少,因此通常不起作用。UTF-32与之类似,只是没有代理对可检测。

区域检测

接下来,我们假设读者在某个地区。例如,如果用户看到的UI本地化为日语,那么我们可以尝试检测三种主要的日语编码。ISO-2022-JP再次位于东部,可以检测转义序列。如果失败,那么确定EUC-
JP和Shift-JIS之间的区别就不那么容易了。用户更有可能收到Shift-JIS文本,但是EUC-JP中的某些字符在Shift-
JIS中不存在,反之亦然,因此有时您可以获得很好的匹配。

中文编码和其他区域使用相同的步骤。

用户的选择

如果这些方法不能提供令人满意的结果,则用户必须手动选择一种编码。

2020-09-08