Html HTML5 可以与扫描仪和信用卡读卡器等外围设备通信吗？

Can HTML5 communicate with peripherals like scanners and credit card readers?

提问by Daniel Szabo

My company writes software that installs on client machines to perform point-of-sale transactions. The software interfaces with a variety of external peripherals (receipt printers, bar code scanners, credit-card readers, etc). We do this with a WinForms app that we created in Visual Studio using the Microsoft OPOS library, which in turn communicates with our cloud server.

我的公司编写的软件安装在客户端机器上以执行销售点交易。该软件与各种外围设备（收据打印机、条码扫描仪、信用卡阅读器等）连接。我们使用 Microsoft OPOS 库在 Visual Studio 中创建的 WinForms 应用程序执行此操作，该应用程序又与我们的云服务器进行通信。

There are obvious inefficiencies in this model, primarily with updates. I'm researching other ways to communicate with these peripherals over the web, preferably via web browser. So far as I can tell, Java is one of the only technologies out there that can do what we're looking for (via applet), and I assume Adobe Flash can as well (via the Air platform). These are viable, but not preferable because we want to run our software on web-enabled mobile devices.

该模型存在明显的低效率，主要是更新。我正在研究通过网络与这些外围设备进行通信的其他方式，最好是通过网络浏览器。就我所知，Java 是仅有的可以做我们正在寻找的事情的技术之一（通过小程序），我认为 Adob​​e Flash 也可以（通过 Air 平台）。这些是可行的，但不是可取的，因为我们希望在支持 Web 的移动设备上运行我们的软件。

Does anybody have suggestions for other ways to communicate with external peripherals over the web?

有人对通过网络与外部外围设备进行通信的其他方式有什么建议吗？

回答by LoveAndCoding

UPDATE (Jan 16th, 2019):The Credential Management APIhas been announced. It's currently only supported on Chrome and Operabut it's looking promising. Google Developers wrote an articleelaborating on the spec.

UPDATE（2019年1月16日）：该凭证管理API已经公布。它目前仅在 Chrome 和 Opera 上受支持，但看起来很有希望。Google Developers 写了一篇文章详细阐述了该规范。

UPDATE (Dec 28th, 2016):Another couple years gone, and another update. This one will be more focused on two new developments than anything else. See the new "WebUSB & Web BlueTooth" section under "Full Device API". But the answer remains the same.

更新（2016 年 12 月 28 日）：又过了几年，又是一次更新。这将比其他任何事情都更专注于两个新的发展。请参阅“完整设备 API”下的新“WebUSB 和 Web 蓝牙”部分。但答案是一样的。

UPDATE (Nov 3rd, 2014):It's been just over two years since the original post was made, but the answer remains mostly the same for now. We are, however, closer to your original goal in several areas.

更新（2014 年 11 月 3 日）：距离最初的帖子发布已经过去了两年多，但现在答案基本相同。然而，我们在几个方面更接近您最初的目标。

ORIGINAL ANSWER:

原始答案：

There would be a number of ways to go about this.

有很多方法可以解决这个问题。

Background

背景

The HTML5 specification has entered into the "Recommendation" state. This means that HTML5 is pretty much set for what it looks like. However, I will be using HTML5 in the same way that every marketing person in the world has decided is best. That is, I will not be talking about HTML. Well, I will, in so far as you will utilize it from an HTML page, but not really. What I'll actually be discussing is JavaScript (JS) and that's a horse of a different color. But for all intents and purposes, we're putting it all under the same heading as HTML5, which has been decided to mean "shiny and new" now.

HTML5 规范已进入“推荐”状态。这意味着 HTML5 几乎已经设置好了。但是，我将按照世界上每个营销人员都认为最好的方式来使用 HTML5。也就是说，我不会谈论 HTML。好吧，就您将从 HTML 页面使用它而言，我会，但不是真的。我实际上要讨论的是 JavaScript (JS)，这是一匹不同颜色的马。但出于所有意图和目的，我们将其全部放在与 HTML5 相同的标题下，现在已决定它的意思是“闪亮的和新的”。

