检测 OCR 文档中的乱码文本的最佳方法是什么
有没有好的 NLP 或统计技术来检测 OCR 文本中的乱码？我突然想到，查看文本中 n 元语法的分布可能是一个很好的起点，但我对整个 NLP 领域还很陌生。
这是我到目前为止看到的内容：
文本大部分是英文的，但有一个通用的解决方案会很好。该文本当前已在 Lucene 中建立索引，因此任何基于术语的方法的想法也将很有用。
任何建议都会很棒！谢谢！
Are there any good NLP or statistical techniques for detecting garbled characters in OCR-ed text? Off the top of my head I was thinking that looking at the distribution of n-grams in text might be a good starting point but I'm pretty new to the whole NLP domain.
Here is what I've looked at so far:
- N-gram Statistics in English and Chinese: Similarities and Differences
- Statistical Distributions of English Text
The text will mostly be in english but a general solution would be nice. The text is currently indexed in Lucene so any ideas on a term based approach would be useful too.
Any suggestions would be great! Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，在这种情况下最强大的是 Ngram。您应该将它们收集到相关文本语料库（与您的 OCR 文本具有相同主题）。这个问题与拼写检查非常相似——如果小的字符变化导致很大的概率增加，那么它就是一个错误。检查 本教程如何使用 ngram 进行拼写检查。
Yes, most powerful thing in that case is Ngrams. You should collect them on related text corpora (with same topic to your OCR texts). This problem is very similar to spellchecking - if small character change lead to great probability increase it was a mistake. Check this tutorial how to use ngram for spellchecking.
几年前我使用 n-grams 来做这件事，取得了相当不错的结果。我使用了 Apache Nutch 的语言检测器，它在内部使用单词和词内 n-gram。然后将文本的“ngram-profile”与训练材料的 n-gram 配置文件进行比较。除了语言之外，Nutch 还给出了分数/置信度值，并且我根据语言（应该是文档所在的语言）和分数使用了硬截止。保留了大部分乱码文本，但计算成本较高。
I used n-grams for this some years ago, with pretty decent results. I used Apache Nutch's language detector, that uses word and intraword n-grams internally.Then the "ngram-profile" of your text is compared to n-gram profiles of the training material. Nutch gives a score/confidence value in addition to the language, and I used hard cutoffs based on the language (should be the one the docs are in) and scores. Kept most of the garbeled text out, but it's somewhat computationally costly.