Google Chrome Native Messaging开发实录（一）背景介绍

最近接手了一个针对Google Chrome的需求，最终是使用Native Messaging来实现的。通过这个连载，将把本次开发从方案选定到编码的全部过程进行完整的回顾，并记录开发过程中踩过的各种坑，给首次接触或希望使用chrome插件/扩展技术的朋友，提供一些经验参考。

需求概要是这样，项目本身是一个在线办公的web应用，其中有一个功能模块是刷卡考勤，原来的这个功能仅支持IE浏览器，具体是在某个页面上，通过IE的AtiveX控件，显示出连接在客户机上的IDR读卡器上识别到的卡片的卡号。新的需求要求这个功能要支持Chrome浏览器。

分析一下，目标是让Chrome浏览器通过某个途径，能够达到和在IE浏览器上同样的效果，而已知的条件是磁卡机厂商提供的AtiveX控件。由于这个项目中的磁卡机款式比较老，并不像现在市面上能买到的免驱的设备，电脑通过usb连接马上就识别为HID Device，因此借助驱动和磁卡读卡器通讯是避免不了的。另一个技术关键点是，Chrome本身提供的硬件访问相关API也无法直接和读卡器通讯，那么剩下可选的方案逃不出NaCl和Native Messaging。

接下来先看看NaCl，它确实是一项深受开发者喜爱的技术，在Google大力推动下，ppapi取代npapi成为Chrome唯一的核心插件方式，以往开发过的c/c++的组件和应用尽皆得以保留和web页面交互，它的发布形式也相当丰富，nacl/pnacl甚至都可以通过web服务器获取，和自己的web站点一起部署。遗憾的是，我手上可用的磁卡机的访问组件，是随ActiveX控件一起打包的win32下开发的x86类库，更要命的是没有.h头文件和.lib库，只有一个dll动态库，也就是说，我是需要win32 api的，使用LoadLibrary和GetProcAddress才能调用到dll库中需要的函数，结合NaCl SDK，最合适的方案应该是pepper plugin。但我最后否定了这个方案，原因是Chrome上注册pepper plugin是通过命令行的，而且不是永久生效的，也许是我并没有找到正确的方法，在时间j有限的前提下，我没有深入下去。

NaCl

Pepper Plugin

所以，最后只有祭出Native Messaging这个大杀器了，它的原理很好理解，Chrome的沙箱开辟了一个跨进程通讯的通道，允许Chrome Extension扩展能发送消息给本地任何一个支持stdio的进程，并从这个进程获得响应消息。这个方案对Chrome来说，需要开发一个扩展，对本地来说，需要一个控制台程序或windows service，在时间和难度的考虑下，这就可以接受了。

Native Messaging

后续我将分成几篇分别展示各个部分开发的内容，在本篇结尾，我分享几个资源 ，是我在尝试NaCl方案时，收集到的还不错的资料，因为我也是头一回接触这个，所以类似开发指南和介绍的内容是相当难得的。

1.Google I/O 2012 - Native Client LIVE

2.CEF和PPAPI

3.Google I/O 2012 - Life of a Native Client Instr