Also, the items which I am discussing will vary in support. Some are very browser dependent projects (like Chromium specific implementations), and some are more standards driven projects that may not have browsers implementing or experimenting with them yet. I'll try to distinguish between the two as I go along.

此外，我正在讨论的项目在支持方面会有所不同。有些是非常依赖于浏览器的项目（比如 Chromium 特定的实现），有些是更多标准驱动的项目，可能还没有浏览器实现或试验它们。随着我的进展，我将尝试区分这两者。

Full Device API

完整的设备 API

Status: Incoming, but not ready

状态：传入，但未准备好

Being able to access devices from the browser is making slow but steady progress. Right now, many modern browsers have access to some of the more common devices like the cameraor gamepads, but they are all high level APIs. Browser vendors, the standards groups, and lots of companies involved with the web are all trying to make webapps just as powerful as your local applications.

能够从浏览器访问设备正在取得缓慢但稳定的进展。现在，许多现代浏览器可以访问一些更常见的设备，例如相机或游戏手柄，但它们都是高级 API。浏览器供应商、标准组织和许多与 Web 相关的公司都在努力使 Web 应用程序与您的本地应用程序一样强大。

But the APIs you are looking for are still in progress and a ways off. For your particular case, and for the more general case of connecting your webapp to most devices, we're still a few years away from something we can use. If you want to see what awesome things are coming up in that field, here are just a select few items that may help you directly:

但是您正在寻找的 API 仍在进行中，而且还有很长的路要走。对于您的特定情况，以及将您的 web 应用程序连接到大多数设备的更一般情况，我们距离可以使用的东西还有几年的时间。如果您想了解该领域有哪些很棒的事情发生，这里只是一些可以直接帮助您的精选项目：

• Web Near Field Communication (NFC) API
  This one unfortunately may be dead in the water for now. But it looks like originally some folks at the W3C (mostly Intel it looks like) were looking at adding a NFC API to the web.
• Media Capture Streams
  The WebRTC group is working on programmatic access to media streams like the camera which would allow to integrate things like barcode scanning or other features. This has reached CR status and is available in browsers, but is less helpful on its own.
• Web Bluetooth
  If you had bluetooth capable tools, this API would help you connect with them from computers and devices that were able to listen and connect. The primary driver for this at the moment seems like it is the Chrome team, including an experimental implementation, but I wouldn't consider it anywhere ready to use yet (See "WebUSB & Web BlueTooth" section).
• WebUSB
  This would allow full access to low level USB information including listing devices and interacting with them. Same as Web BlueTooth, this seems to be current Chrome pet project, but I also wouldn't rely on it (See "WebUSB & Web BlueTooth" section).
• Network Service Discovery
  If you have other devices or items on the network which broadcast and use HTTP, this API would allow you to discover and interact with these services. No browser implementation, but it is in a working draft for the W3C.

• 网络近场通信 (NFC) API
  不幸的是，这个API现在可能已经死了。但看起来最初 W3C 的一些人（看起来主要是英特尔）正在考虑向网络添加 NFC API。
• 媒体捕获流
  WebRTC 小组正在致力于以编程方式访问媒体流，例如相机，这将允许集成诸如条形码扫描或其他功能之类的东西。这已达到 CR 状态并可在浏览器中使用，但其本身的帮助较小。
• 网络蓝牙
  如果您有支持蓝牙的工具，此 API 将帮助您从能够收听和连接的计算机和设备上连接它们。目前的主要驱动力似乎是 Chrome 团队，包括一个实验性的实现，但我不认为它可以在任何地方使用（请参阅“WebUSB 和 Web 蓝牙”部分）。
