如何可靠地猜测MacRoman，CP1252，Latin1，UTF-8和ASCII之间的编码

Question

在工作中，似乎没有一周没有编码相关的混乱，灾难或灾难。问题通常来自程序员，他们认为他们无需指定编码就可以可靠地处理“文本”文件。但是你不能。

因此，已决定从此以后禁止文件以*.txt或结尾的文件名*.text。他们的想法是，这些扩展使临时程序员误以为对编码不满意，这会导致处理不当。根本没有扩展将是更好的选择，因为至少您
知道 自己不知道拥有什么。

但是，我们不会走那么远。相反，您将期望使用以编码结尾的文件名。因此，对于文本文件，例如，这些会是这样README.ascii，README.latin1，README.utf8，等。

对于需要特定扩展名的文件，如果可以在文件本身内部指定编码，例如在Perl或Python中，则应这样做。对于像Java源这样的文件，其中文件内部没有这样的功能，您可以将编码放在扩展名之前，例如SomeClass- utf8.java。

对于输出， 强烈建议使用 UTF-8 。

但是作为输入，我们需要弄清楚如何处理代码库中名为的数千个文件*.txt。我们想重命名所有这些以适应我们的新标准。但是我们不可能全都盯着他们。因此，我们需要一个实际起作用的库或程序。

这些格式有ASCII，ISO-8859-1，UTF-8，Microsoft CP1252或Apple
MacRoman。尽管我们知道我们可以判断某些东西是否是ASCII，并且知道有某种东西可能是UTF-8还是很不错的选择，但我们对8位编码感到困惑。因为我们在大多数台式机为Mac的混合Unix环境（Solaris，Linux，Darwin）中运行，所以我们有很多烦人的MacRoman文件。这些尤其是一个问题。

一段时间以来，我一直在寻找一种以编程方式确定哪个

1. ASCII码
2. ISO-8859-1
3. CP1252
4. Mccorman
5. UTF-8

文件在其中，我还没有找到可以可靠地区分这三种不同的8位编码的程序或库。我们可能仅拥有一千多个MacRoman文件，因此我们使用的任何字符集检测器都必须能够将其嗅出。我看过的东西都无法解决这个问题。我对ICU字符集检测器库寄予厚望，但它不能处理MacRoman。我也研究过在Perl和Python中执行相同功能的模块，但是一遍又一遍，它始终是同一回事：不支持检测MacRoman。

因此，我要寻找的是一个现有的库或程序，该程序可以可靠地确定文件所使用的五种编码中的哪一种（最好是更多）。特别是它必须区分我引用的三种3位编码，
尤其是MacRoman 。文件是超过99％的英语文本；还有其他几种语言，但不是很多。

如果是库代码，则我们的语言偏好是按Perl，C，Java或Python的顺序排列。如果它只是一个程序，那么只要它是完整的源代码，在Unix上运行并且完全不受限制，我们就不会真正在意它的语言。

有没有其他人遇到过这样的问题：随机编码成千上万的旧文本文件？如果是这样，您是如何尝试解决它的？您的成功程度如何？这是我的问题中最重要的方面，但是我也很感兴趣您是否鼓励程序员使用文件中的实际编码来命名（或重命名）他们的文件，这将有助于我们将来避免此问题。有没有人曾经尝试过在体制上实施这一措施？如果是
，那是否 成功，为什么？

是的，我完全理解，考虑到问题的性质，为什么不能保证给出确切的答案。对于小文件，尤其是这种情况，因为您没有足够的数据继续运行。幸运的是，我们的文件很少。除了随机README文件外，大多数文件的大小在50k到250k之间，许多文件更大。大小超过K的任何内容都将保证使用英语。

问题领域是生物医学文本挖掘，因此我们有时会处理广泛而又庞大的语料库，例如PubMedCentral的所有Open
Access存储库。相当大的文件是BioThesaurus 6.0，容量为5.7 GB。该文件特别令人讨厌，因为它 几乎
都是UTF-8。但是，我相信有些numbskull会以一些8位编码插入其中的几行，即Microsoft CP1252。您需要花很长时间才能踏上那条路。:(

Answer 1

首先，简单的情况：

ASCII码

如果您的数据不包含大于0x7F的字节，则为ASCII。（或者是7位ISO646编码，但是已经过时了。）

UTF-8

如果您的数据验证为UTF-8，则可以安全地假定它 为 UTF-8。由于UTF-8严格的验证规则，误报极为罕见。

ISO-8859-1与Windows-1252

这两种编码之间的唯一区别是ISO-8859-1具有C1控制字符，而Windows-1252具有可打印字符€，ƒ„…†‡ˆ‰Š‹ŒŽ“”•-〜™š›
œžŸ。我见过很多使用弯引号或破折号的文件，但是没有使用C1控制字符的文件。因此，甚至不必理会它们或ISO-8859-1，而只需检测Windows-1252。

现在只剩下一个问题了。

这要复杂得多。

未定义的字符

Windows-1252中未使用字节0x81、0x8D，0x8F，0x90、0x9D。如果发生这种情况，则假定数据为MacRoman。

相同字符

两种编码中的字节0xA2（¢），0xA3（£），0xA9（©），0xB1（±），0xB5（µ）都相同。如果这些是唯一的非ASCII字节，那么选择MacRoman还是cp1252都没有关系。

统计方法

在您知道为UTF-8的数据中计数字符（不字节！）的频率。确定最频繁的字符。然后使用此数据确定cp1252或MacRoman字符是否更常见。

例如，在我仅对100条随机英语Wikipedia文章执行的搜索中，最常见的非ASCII字符为·•–é°®’èö—。基于这个事实，

• 字节0x92、0x95、0x96、0x97、0xAE，0xB0、0xB7、0xE8、0xE9或0xF6建议使用Windows-1252。
• 字节0x8E，0x8F，0x9A，0xA1、0xA5、0xA8、0xD0、0xD1、0xD5或0xE1表示MacRoman。

计数cp1252建议字节和MacRoman建议字节，并选择最大的一个。