javascript - 通过命令行或本地脚本与浏览器 JavaScript 交互？

Question

我们提供类似于 imagemagick 的浏览器页面 JavaScript，可帮助人们将图像转换为不同大小和格式。但是，它需要网页交互。

是否可以让人们自动进行这种交互——无需将图像发送到我们的服务器(从而增加带宽成本和服务器负载)，也无需用户下载像 Puppeteer 这样的 headless 浏览器库？

例如，以下流程是否可行:

通过命令行(或本地脚本)打开 Chrome 到特定网页。

将图像上传到该网页。

在网页上调用脚本。

接收脚本结果并允许本地操作。

启动 Chrome 是可能的，但尚不清楚启动后是否可以与特定浏览器窗口进行交互。

Answer 1

在技​​术上应该是可以自动化的，但这远非直接的。

您的问题可以分为两部分:离线处理和上传自动化。

离线处理

假设您的图像处理代码是完全在浏览器中的 JavaScript(而不是，例如，调用 native 库的模块化节点程序)，则可以在浏览器中完成所有处理。

文件“上传”可以是read 、已处理和 downloaded无需向服务器发送任何内容。
处理甚至可能发生在 background thread 中。 ，保持 UI 响应，例如一个不错的进度条。

代码本身可以使用 Service Worker 在线托管。 ，或静态 html + javascript。
一旦访问或部署，两者都可以离线打开和执行。
(请注意，Chrome 严格限制静态 html，包括对网络 worker 的严格限制。
Google 更希望您将内容保持在线状态。)

上传自动化

如上所述，通过文件输入选择的文件或放入浏览器的文件可以被页内 JavaScript 读取，但我将继续称其为传统的“上传”操作。

Chrome 有一些自动化扩展，最著名的是 Kantu ，但由于 Chrome 的 security restriction，他们无法处理文件上传.

所以，如果你想自动化文件选择，你需要使用原生的、浏览器外的自动化工具，比如 Kantu 的 XModules , AutoHotkey , 或 SikuliX .存在商业解决方案，但鉴于您对 headless 浏览器的不寻常要求，有类似的限制。

AutoHotkey 将专注于模拟键盘(打开浏览器，等待 5 秒，按 Tab 10 次，按回车，等待 2 秒，输入文件名，按回车等)，并且可以编译成可部署的 exe。

Sikulix 更强大，但也更难分发；只是 java 运行时比浏览器大。

Kantu + XModules 介于两者之间。用户将需要安装浏览器扩展及其 native 扩展，但一旦完成，一切都会在浏览器中发生(或多或少)。

所有三种方法都涉及输入文件名的模拟，因为据我所知，没有更简单的方法可以在用户启动的(非 headless )Chrome 中实现自动化。

图像文件的名称可以作为参数传递给 AutoHotkey 和 Sikulix 的命令行，或者存储在文件中并在 Kantu 的情况下由脚本读取。

在所有三种情况下，自动化都是模拟用户，现实生活中的用户在脚本运行时不得接触计算机，否则自动化会中断。

命令行呢？

或者，如果您的目标是自动化而不部署浏览器，您可以考虑将其制作为命令行 node.js 程序，并将其打包为 exe。

可分发的将比编译的 AutoHotkey 重，但移动部件要少得多，因此更可靠:

独立于 Chrome 版本或 XModules 的存在。

所有处理都在自己的进程中进行，而不是劫持用户的 Chrome。

可以 headless 执行，这对于自动化非常重要。

灵活的命令行参数。

但我喜欢浏览器自动化，就是这么简单

再想想。

根据我的经验，很多事情会导致浏览器/GUI 自动化:

不寻常的屏幕分辨率、浏览器缩放、操作系统缩放或最后记住的 Chrome 大小会扭曲您的页面，无法识别。

更改页面元素的浏览器扩展程序，例如广告拦截器。

使用热键拦截键盘输入的 IME 和其他程序。

弹出程序，例如防病毒、Windows 更新或插入 CD。

意外锁定、 sleep 、注销、键盘上遗留的键或电源中断。

或者一个简单的 Chrome 更新可以打破你所依赖的 100 件事中的任何一件。

所以，是的，这就是为什么计算机自动化最好 headless 完成的原因。

我的代码会安全吗？

如果您担心脚本的安全性，请不要担心。
当您希望处理发生在客户端的那一刻，猫就出来了。

从技术上讲，您的代码受版权保护。
但祝你好运。
如果你想让你的代码不被提取/解密/取消混淆/任何(咳嗽)，你需要把它放在一个在线黑盒中，没有客户端处理。