• WebUSB
  这将允许完全访问低级 USB 信息，包括列出设备并与它们交互。与 Web BlueTooth 相同，这似乎是当前的 Chrome 宠物项目，但我也不依赖它（请参阅“WebUSB 和 Web BlueTooth”部分）。
• 网络服务发现
  如果网络上有其他设备或项目广播和使用 HTTP，则此 API 将允许您发现这些服务并与之交互。没有浏览器实现，但它在 W3C 的工作草案中。

Originally, Mozilla was pushing a number of these forward because of Boot2Gecko (or Firefox OS). However, with that project officially cancelled, we aren't seeing much progress from them in these areas now.

最初，由于 Boot2Gecko（或 Firefox OS），Mozilla 正在推动其中一些向前发展。然而，随着该项目正式取消，我们现在在这些领域看不到太多进展。

Members of the Chrome team, however, seem to have decided to dive in and start not only working towards these, but putting them live in browsers. Which leads us to...

然而，Chrome 团队的成员似乎已经决定深入研究并开始不仅致力于这些，而且将它们放在浏览器中。这导致我们...

WebUSB & Web BlueTooth

网络USB和网络蓝牙

Like sausages, it's better to not know how Web Standards are made
-Abraham Lincoln (probably)

就像香肠一样，最好不知道 Web 标准是如何制定的
-Abraham Lincoln（可能）

There's been a little bit of buzz in this area as it looks like the Chrome team snuck in these as experimental features and developed their own specification for it. Which is great! Just maybe not in the way that you were hoping for.

在这个领域有一些嗡嗡声，因为看起来 Chrome 团队偷偷地将这些作为实验性功能并为其开发了自己的规范。这很棒！只是可能不是您希望的方式。

Each browser vendor and W3C contributor group has their own style and makes contributions towards the specs in their own way. The result is usuallya fairly decent specification that the browsers have agreed upon. But getting from nothing to something is... messy. Real messy. And is quite a process a lot of times. It doesn't always result in a good spec (yeah, I'm talking about you Florian compromise...) but even when it does, it takes a while.

每个浏览器供应商和 W3C 贡献者组都有自己的风格，并以自己的方式为规范做出贡献。结果通常是浏览器同意的相当不错的规范。但是从无到有是...凌乱。真乱。很多时候都是一个过程。它并不总是会产生一个好的规范（是的，我说的是你的 Florian 妥协......）但即使是这样，也需要一段时间。

However, It seems like Google developed this version of the spec all on their own. And, in my experience, Google's approach to the specs is always a little... well... setting my personal opinions aside we'll say "gung-ho". They tend to just dive right into the deep end. And that seems to be what they've done here.

然而，似乎谷歌自己开发了这个版本的规范。而且，根据我的经验，Google 对规范的处理方式总是有点......好吧......把我的个人意见放在一边，我们会说“gung-ho”。他们往往只是潜入深渊。这似乎就是他们在这里所做的。

I highly doubt these specs or implementations will look anything like this when they become standards. And there's nothing wrong with that. That's part of the process. But I wouldn't go relying on this implementation or developing any code or products against it. This is an unprecedented feature on the web and all the browser vendors are gonna want a big say in this.

我非常怀疑这些规范或实现在成为标准时会看起来像这样。这并没有错。这是过程的一部分。但我不会去依赖这个实现或针对它开发任何代码或产品。这是网络上前所未有的功能，所有浏览器供应商都希望在这方面有很大的发言权。

That said, this is actually good. One of the things Google often does (for better or worse) with situations like this is forces the conversation and it can push things along. And having a feature shipped in the browser, even an experimental feature, can turn up the heat on the demand for it. So we may see more progress in this area soon.

也就是说，这实际上是好的。在这种情况下，谷歌经常做的事情之一（无论好坏）就是强制对话，它可以推动事情的进展。并且在浏览器中提供一个功能，即使是一个实验性的功能，也可以提高对它的需求。因此，我们可能很快就会看到这方面的更多进展。

