【问题标题】:Character Encoding Detection Algorithm字符编码检测算法
【发布时间】:2010-10-20 22:03:10
【问题描述】:

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

Universal Charset Detection

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

JCharDet

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

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

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

CPDetector

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

ICU4J

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

【问题讨论】:

标签: java character-encoding


【解决方案1】:

几年前,我们为邮件应用程序进行了字符集检测,并且推出了自己的。邮件应用程序实际上是一个 WAP 应用程序,而手机需要 UTF-8。有几个步骤:

通用

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

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

区域检测

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

中文编码和其他地区使用相同的程序。

用户选择

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

【讨论】:

  • 我假设您在链接中引用的系统使用的策略与我描述的相似,但希望分享我们的经验会有所帮助。
  • UTF-32 很容易被检测到,因为代码点范围的限制。有效的 UTF-32 代码单元将始终符合模式 00 {0x|10} xx xx(对于 BE)或 xx xx {0x|10} 00(对于 LE)。
  • @JaredOberhaus 你能否展示一些关于第一步的java代码?另外,您将如何为第二步找到正确编码组的项目?
【解决方案2】:

不完全符合您的要求,但我注意到 ICU project 包含一个 CharsetDetector 类。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2016-10-06
    • 2013-04-01
    • 2011-06-16
    • 1970-01-01
    • 2014-01-12
    • 2012-02-29
    • 2010-10-17
    • 1970-01-01
    相关资源
    最近更新 更多