网页接入硬件交互通信方案

文章介绍了如何使用H5的WebSocket特性,通过封装成WindowsService来实现网页与硬件的通信,以此替代过时的Active-X方案。这种方法通用性强,能适应各种硬件SDK,但也存在端口号占用和额外开发工作量的问题。实际应用中,已成功接入RFID等多种USB硬件设备。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

我们都知道,网页直接接入硬件并与硬件交互并不那么方便,如果硬件有网络功能还可以通过网络通信实现(一般是socket),但大多数情况下硬件还是直接通过usb/串口等硬接线接入。很早以前有一种解决方案是Active-X,但只支持IE浏览器,尤其现在2023年IE已经并入Edge浏览器,这一方案已经过时。那么有没有一种更好更通用的方案可供选择呢?答案是肯定的。

我们都知道H5现在已经非常普遍了,各大浏览器对H5的实现程度已经很高,不用担心不一致的问题。我们可以利用H5里面的WebSocket特性,实现网页与硬件通信。

方案示意图如下:

就是我们的主机既充当WebSocket客户端,也充当WebSocket服务端,不同的是我们把WebSocket服务端封装成了Windows Service。浏览器通过发出WebSocket请求,本机的Windows服务接收到浏览器发出的WebSocket请求之后进行处理(一般是准备对应硬件的操作,这里可以定义双方通信的JSON约定),然后再发出硬件操作的命令,处理完毕后将硬件处理结果通过WebSocket发回浏览器端,这样就完成了整个通信的过程。实现了浏览器端直接操作硬件的功能。

这一方案的优点:

1. 方案通用。不论原有硬件提供什么样的sdk,都可以通过这一方案接入。

2. 实现容易。WebSocket双向通信还是比较方便的。

这一方案的缺点:

1. 占用端口号。WebSocket通信时需要提供一个port,这个port最好不要设置常用的端口号,建议设置一个较冷门的端口。比如12345。

2. 解决方案是迂回的思路,会多很多中转的部分。比如上图中,我们不仅要开发WebSocket Server/Client端,还要开发Windows Service。多一些开发工作量。

通过这一思路,我们实际接入过RFID桌面发卡器(读写)、RFID工业型读写器(群读)、RFID打印机(打印写码)等通过USB接入的硬件并实现网页操作。

当然这里面有一些细节需要进一步处理,比如:监控USB插拔并识别出自己想要连接的硬件,本地WebSocket断线重连,这些问题都有相应的办法可以解决完善。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

全栈极简

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值