PhoneGapApache Cordova. You know, for your phone

电话鸿沟阿帕奇科尔多瓦。你知道，对于你的手机

Status: Not fully featured and phone only

状态：功能不全，仅限手机

Apache Cordova, previously Adobe PhoneGap, is a way to write your program in HTML, CSS, and JS that allows you to access lower level functionality on things like phones, and compile across devices. This would be a way to implement your program, but it would be a phone application, not necessarily a desktop one. An option to consider, and something I figured I would mention.

Apache Cordova，以前称为Adobe PhoneGap，是一种用 HTML、CSS 和 JS 编写程序的方法，它允许您访问手机等较低级别的功能，并跨设备编译。这将是实现您的程序的一种方式，但它是一个电话应用程序，不一定是桌面应用程序。一个可以考虑的选项，我想我会提到的一些东西。

Cordova implements a few of the above features already, but doesn't have some of the more powerful ones like NFC or BlueTooth.

Cordova 已经实现了上述一些功能，但没有一些更强大的功能，如 NFC 或蓝牙。

The Native-App solution (for Windows 8)

Native-App 解决方案（适用于 Windows 8）

Status: Possible, but OS specific and desktop app

状态：可能，但特定于操作系统和桌面应用程序

Windows 8 offers the ability to build applications in HTML and JS. This would allow you to easily access lower level functionality on the OS via their API. From the looks of it, it is pretty extensive and you can do a lot. You mentioned cross OS support, however, and this obviously limits you to one OS.

Windows 8 提供了在 HTML 和 JS 中构建应用程序的能力。这将允许您通过他们的 API轻松访问操作系统上的较低级别的功能。从它的外观来看，它非常广泛，您可以做很多事情。但是，您提到了跨操作系统支持，这显然将您限制在一个操作系统上。

It's so Flash-y!

太闪了！

Status: Dying/Dead, not possible as a web app

状态：垂死/死亡，不可能作为网络应用程序

Flash won't have direct access to the system through the web. You could create an AIR application, but that will sort of defeat the purpose of having it web based. In addition, Flash support on mobile, and on the web it would seem, is on the decline.

Flash 不能通过网络直接访问系统。您可以创建一个 AIR 应用程序，但这会违背让它基于 Web 的目的。此外，移动设备和网络上的 Flash 支持似乎正在下降。

NodeJS

节点

Status: Can be a bit of a pain and only possible as a desktop app

状态：可能有点痛苦，只能作为桌面应用程序使用

NodeJS and JS applications have sort of been a hot topic the last couple years. I didn't discuss it in my original post because I felt it wasn't quite there yet. However, things have progressed and it is much closer to being ready for this sort of thing, and has the support and power of a growing user base. That said, for your particular case, I wouldn't recommend using it. It would have to be local on the users machine, and because of how NodeJS (and similar engines) are at the moment, it would require a lot of extra configuration and setup that would complicate things a bit.

NodeJS 和 JS 应用程序在过去几年中一直是一个热门话题。我没有在我原来的帖子中讨论它，因为我觉得它还没有完全到位。然而，事情已经取得了进展，它更接近于为这种事情做好准备，并且拥有不断增长的用户群的支持和力量。也就是说，对于您的特定情况，我不建议使用它。它必须在用户机器上是本地的，并且由于 NodeJS（和类似引擎）目前的情况，它需要大量额外的配置和设置，这会使事情变得有点复杂。

So you could build an app using HTML, CSS and JS with NodeJS or similar engines and have low level access to what you need, but it has to be local, and it would take more work than I'm sure you want to do every time you'd like to install it for a customer.

因此，您可以使用带有 NodeJS 或类似引擎的 HTML、CSS 和 JS 构建一个应用程序，并且可以对您需要的内容进行低级别访问，但它必须是本地的，而且它需要做的工作比我确定的每一次都多您想为客户安装它的时间。

