Monthly Archives: January 2009

我相信大多数中国的程序员都知道unicode对于多语言支持和全球化软件的重要性。但是如果问他们不用unicode会有什么后果，可能大多数人只会说，在某些系统上可能会出现乱码之类的现象。其实这只是一个最浅层次的影响，深层次的影响是什么呢？那就是你的程序根本就不工作，并且需要花很多的人力资源去查找发现并解决这个原本很容易避免的问题的根源。为什么这么说呢？因为我昨天晚上碰到了一个例子。 老婆最近在上课，其中有一门课是远程教育的，你买书，然后安装配套的软件，然后每天根据老师的email看书并在软件上完成作业。听起来很不错？是的，的确是这样子，除非你的软件有问题。 昨天晚上书和配套光盘终于到了，我帮老婆装软件，说实话，这是一个很屎的软件，好像是用director做的，安装程序是wise installer。运行安装程序，提示我安装，没有问题，装完了，没有任何出错提示，要求重启，好吧，重启之后，按照指示去开始菜单里，找到了该软件的快捷方式的子菜单，可是点进去一看，nothing！作为一个IT民工，俺自然想到创建快捷方式的那部分出错了，无所谓，咱是专家啊，直接去安装的目录找exe不就结了。打开安装目录，发现没有想要的可执行程序，但是有一个很可疑的临时文件，一看就知道是安装程序留下的，大小还不小。第一反应就是把它的扩展名修改成exe，果然，图标也出来了，没错，就是这个。看起来一切顺利，运行，没有问题，登录，也没有问题，然而到打开课程的时候报exception了。 因为最近在dogfood windows 7，以为他跟win7不兼容，于是又在我的xp的机器上装了一下，问题依旧。想想我老婆她们班怎么说也有几十号人吧，同样的软件，同样的版本，难道他们就没有遇到这个问题？想来想去，还是觉得安装程序就有问题了，于是又开始用universal extractor把程序的安装包自己解开，发现也没有问题啊，看着里面的内容跟我实际安装的一样。难道是光盘出错，某个字节恰好被搞错了？但是安装包一般都是压缩过的，一个字节出错基本上就不可能解压开了。应该不是这个问题，于是祭起process monitor （原来的File monitor），监视了一下安装程序，打算看看到底那个临时文件是怎么回事儿，个人感觉应该是安装程序重命名这个文件的时候出错了。很快，结果出来了，发现process monitor里面安装进程试图重命名这个文件，但是失败了，原因很简单，它企图重命名的新文件名里有个问号，这在windows的路径里面属于非法字符。 可是为什么呢？这个明显的错误，应该所有人都很容易发现，为什么没有人汇报这个问题呢？难道是我的电脑设置有问题？突然问好让我想起了MultiByteToWideChar里面的comment，对于无法转换的字符，会被替换成“？”！好了，知道原因了：我的系统因为要用网银，而某个银行的傻逼网银软件不支持unicode，所以必须把system locale设置成中文，所以久而久之我就养成了习惯，即便是英文系统，system locale也会在装系统的时候改成中文，肯定是这个原因。于是去控制面板，将其改回英文，重启，重装，一切搞定，再进去，没有任何问题了！ 下面再来分析一下问题吧，猜猜这个软件为它的exe取的文件名是什么？ XXX Pro™5 这里考虑到某些原因我隐藏掉了软件的名字，但是注意名字后面那个TM标志了吗？就是它搞出了问题！如果这一切都是unicode，那么很好，没有任何问题，但是或者这个wise installer不是unicode版本的，他只支持1252 codepage，或者是软件制作人指定名字的时候指定了ANSI version。所以TM标志的编码就是0x99。安装软件rename的时候会调用CreateFileA,也就是ansi版本的createfile，然后传入这个ansi版本的名字。但是系统还是用unicode的，所以系统就会有MultiByteToWideChar来试图把这个转换成unicode，但是MultiByteToWideChar需要一个codepage作为参数，因为这个是non-unicode程序，所以就去了ACP作为参数。ACP怎么解释呢？他就是system locale对应的codepage，在我机器上，就是936，简体中文的codepage。而在这个codepage下面是不存在”\x99\x35”这个组合的，于是MultiByteToWideChar把\x99\x35转换成了一个”?”!   当然问题不止这些，即使我手工把名字改过来，运行后某些地方还是出错，而这一起在system locale是英文的时候没有任何问题，这就说明这个软件本身其他地方还存在类似的问题。