GB18030/BIG5硬要用utf-8打开的话，肯定会遇到乱码

　　GB18030/BIG5硬要用utf-8打开的话，肯定会遇到乱码

　　本文简化版由OpenCC转换

　　最近在为OpenCC构建图形界面时遇到一个问题：OpenCC默认只能转换utf-8文本。其他编码如 GB18030。 BIG5只能转utf-8后，用OpenCC就可以转了。问题有大有小，也不小。我可以添加一个选项，让用户在打开时选择文本编码，然后进行转换，但这给用户的体验非常糟糕，因为很多非专业用户不知道文本编码是什么，更不用说区分了。向上。如果GB18030/BIG5强制用utf-8打开，肯定会遇到乱码。由于Windows默认为GB18030/BIG5编码，一般情况下文本会被保存为默认编码，大大增加了用户遇到乱码的概率。为了提升体验，我打算实现文本编码的自动检测。

　　我第一次接触编码来自网站。请记住，如果您忘记在头部明确指定浏览器的编码，则经常会出现乱码，但不会总是出现乱码。这是什么？这是怎么回事？浏览器仍然具有自动识别的能力。发现火狐浏览器里有个编码选项，有“自动检测”，大部分时候都能正确识别。

　　实际上，纯文本的编码检测是一个非常复杂的问题，甚至在理论上是不可能的。准确地说，“检测”应称为“检测”或“推测”。自动代码检测的实现原理主要是一种统计方法。每个代码都有一定的特征。首先检查特征是否匹配，然后使用普通匹配，类似于蒙特卡洛方法。具体方法请参考Mozilla。

　　Mozilla 多年前做了一个非常好的代码检测工具，叫做chardet，后来又发布了一个universalchardet，里面有更好的算法，可以在Firefox 中自动识别代码。我想这么有名的工具一定有很多人用过。有趣的是，我在网上找到了chardet和universalchardet的各种移植：

　　唯一缺少的是 C/C++ 接口包。 Debian 甚至收录 有 python-chardet 和 ruby​​-rchardet，但没有 libchardet 或 libuniversalchardet。难道没有使用 chardet 的 C/C++ 应用程序吗？使用强大的谷歌代码搜索，发现确实有，但是几乎所有的chardet代码都嵌入到了项目中，并且耦合度非常接近。更直接调用python-chardet，实现不够纯。

　　我一直觉得应该不是这样，但是经过反复确认，确实没有独立的universalchardet C库包。最好自己做。我从 mozilla 拿了代码，做了一个小补丁，写了一个界面和一个命令行界面，命名为 uchardet，我就完成了。我测试了一些GB18030和UTF8文本，感觉准确率很高，速度也很快。但是当我试图识别几个字节的短文本时，出现了识别错误。一开始我以为是我的错。后来发现我直接用火狐打开了，还是无法识别，错误识别码也是一样。看来是上游问题，应该是算法本身的缺陷。想一想，毕竟文字越短，产生歧义的可能性就越大。不过既然能达到火狐的水平，一般的应用就够了。

　　项目主页位于 Google 代码上：

　　代码在github上：

　　我为什么要使用universalchardet？事实上，自动编码识别的解决方案不止一种。有icu提供的解决方案，IE也有API，还有enca，很多Linux发行版都已经有了。我使用 Universalchardet 因为它是最合适的。 IE 的 API 不能跨平台。 icu的实现太大了。 Enca 是 GPL（注意它不是 LGPL）。使用它意味着我必须对我的所有源代码使用 GPL，而不是更开放的 Apache。 Universalchardet是MPL，LGPL几乎是宽松的，使用没有问题。不太喜欢GPL下发布的函数库，对开发者的限制太大了。

　　上次修改时间 2017-03-16