是否可能让人们自动化这种交互--而无需将图像发送到我们的服务器(从而增加带宽成本和服务器负载)和无需要求用户下载像Puppeteer这样的无头浏览器库?
例如,以下流程是否可行:
- 通过命令行(或本地脚本)打开Chrome到特定的网页。
- 将图像上传到该网页。
- 调用网页上的脚本。
- 接收脚本结果并允许进行本地操作。
理论上是可以自动化的,但实现起来却不容易。
你的问题可以分为两部分:离线处理和上传自动化。
离线处理
假设你的图像处理代码完全由浏览器JavaScript编写(而不是调用本地库的模块化node程序),则可以全部在浏览器中进行处理。
“上传”的文件可以被读取、处理并下载,而无需将任何内容发送到服务器。 处理甚至可以在后台线程中进行,使用户界面保持响应,例如一个漂亮的进度条。
代码本身可以使用Service Worker或静态html+javascript在线托管。 一旦访问或部署,两者都可以脱机打开和执行。 (请注意,Chrome严重限制静态html,包括对Web Workers的严格限制。Google更喜欢您保持联网状态。)
上传自动化
如上所述,通过文件输入选择或拖入浏览器的文件可以由页面中的JavaScript读取,但出于传统原因,我仍然将其称为“上传”操作。
Chrome有一些自动化扩展程序,尤其是Kantu,但由于Chrome的安全限制,它们无法处理文件上传。
因此,如果您想自动选择文件,需要使用本地的、超出浏览器范围的自动化工具,例如Kantu的XModules、AutoHotkey或SikuliX。商业解决方案存在,但考虑到您的非常规要求(不能使用无头浏览器),也存在类似的限制。
AutoHotkey将专注于模拟键盘操作(打开浏览器,等待5秒钟,按Tab键10次,按回车键,等待2秒钟,输入文件名等),并可以编译成可部署的exe。
Sikulix更强大,但也更难分发;仅Java运行时就比浏览器更大。
Kantu + XModules介于两者之间。用户需要安装浏览器扩展程序和其本地扩展程序,但一旦完成,所有操作都在浏览器内部进行(或多或少)。
这三种方法都涉及模拟输入文件名,因为据我所知,在用户启动的(非无头)Chrome中自动化没有更简单的方法。
文件名可以作为参数传递给AutoHotkey和Sikulix的命令行,或在Kantu脚本中存储在文件中并读取。
在这三种情况下,自动化模拟了用户,真实用户在脚本运行时不得触摸计算机,否则自动化将停止。
那命令行呢?
或者,如果您的目标是自动化而不部署浏览器,则可以考虑将其制作为命令行Node.js程序,并将其打包为exe。
可分发的内容比编译后的AutoHotkey重,但移动部件要少得多,因此更可靠:
但我喜欢浏览器自动化,它很简单
再想一想。
从我的经验来看,许多事情会使浏览器/GUI自动化失效:
所以,是的,这就是为什么计算机自动化最好无头执行的原因。
我的代码会安全吗?
如果您担心脚本的安全性,请放心。 一旦您想要在客户端上处理,猫就跑了。
从技术上讲,您的代码受版权保护。但是如果你想执行保护工作,祝你好运。 如果您希望使您的代码免于被提取/解密/反混淆等操作(咳咳),您需要将其保持为在线黑盒子,不进行客户端处理。
围绕您的Web应用程序构建的一种方法是:
1)将console.log重定向到标准输出(请参见此处:在Chrome中,如何将JavaScript控制台输出重定向到标准输出/标准错误),可能需要适当的--log-level
标志和将错误消息重定向到其他位置,以便某些随机消息不会破坏整个过程,
2)从脚本级别开始/除了保存结果文件之外,以Base64格式记录console.log信息,
3)从CLI侧面,使用一个管道(管道),使Base64成为一个合适的文件(以及任何其他处理)。
.js
脚本来提供您的代码,然后您可以将其提供给开发人员,他们可以通过脚本标签将其包含在自己的网站中或者下载并在本地使用。您所需要做的就是提供这个脚本。 - MauriceNino