简介这是一套新中新二代身份证读卡器的网页插件资源包面向需要在浏览器环境中直接读取身份证芯片信息的开发人员与系统集成方。该控件采用传统OCX与ActiveX技术构建通过IE浏览器或兼容模式访问网页即可触发读卡器取得姓名、性别、出生日期、住址、公民身份号码等核心数据广泛适用于政务窗口、酒店登记、金融业务、网上报名等身份核验场景。压缩包共收录17个文件整体大小约2.92MB主要包含dll动态库、exe安装与配置程序、htm测试页面、cab和ocx控件文件、inf驱动配置文件以及sed与dat数据文件足以支撑插件注册、驱动部署和网页调用联调。目前已有1177人学习或下载这套资源。借助包内控件文件、示例页面与SDK动态库读者可快速搭建本地的身份证读取演示环境并理解从控件注册、浏览器安全设置到前端脚本通信的完整链路同时能够借鉴其在兼容性、安全性、隐私保护方面的处理思路为后续集成或迁移改造提供参考。 做了这么多年系统集成我隔三差五就会碰到有人问新中新二代身份证读卡器怎么在网页里调。搜出来的资料要么是十年前的老博客要么是厂商文档里语焉不详的几行说明照着做经常卡在半路。这玩意儿本身不难但坑确实不少尤其是“网页”这两个字直接把一大半传统方案堵死了。这篇把我实际对接过的路线、代码思路和踩过的坑一次说清楚给正在做酒店前台、访客登记、政务窗口这类系统的朋友省点时间。1. 先搞清楚读卡器的数据通路不是即插即用那么回事很多人拿到读卡器插上USB装了驱动然后打开浏览器就懵了——网页里什么都没有。这不是你操作问题而是从一开始就走错了方向。二代身份证读卡器虽然外观各异但工作逻辑基本一致读卡器硬件负责读取身份证内的芯片信息然后通过USB有的走串口协议有的走USB-HID把密文数据传给上位机上位机再通过厂商提供的SDK动态库进行解密、解析最终拿到姓名、身份证号、住址、照片这些明文信息。也就是说读卡器本身不直接输出“姓名张三”这种数据。它输出的是密文或者结构化数据块真正的解码工作靠的是SDK里的DLL文件。以新中新为例厂商通常会提供一套基于C/C或C#的SDK包里面有几个核心的DLL常见的有sdtapi.dll这类命名不同型号略有差异开发者调用里面的接口函数传端口号、传缓冲区指针然后从结构体里取结果。这里就有个核心矛盾了浏览器里的JavaScript是没有权限直接加载本地DLL的。现代浏览器的沙箱模型里页面最多通过WebUSB这类新兴API访问底层硬件但前提是设备固件支持相应的协议。国内身份证读卡器绝大多数不会去兼容WebUSB标准所以指望纯前端搞定不现实。所谓“网页插件”本质上是要在你的网页和本地读卡器SDK之间搭一条桥。这条桥通常有三种搭法ActiveX控件老掉牙但曾经遍地都是、本地WebSocket服务我现在的主力方案、以及浏览器原生扩展极少用维护成本高。下面挨个说尤其是后两种很多人混淆得厉害。2. 三种网页对接路线哪条路能走哪条路是死胡同2.1 ActiveX控件路线兼容性灾难五到十年前市面上几乎所有身份证读卡器的网页调用方案都是ActiveX。厂商给一个ocx控件你在HTML里用object标签引入然后JavaScript里直接new一个控件实例调用它的方法。这套方案在IE浏览器时代确实好用但今天基本属于自找麻烦。首先Chrome、Firefox、Edge现代版本全线不支持ActiveX微软自家的Edge从Chromium内核开始也彻底砍掉了。你只能要求客户用IE11或者Edge的IE模式还得在浏览器设置里把站点加入兼容性视图列表、启用ActiveX筛选放行客户现场的电脑只要设置稍微不对整个功能就哑火。更麻烦的是ActiveX控件需要在每台客户机上手工注册regsvr32Windows 10以后的系统对ActiveX默认限制越来越严格64位系统和32位控件的兼容性又是一堆幺蛾子。我这几年新做的项目已经完全不碰ActiveX了除非是纯内网、客户坚持用老IE的老旧项目否则别选这条路。它看起来是“网页插件”最正统的答案其实是维护成本最高的那个。2.2 本地WebSocket中转服务当下最平衡的方案既然浏览器不能直接调DLL那就让一个本地程序去调DLL把结果通过WebSocket发给网页。这个本地程序可以是一个控制台程序、Windows服务或者干脆是一个开机自动启动的小工具。网页JavaScript通过WebSocket的ws://127.0.0.1:端口号去连本地服务发指令过去服务解析后把结果返回给网页。这条路的优势非常明显浏览器兼容性几乎为零要求Chrome、Firefox、Edge、国产双核浏览器的极速模式全部通吃。部署上只需要把本地服务程序装到客户机上不需要注册控件不需要管理员权限反复确认。网页端代码也不用处理复杂的协议就是一个WebSocket收发JSON简单直接。如果说缺点那就是每一台客户端电脑上都需要装这个本地服务。但对于读卡器这种本身就需要装驱动的硬件来说多装一个配套服务程序完全在可接受范围内。而且这个服务可以和驱动一起打包做成一键安装体验已经很接近传统桌面软件了。2.3 WebUSB直连方案看起来很美好实际很骨感Chrome从Chrome 61开始支持WebUSB API允许网页直接和USB设备通信。新一些的读卡器型号尤其是那些硬件本身支持USB-HID免驱方案的理论上网页可以绕过本地服务直接通过navigator.usb.requestDevice()申请设备访问权限然后发送命令、读取数据。为什么我说“理论上”因为实际跑起来有几个问题。第一WebUSB要求浏览器弹出设备授权窗口用户必须手动选择并点击连接这个操作在不需要安装任何软件的愿景下还算能接受但身份证读卡器返回的是经过加密的数据块解密算法在DLL里WebUSB拿到密文之后没有DLL可调还是得想办法在JavaScript里实现解密——而厂商基本不会把解密算法完整公开。第二部分读卡器走的是串口协议电脑上表现为一个虚拟串口WebUSB对串口设备支持很弱你得自己实现串口驱动协议栈复杂度直线上升。所以结论很明确WebUSB在某些国外标准的智能卡读写器上有戏但在国内身份证读卡器这个生态里至少现在还不是一条通用路径。做项目选方案别拿WebUSB当主力容易把自己坑进去。我整理了一个表方便直接对照方案浏览器适配部署复杂度维护成本适用场景ActiveX控件IE/Edge IE模式高需注册控件高老系统改造本地WebSocket服务所有现代浏览器中需安装服务本文还有配套的精品资源点击获取
简介这是一套新中新二代身份证读卡器的网页插件资源包面向需要在浏览器环境中直接读取身份证芯片信息的开发人员与系统集成方。该控件采用传统OCX与ActiveX技术构建通过IE浏览器或兼容模式访问网页即可触发读卡器取得姓名、性别、出生日期、住址、公民身份号码等核心数据广泛适用于政务窗口、酒店登记、金融业务、网上报名等身份核验场景。压缩包共收录17个文件整体大小约2.92MB主要包含dll动态库、exe安装与配置程序、htm测试页面、cab和ocx控件文件、inf驱动配置文件以及sed与dat数据文件足以支撑插件注册、驱动部署和网页调用联调。目前已有1177人学习或下载这套资源。借助包内控件文件、示例页面与SDK动态库读者可快速搭建本地的身份证读取演示环境并理解从控件注册、浏览器安全设置到前端脚本通信的完整链路同时能够借鉴其在兼容性、安全性、隐私保护方面的处理思路为后续集成或迁移改造提供参考。 做了这么多年系统集成我隔三差五就会碰到有人问新中新二代身份证读卡器怎么在网页里调。搜出来的资料要么是十年前的老博客要么是厂商文档里语焉不详的几行说明照着做经常卡在半路。这玩意儿本身不难但坑确实不少尤其是“网页”这两个字直接把一大半传统方案堵死了。这篇把我实际对接过的路线、代码思路和踩过的坑一次说清楚给正在做酒店前台、访客登记、政务窗口这类系统的朋友省点时间。1. 先搞清楚读卡器的数据通路不是即插即用那么回事很多人拿到读卡器插上USB装了驱动然后打开浏览器就懵了——网页里什么都没有。这不是你操作问题而是从一开始就走错了方向。二代身份证读卡器虽然外观各异但工作逻辑基本一致读卡器硬件负责读取身份证内的芯片信息然后通过USB有的走串口协议有的走USB-HID把密文数据传给上位机上位机再通过厂商提供的SDK动态库进行解密、解析最终拿到姓名、身份证号、住址、照片这些明文信息。也就是说读卡器本身不直接输出“姓名张三”这种数据。它输出的是密文或者结构化数据块真正的解码工作靠的是SDK里的DLL文件。以新中新为例厂商通常会提供一套基于C/C或C#的SDK包里面有几个核心的DLL常见的有sdtapi.dll这类命名不同型号略有差异开发者调用里面的接口函数传端口号、传缓冲区指针然后从结构体里取结果。这里就有个核心矛盾了浏览器里的JavaScript是没有权限直接加载本地DLL的。现代浏览器的沙箱模型里页面最多通过WebUSB这类新兴API访问底层硬件但前提是设备固件支持相应的协议。国内身份证读卡器绝大多数不会去兼容WebUSB标准所以指望纯前端搞定不现实。所谓“网页插件”本质上是要在你的网页和本地读卡器SDK之间搭一条桥。这条桥通常有三种搭法ActiveX控件老掉牙但曾经遍地都是、本地WebSocket服务我现在的主力方案、以及浏览器原生扩展极少用维护成本高。下面挨个说尤其是后两种很多人混淆得厉害。2. 三种网页对接路线哪条路能走哪条路是死胡同2.1 ActiveX控件路线兼容性灾难五到十年前市面上几乎所有身份证读卡器的网页调用方案都是ActiveX。厂商给一个ocx控件你在HTML里用object标签引入然后JavaScript里直接new一个控件实例调用它的方法。这套方案在IE浏览器时代确实好用但今天基本属于自找麻烦。首先Chrome、Firefox、Edge现代版本全线不支持ActiveX微软自家的Edge从Chromium内核开始也彻底砍掉了。你只能要求客户用IE11或者Edge的IE模式还得在浏览器设置里把站点加入兼容性视图列表、启用ActiveX筛选放行客户现场的电脑只要设置稍微不对整个功能就哑火。更麻烦的是ActiveX控件需要在每台客户机上手工注册regsvr32Windows 10以后的系统对ActiveX默认限制越来越严格64位系统和32位控件的兼容性又是一堆幺蛾子。我这几年新做的项目已经完全不碰ActiveX了除非是纯内网、客户坚持用老IE的老旧项目否则别选这条路。它看起来是“网页插件”最正统的答案其实是维护成本最高的那个。2.2 本地WebSocket中转服务当下最平衡的方案既然浏览器不能直接调DLL那就让一个本地程序去调DLL把结果通过WebSocket发给网页。这个本地程序可以是一个控制台程序、Windows服务或者干脆是一个开机自动启动的小工具。网页JavaScript通过WebSocket的ws://127.0.0.1:端口号去连本地服务发指令过去服务解析后把结果返回给网页。这条路的优势非常明显浏览器兼容性几乎为零要求Chrome、Firefox、Edge、国产双核浏览器的极速模式全部通吃。部署上只需要把本地服务程序装到客户机上不需要注册控件不需要管理员权限反复确认。网页端代码也不用处理复杂的协议就是一个WebSocket收发JSON简单直接。如果说缺点那就是每一台客户端电脑上都需要装这个本地服务。但对于读卡器这种本身就需要装驱动的硬件来说多装一个配套服务程序完全在可接受范围内。而且这个服务可以和驱动一起打包做成一键安装体验已经很接近传统桌面软件了。2.3 WebUSB直连方案看起来很美好实际很骨感Chrome从Chrome 61开始支持WebUSB API允许网页直接和USB设备通信。新一些的读卡器型号尤其是那些硬件本身支持USB-HID免驱方案的理论上网页可以绕过本地服务直接通过navigator.usb.requestDevice()申请设备访问权限然后发送命令、读取数据。为什么我说“理论上”因为实际跑起来有几个问题。第一WebUSB要求浏览器弹出设备授权窗口用户必须手动选择并点击连接这个操作在不需要安装任何软件的愿景下还算能接受但身份证读卡器返回的是经过加密的数据块解密算法在DLL里WebUSB拿到密文之后没有DLL可调还是得想办法在JavaScript里实现解密——而厂商基本不会把解密算法完整公开。第二部分读卡器走的是串口协议电脑上表现为一个虚拟串口WebUSB对串口设备支持很弱你得自己实现串口驱动协议栈复杂度直线上升。所以结论很明确WebUSB在某些国外标准的智能卡读写器上有戏但在国内身份证读卡器这个生态里至少现在还不是一条通用路径。做项目选方案别拿WebUSB当主力容易把自己坑进去。我整理了一个表方便直接对照方案浏览器适配部署复杂度维护成本适用场景ActiveX控件IE/Edge IE模式高需注册控件高老系统改造本地WebSocket服务所有现代浏览器中需安装服务本文还有配套的精品资源点击获取
