在工作中，似乎每周都会遇到一些与编码相关的忧虑、灾难或灾难。该问题通常源于程序员认为他们可以在不指定编码的情况下可靠地处理“文本”文件。但你不能。
因此决定从今以后禁止文件名以以下结尾*.txt or *.text。人们的想法是，这些扩展会误导临时程序员对编码感到沉闷的自满，从而导致不正确的处理。最好没有
根本没有扩展，因为至少你know你不知道自己拥有什么。
然而，我们不会走那么远。相反，您将需要使用以编码结尾的文件名。例如，对于文本文件，这些将类似于README.ascii, README.latin1, README.utf8, etc.
对于需要特定扩展名的文件，如果可以在文件本身内部指定编码（例如 Perl 或 Python），那么您应该这样做。对于像 Java 源代码这样的文件内部不存在此类工具的文件，您将把编码放在扩展名之前，例如SomeClass-utf8.java.
对于输出，UTF-8 是strongly首选。
但对于输入，我们需要弄清楚如何处理代码库中名为的数千个文件*.txt。我们想重新命名它们以适应我们的新标准。但我们不可能目击所有这些。所以我们需要一个真正有效的库或程序。
这些格式有多种：ASCII、ISO-8859-1、UTF-8、Microsoft CP1252 或 Apple MacRoman。尽管我们知道我们可以判断某些内容是否是 ASCII，并且我们可以很好地了解某些内容是否可能是 UTF-8，但我们对 8 位编码感到困惑。因为我们在混合 Unix 环境（Solaris、Linux、Darwin）中运行，并且大多数桌面都是 Mac，所以我们有很多烦人的 MacRoman 文件。这些尤其是一个问题。
一段时间以来，我一直在寻找一种方法来以编程方式确定哪些
- ASCII
- ISO-8859-1
- CP1252
- MacRoman
- UTF-8
文件存在，但我还没有找到可以可靠地区分这三种不同 8 位编码的程序或库。仅我们可能就有一千多个 MacRoman 文件，因此无论我们使用什么字符集检测器都必须能够嗅出这些文件。我所见过的任何东西都无法解决这个问题。我对ICU 字符集检测器库，但它无法处理 MacRoman。我还研究过在 Perl 和 Python 中执行相同操作的模块，但一次又一次总是同样的情况：不支持检测 MacRoman。
因此，我正在寻找一个现有的库或程序，能够可靠地确定文件采用这五种编码中的哪一种，最好不止于此。特别是它必须区分我引用的三个 3 位编码，特别是麦克罗曼。文件99%以上是英文文本；其他语言也有一些，但不多。
如果是库代码，我们的语言偏好是 Perl、C、Java 或 Python，并按此顺序。如果它只是一个程序，那么我们并不关心它是用什么语言编写的，只要它有完整的源代码、在 Unix 上运行并且完全不受阻碍即可。
还有其他人遇到过无数遗留文本文件随机编码的问题吗？如果是这样，您是如何尝试解决这个问题的？您的成功程度如何？这是我的问题最重要的方面，但我也想知道您是否认为鼓励程序员使用这些文件的实际编码来命名（或重命名）他们的文件将有助于我们避免将来的问题。有没有人尝试过在制度上强制执行这一点，如果是的话，是that成功与否，为什么？
是的，我完全理解为什么鉴于问题的性质不能保证得到明确的答案。对于小文件尤其如此，因为您没有足够的数据来继续处理。幸运的是，我们的文件很少很小。除了随机README文件的大小大多数在 50k 到 250k 之间，并且许多更大。任何大小超过几 K 的内容都保证是英文的。
问题领域是生物医学文本挖掘，因此我们有时会处理广泛且极其庞大的语料库，例如 PubMedCentral 的所有开放访问存储库。 BioThesaurus 6.0 是一个相当大的文件，有 5.7 GB。这个文件特别烦人，因为它是almost全部为 UTF-8。然而，一些笨蛋在其中插入了一些采用 8 位编码的行——我相信是 Microsoft CP1252。你需要相当长的一段时间才会被那个绊倒。 :(
