我有一个文本编辑器，可以加载ASCII和Unicode文件。它通过在文件开头查找BOM和/或在前256字节中搜索字符来自动检测编码。 0x7f的。
应该支持哪些其他编码，以及哪些特性会使编码易于自动检测？
答案 0 :(得分：4)
绝对是UTF-8。请参阅http://www.joelonsoftware.com/articles/Unicode.html。
据我所知，没有保证可以自动检测到这种情况（尽管通过扫描可以将错误诊断的概率降低到很小的数量。）
答案 1 :(得分：3)
我不知道编码，但请确保它可以支持多种不同的行结束标准！ （\ n vs \ r \ n）
如果您尚未查看Mich Kaplan的博客，我建议您这样做：http://blogs.msdn.com/michkap/
具体来说，这篇文章可能很有用：http://www.siao2.com/2007/04/22/2239345.aspx
答案 2 :(得分：1)
您无法检测编码。你能做的最好的事情就是IE，它依赖于不同语言的字母分布，以及语言的标准字符。但这至多是一个长镜头。
我建议您开始使用一些大型字符集库（查看像iconv这样的项目）并将所有这些都提供给用户。但是不要打扰自动检测。只需允许用户选择他对默认字符集的偏好，默认字符集本身就是UTF-8。
答案 3 :(得分：1)
对于检测，大多数编码都无法安全检测到。在某些（如Latin-1）中，某些字节值只是无效。在UTF-8中，可以发生任何字节值，但不是每个字节值序列。但实际上，您不会自己进行解码，而是使用编码/解码库，尝试解码并捕获错误。那么为什么不支持这个库支持的所有编码呢？
您还可以开发启发式算法，例如解码特定编码，然后测试奇怪字符或字符组合或此类字符频率的结果。但这永远不会安全，我同意Vilx-你不应该打扰。根据我的经验，人们通常知道文件具有特定的编码，或者只有两个或三个是可能的。所以，如果他们看到你选错了，他们就可以很容易地适应。并看看其他编辑。最聪明的解决方案并不总是最好的，特别是如果人们习惯了其他程序。
答案 4 :(得分：1)
UTF-16在纯文本文件中并不常见。 UTF-8更常见，因为它与ASCII兼容，并在XML等标准中指定。
1）检查各种Unicode编码的BOM。如果找到，请使用该编码
2）如果没有BOM，检查文件文本是否有效UTF-8，读取直到达到足够的非ASCII样本（因为许多文件几乎都是ASCII但可能有一些重音字符或智能引号）或文件结束。如果有效UTF-8，请使用UTF-8
3）如果不是Unicode，它可能是当前的平台默认代码页
4）有些编码很容易检测，例如日语Shift-JIS会大量使用前缀字节0x82和0x83表示平假名和片假名。
5）如果程序的猜测结果是错误的，请给用户选择更改编码。
答案 5 :(得分：0)
无论你做什么，使用超过256个字节进行嗅探测试。正确的做法很重要，那么为什么不查看整个文档呢？或至少前100KB左右。
尝试使用UTF-8和明显的UTF-16（许多交替的0字节），然后回退到当前语言环境的ANSI代码页。