【发布时间】：2011-01-07 10:09:21
【问题描述】：
我有一个可以加载 ASCII 和 Unicode 文件的文本编辑器。它通过在文件开头查找 BOM 和/或在前 256 个字节中搜索大于 0x7f 的字符来自动检测编码。
应该支持哪些其他编码，以及哪些特征可以使该编码易于自动检测？
【问题讨论】：
标签： unicode encoding text-editor character
【发布时间】：2011-01-07 10:09:21
【问题描述】：
绝对是 UTF-8。见http://www.joelonsoftware.com/articles/Unicode.html。
据我所知，没有保证可以自动检测到这一点（尽管通过扫描可以将错误诊断的可能性降低到很小的程度）。
【讨论】：
我不知道编码，但请确保它可以支持多种不同的行尾标准！ (\n 对 \r\n)
如果您还没有查看 Mich Kaplan 的博客，我建议您这样做：http://blogs.msdn.com/michkap/
具体这篇文章可能有用：http://www.siao2.com/2007/04/22/2239345.aspx
【讨论】：
-
两者都支持，不用担心。
-
还有一个 Unicode 行分隔符 U+2028，但是我在野外没见过。
您无法检测编码。你能做的最好的事情就是像 IE 一样，它依赖于不同语言的字母分布，以及一种语言的标准字符。但这充其量只是一个长远的目标。
我建议您使用一些大型字符集库（查看 iconv 等项目）并将所有这些都提供给用户。但不要打扰自动检测。只需允许用户选择他对默认字符集的偏好，默认情况下它本身就是 UTF-8。
【讨论】：
-
嗯，我可以这样做，但我不认为外部库是一种选择。
-
不是外部库。字符编码表。 Unicode 和其他字符集之间的映射。尽管外部库会使转换变得更容易。我确实理解正确，您正在自己编写这个文本编辑器，对吧？
Latin-1 (ISO-8859-1) 及其 Windows 扩展 CP-1252 必须绝对支持西方用户。有人可能会争辩说 UTF-8 是一种更好的选择，但人们通常没有这种选择。中国用户需要 GB-18030，记住除了 UTF-8 编码的 Unicode 之外，还有日本人、俄罗斯人、希腊人都有自己的编码。
至于检测，大多数编码都无法安全检测。在某些（如 Latin-1）中，某些字节值是无效的。在 UTF-8 中，可以出现任何字节值，但不是每个字节值序列。然而，在实践中，您不会自己进行解码，而是使用编码/解码库，尝试解码并捕获错误。那么为什么不支持这个库支持的所有编码呢？
您还可以开发启发式方法，例如对特定编码进行解码，然后测试结果中是否存在奇怪字符或字符组合或此类字符的频率。但这永远不会安全，我同意 Vilx 的观点——你不应该打扰。以我的经验，人们通常知道一个文件有一定的编码，或者只有两个或三个是可能的。所以如果他们看到你选错了，他们可以很容易地适应。并看看其他编辑。最聪明的解决方案并不总是最好的，尤其是当人们习惯了其他程序时。
【讨论】：
-
我用的是wxWidgets，如果我没记错的话，它支持UTF-16和UTF-8。
-
我阅读了文档，并且 wxWidgets 支持很多其他的，比如 UTF-32。请注意，这并不是很常见。
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) 如果程序的猜测结果是错误的，则让用户选择更改编码。
【讨论】：
无论您做什么，都要使用超过 256 个字节进行嗅探测试。做对很重要，所以为什么不检查整个文档呢？或者至少前 100KB 左右。
尝试 UTF-8 和明显的 UTF-16（大量交替的 0 字节），然后回退到当前语言环境的 ANSI 代码页。
【讨论】：
-
点了。但是当文件大于 5 MB 时检查整个文件是荒谬且毫无意义的。
-
我的想法是只支持 UTF-16 和 UTF-8。标准 ASCII 字符在 ASCII 和 UTF-8 中是相同的，其他 128 个字符可能会被忽略。