Jon*_*Jon 44 java character-encoding
我正在寻找一种方法来检测文档中的字符集.我一直在这里阅读Mozilla字符集检测实现:
我还发现了一个名为jCharDet的Java实现:
这两者都是基于使用一组静态数据进行的研究.我想知道的是,是否有人成功使用过任何其他实现,如果有的话,是什么？你有自己的方法吗？如果是的话,你用来检测字符集的算法是什么？
任何帮助,将不胜感激.我不是在寻找通过谷歌的现有方法列表,也不是在寻找Joel Spolsky文章的链接 - 只是为了澄清:)
更新:我对此进行了大量研究,最终找到了一个名为cpdetector的框架,该框架使用可插入的方法进行字符检测,请参阅:
这提供了BOM,chardet(Mozilla方法)和ASCII检测插件.编写自己的代码也很容易.还有另一个框架,它提供了更好的字符检测,Mozilla方法/ jchardet等......
为cpdetector编写自己的插件非常容易,它使用这个框架来提供更准确的字符编码检测算法.它比Mozilla方法更好用.
几年前,我们对邮件应用程序进行了字符集检测,我们自己推出了.邮件应用程序实际上是一个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中不存在,反之亦然,所以有时你可以得到一个很好的匹配.
中国编码和其他地区使用相同的程序.
用户的选择
如果这些不能提供令人满意的结果,则用户必须手动选择编码.
| 归档时间： |
|
| 查看次数： |
26567 次 |
| 最近记录： |