原文点此查看


            不能打开CHM文件的原因分析及解决方法

  这次重装了Windows系统，心想不应该再有什么问题，没想到居然碰上了
CHM打不开的情况。双击一个中文命名的CHM文件例如“全唐诗.CHM”，弹出
一个对话框：
  “不能打开文件：mk:@MSITStore:F:\全唐诗.chm”

记得以前这种情况也发生过，当时因为事情多，没有功夫理它，只是把
文件名改成英文了事。现在又发生这种情况，一定要把它了结掉。

  我本来想打开的CHM文件应该是“F:\全唐诗.chm”，为什么错误报告中
提到的文件名前面多了一串乱七八糟的“mk:@MSITStore:”？难道系统把我
本来的文件名擅自篡改了吗？必须观察一下系统打开文件的过程。我使用了
工具Filemon(http://www.sysinternals.com/ntw2k/source/filemon.shtml)
来监视系统打开文件的过程，结果发现系统在发出“叮”的一声报告错误之
前试图对以下文件取属性：
  F:\全唐诗.CHI
但是RESULT为“NOT FOUND”。难道它要打开的文件是“全唐诗.CHI”？于是
我把文件的扩展名改成CHI，结果是连文件关联都不存在了，更别说打开了。

  用Filemon没有解决任何问题。看来只好求助于SoftICE来追踪了。我首
先想到的是在CreateFileA这个API上面设个断点，这样好监视系统究竟打开
了什么文件，结果发现系统试图打开一个叫“F:\???.CHM”的文件并且失败
了：

看来问题就在这里了，现在要搞清楚这个“???.chm”究竟是怎么来的，
为什么文件名无端地变成了问号。继续追踪，发现在打开文件之前，系统调
用一个叫WideCharToMultiByte的API把Unicode编码的字符串转化成Ansi字符
串，但是转化的结果却是错误的：

现在错误的关键原因已经找到了，就是WideCharToMultiByte这个API的
调用有问题。查“Win32 Programmer's Reference”手册或者MSDN发现，这
个API的第一个参数是代码页(CodePage)，而这个代码页与Windows的语种有
关。例如简体中文的CodePage是936，繁体中文是950，英文就是1252。仔细
观察上面的跟踪过程，我发现我机器的代码页居然是1252(英文)，而不是简
体中文的936。 这下我明白了，我赶紧打开控制面板，找到“区域设置”一
看，哼唧，竟然是“英语(美国)”。立即把它改成“中文(中国)”，它说要
重新启动，我没理它，不重启。重新打开“全唐诗.CHM”，终于Ok了。

========== The End ==========

最有意思的是这篇文章的思维方式：层层递进的逻辑推理，非常理科～