字符编码检测algorithm
我正在寻找一种方法来检测文档中的字符集。 我一直在阅读这里的Mozilla字符集检测实现：
通用字符集检测
我还发现了一个名为jCharDet的Java实现：
JCharDet
这两个都是基于使用一组静态数据进行的研究。 我想知道的是，是否有人使用任何其他的实现成功，如果是的话？ 你有没有推出自己的方法，如果是的话，你用什么algorithm来检测字符集？
任何帮助，将不胜感激。 我不是在寻找通过谷歌现有方法的清单，也不是在寻找链接到Joel Spolsky的文章 – 只是为了澄清：）
更新：我做了一大堆的研究，并最终find一个名为cpdetector的框架，使用可插入的方法来检测字符，请参阅：
CPDetector
这提供了BOM，chardet（Mozilla方法）和ASCII检测插件。 写你自己的也很容易。 还有另一个框架，它提供了更好的字符检测，Mozilla的方法/ jchardet等…
ICU4J
编写自己的cpdetector插件非常简单，它使用此框架提供更准确的字符编码检测algorithm。 它比Mozilla的方法更好。
几年前，我们有一个邮件应用程序的字符集检测，我们自己推出。 邮件应用程序实际上是一个WAP应用程序，电话预期UTF-8。 有几个步骤：
普遍
我们可以很容易地检测到文本是UTF-8，因为在字节2/3 / etc的最高位有一个特定的位模式。 一旦你发现模式重复了一定的次数，你可以肯定它是UTF-8。
如果文件以UTF-16字节顺序标记开头，则可以假定文本的其余部分是该编码。 否则，检测UTF-16并不像UTF-8那么容易，除非你能够检测到代理对模式：但是使用代理对是很less见的，所以通常不起作用。 UTF-32是相似的，除了没有代理对检测。
区域检测
接下来，我们假设读者在某个地区。 例如，如果用户看到用日语本地化的UI，则可以尝试检测三种主要的日文编码。 ISO-2022-JP再次用东西来检测转义序列。 如果失败了，那么确定EUC-JP和Shift-JIS之间的差别就不那么简单了。 用户收到Shift-JIS文本的可能性更大，但是EUC-JP中的字符在Shift-JIS中不存在，反之亦然，所以有时候可以得到很好的匹配。
中国编码和其他地区使用相同的程序。
用户的select
如果这些没有提供令人满意的结果，则用户必须手动select编码。
不完全是你所要求的，但我注意到， ICU项目包括一个CharsetDetector类。