... Now where was I?

......现在我在哪里？

So where does that leave us? Well, simple: if you want a single language/set of code as your code base, HTML/CSS/JS aren't a great option... yet. But they could be some day. For now, your options are limited to what you feel is best for your customer. Java is a stable option you listed, but obviously comes with its own drawbacks. As the web develops, I think we'll see a lot of really cool things coming out of the new functionality, but we've got a ways to go still.

那么，这让我们何去何从？嗯，很简单：如果你想要一个单一的语言/一组代码作为你的代码库，HTML/CSS/JS 不是一个很好的选择......还没有。但他们可能有一天。目前，您的选择仅限于您认为对客户最有利的方式。Java 是您列出的稳定选项，但显然有其自身的缺点。随着网络的发展，我认为我们会看到新功能带来很多非常酷的东西，但我们还有很长的路要走。

More reading:

更多阅读：

• Brian.IO: Beyond HTML5
• HTML5 Apps on Windows 8
• Wikipedia list of projects built using JS

• Brian.IO：超越 HTML5
• Windows 8 上的 HTML5 应用
• 使用 JS 构建的项目的维基百科列表

回答by bobbybee

This is possible, but it would have to be done indirectly. In theory, you could write a socket-server in a low level language, which gets I/O, and sends the I/O through the socket (relaying, I guess). HTML5 uses WebSockets, or some equivalent to communicate with this socket-server.

这是可能的，但必须间接完成。理论上，您可以用低级语言编写一个套接字服务器，它获取 I/O，并通过套接字发送 I/O（我猜是中继）。HTML5 使用 WebSockets 或一些等价物与此套接字服务器通信。

回答by Supersharp

Now it can be achieved with WebUSBAPI.

现在可以通过WebUSBAPI来实现。

It is available in Chromesince version 54.

从 54 版开始，它在 Chrome 中可用。

It is a W3C editor's draft so we can expect (hope) that it will be adopted by other browser vendors...

这是 W3C 编辑的草案，所以我们可以期待（希望）它会被其他浏览器供应商采用......

回答by James

Just for the record, a method that works well in 2016 (since chrome 26), but is to be withdrawn over the next 2 yearsis to deploy your html5 as a chrome app and use chrome.usb(or chrome.serial or chrome.bluetooth).

仅作为记录，一种在 2016 年（自 chrome 26 起）运行良好但将在未来 2 年内撤回的方法是将您的 html5 部署为 chrome 应用程序并使用chrome.usb（或 chrome.serial 或 chrome.usb）。蓝牙）。

I am currently using chrome.usb and planning to migrate to a web app using WebUSB API(see Supersharp's answer), which I hope will be adopted by the time Google discontinue chrome apps .

我目前正在使用 chrome.usb 并计划使用WebUSB API迁移到网络应用程序（请参阅 Supersharp 的回答），我希望在 Google 停止使用 chrome 应用程序时会采用该应用程序。

回答by EJA

I've been thinking about this a lot lately... have a POS app mostly written in VB6, considering what to do next. HTML5 is an option and I was thinking I'd use VSPE to get the serial stuff into the JS.

我最近一直在考虑这个问题......有一个主要用 VB6 编写的 POS 应用程序，考虑下一步做什么。HTML5 是一种选择，我想我会使用 VSPE 将串行内容放入 JS 中。

http://www.eterlogic.com/Products.VSPE.html

http://www.eterlogic.com/Products.VSPE.html

Love this product! Works very well for getting serial traffic where you need it, so I think it would work well, at least as a proof-of-concept to get you going. You'll want to use a combination of "connector" types along with the "tcpclient" and "tcpserver".

喜欢这个产品！在您需要的地方获取串行流量非常有效，所以我认为它会很好地工作，至少作为让您前进的概念证明。您需要结合使用“connector”类型以及“tcpclient”和“tcpserver”。