越南文处理.docVIP

越南文处理 Unicode入门与剖析——从一个越南文的案例说起 (2011-04-05 11:52:49)转载▼ 标签： 杂谈 分类： 大作 Unicode入门与剖析——从一个越南文的案例说起 写在前面 和大多数人一样，我本来对Unicode也是一知半解。由于从微软的VS2003开始（说起来竟然是8年以前了），Unicode已经是一个默认选项，熟悉的C++语言的char*变成了_TCHAR*，相信大多数人不会去深究其原理，只是将常用的几个字符串函数、基本类型做了相应变化而已。微软已经帮我们做了大量基础工作，大部分情况下并不需要深入研究。 在我不准备把Unicode搞明白的时候，遇到了一件事：我们的项目要移植到越南版本。没想到这个看似不是很难的工作，让我经历了一场有趣的Unicode之旅。 于是，作为总结，写文记录在这里。 一、前奏 我们的项目中用到的所有文本，都有专门的数据文件，按照ID、内容的方式存储起来。翻译时，用???具提取到一个数据库文件中，交给翻译人员逐条翻译。翻译人员直接在数据库中用编辑器进行编辑，完成后再用工具按原有格式写回数据文件，就OK了。这个工具经过了繁体中文版、英文版的检验，功能基本正常。 我们项目的数据文件，由于历史原因，只能是gbk编码，不是Unicode，而数据库里的内容是Unicode的。所以从数据文件到翻译数据库，再从数据库到数据文件，要经历两次转换。因为是Windows环境，首选必然是微软提供的两个函数：MultiByteToWideChar和WideCharToMultiByte。 对英文来说，转换相当的容易，Ascii、UTF8、UTF16之间，转换没有任何问题。中文有简繁体的问题，也就是GBK和BIG5两种编码。两种编码并非一一对应，所以要利用一张汉字对应表进行转换。由于这方面资料非常丰富，所以也没有带来太大的困难。 我们处理越南版时，将中文表格送给翻译人员，翻译人员在数据库中写好了越南语，交给我们。这时候数据库中的越南文字是UTF16编码的，我将它们转换成cp1258编码，也就是微软标准的越南文字符集。（也叫Windows-1258） 这时问题出现了——转换后的文字出现了很多问号“?”。 二、问号代表什么？ 我的第一反应：微软提供的转换接口不应该有问题，问题可能出在字库上。询问了一个在专门做Linux服务器维护的同事，他说应该不是字库的问题。我用了多种编辑器：记事本、火狐、UltraEdit打开了数据文件，确定了那个问号确实是一个问号，Ascii编码0x3F。现在想起来，能联想到字库，也说明我完全没有了解Unicode和字库的关系。 幸运的是，我找对了了解编码的工具——记事本、火狐（或IE）、UltraEdit，编码三剑客，这三者配合，可以很方便的把各种怪异的编码搞清。具体如何使用，后面会说到。 那么问号是如何产生的呢？略去糊涂的中间过程不谈，我认为问题只能出在WideCharToMultiByte函数上！在从Unicode到cp1258的转换时，它并不能正确的工作！ 通过连续不断的baidu和google，我确定了很多人遇到了和我类似的问题。当然很少有人是转换cp1258越南编码时出现问题，因为能搜到专门讨论越南编码问题的网页基本没有。大多数人是在开发Windows CE下的软件时发现问题的。摘录一段百度文库上的资料： 有的朋友可能已经发现,在标准的WinCE4.2或WinCE5.0 SDK模拟器下,这个函数都无法正常工作,其转换之后的字符全是乱码.及时更改MultiByteToWideChar()参数也依然如此. 不过这个不是代码问题,其结症在于所定制的操作系统.如果我们定制的操作系统默认语言不是中文,也会出现这种情况.由于标准的SDK默认语言为英文,所以肯定会出现这个问题.而这个问题的解决,不能在简单地更改控制面板的区域选项的默认语言,而是要在系统定制的时候,选择默认语言为中文. 系统定制时选择默认语言的位置于: Platform - Setting... - locale - default language ,选择中文,然后编译即可. 这说明了什么？在我看来，微软并没有提供一个能在Unicode和本地字符集中任意转换的函数。曾以为输入的几个参数就可以让WideCharToMultiByte按我的意愿工作，这点可能真是一厢情愿了。微软不仅在MSDN的说明中有所保留，而且这个函数的运行结果还和你的系统设置有关。而且令人绝望的——我们用一台电脑装上了英文版Windows，而且还把越南文字有关的组件