ActiveX是我们在做Web开发使经常使用的浏览器端技术，通过ActiveX控件，Web页面可以实现与计算机本地资源交互，实现特定功能。但实际上ActiveX控件技术是微软自家独有的Web页面扩展技术，它并不包含在W3C制定的HTML标准里面，所以也只有IE或使用IE内核的浏览器才支持它。。究其原因，ActiveX本质上是与Web应用的设计初衷相违背的，它模糊了客户端与服务端的边界，带来安全性、稳定性、兼容性和执行效率等问题。这也是IE在主流浏览器性能排名中总是排在后面的重要原因。但没有办法，由于Windows在桌面操作系统的统治地位，造成了ActiveX成为了事实上的行业标准，ActiveX控件技术一直是Web开发时实现本地资源交互功能的首选技术。
但随着技术和市场的变化，现在开发Web应用时要求支持Chrome等非IE浏览器已经成了标配，而这些浏览器又不支持ActiveX控件，那么需要页面与本地交互时用到有什么方法可以代替呢？今天就根据本人的实际开发经验和大家交流一下。另外，下面谈到的内容还是在桌面使用Windows系统的前提下。
NPAPI或PPAPI
说到上面那个问题，有经验的大神会说用NPAPI或PPAPI啦。没错，NPAPI或PPAPI是指PluginAPI，即插件接口规范。按照这些规范开发的插件，就可以集成在浏览器里，然后Web页面再调用插件的接口，完成相应的功能。NPAPI/PPAPI与ActiveX控件实现的效果类似，但走的技术路线并不同。ActiveX控件修改的是Web页面，而NPAPI/PPAPI实质上通过修改浏览器实现特定的拓展功能。顺便说一下，其实IE也有类似的拓展开发接口。
NPAPI是由网景公司开发的，但因为NPAPI有很大的安全隐患，谷歌在其基础上开发了PPAPI，并且从Chrome52版本后就不再支持NPAPI了。从技术上讲，使用PPAPI貌似应该是最正统的方案，但实际上，目前我看到使用了PPAPI的产品只有Adobe的FlashPlayer，可能是我孤陋寡闻，不过也从一个侧面说明了这项技术至少在国内，用的还是很少。
PPAPI上使用了沙箱技术，插件程序全部运行在沙箱里，在增强安全性的同时也带来了资源消耗的增长。另外，沙箱的诸多安全限制对于做密码应用开发，比如调用USBKey进行数字签名，会造成不小的困难。,而且现在Chrome已经不允许安装非商店的扩展了，也就是说，即使你基于PPAPI开发出了扩展插件程序，也想要上线到谷歌商店才能使用。综合以上几点，除非你的客户有特殊原因或你有一个强大的开发团队，或者你想做Flash这样级别的产品，不推荐使用NPAPI或PPAPI作为ActiveX控件的替代技术。
伪协议
相比高大上的PPAPI，伪协议就很接地气了。它利用浏览器打开HTTP协议的原理，“伪造”一种类似的协议，而这个协议实际上是与本地的某个可执行程序绑定。当浏览器访问以这个协议开头的URL时，就会打开绑定的本地可执行程序，实现页面与本地资源的交互。以一个打开PDF文档的页面为例子，在注册表设置以下键值：
WindowsRegistryEditorVersion5.00
[HKEY_CLASSES_ROOT\pdffile]
URLProtocol=
[HKEY_CLASSES_ROOT\pdffile\shell]
[HKEY_CLASSES_ROOT\pdffile\shell\open]
[HKEY_CLASSES_ROOT\pdffile\shell\open\
联系电话：