字符编码检测算法

Question

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

通用字符集检测

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

JCharDet

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

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

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

CPD检测器

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

ICU4J

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

Answer 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中不存在，反之亦然，因此有时您可以获得很好的匹配。

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

用户的选择

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