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

Question

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

是否可以让人们自动进行这种交互-无需将图像发送到我们的服务器（从而增加了带宽成本和服务器负载），并且不需要用户下载无头的浏览器库（如Puppeteer）？

例如，以下流程是否可能：

1. 通过命令行（或本地脚本）打开Chrome到特定网页。
2. 将图像上传到该网页。
3. 在网页上调用脚本。
4. 接收脚本结果并允许本地操作。

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

Answer 1

技术上应该是可以自动化的，但这远非那么简单。

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

离线处理

假设您的图像处理代码完全是浏览器内的 JavaScript（而不是调用本机库的模块化节点程序），则可以在浏览器内完成所有处理。

“上传”的文件可以被读取、处理和下载，而无需向服务器发送任何内容。处理甚至可能发生在后台线程中，保持 UI 响应，例如漂亮的进度条。

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

上传自动化

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

Chrome 有一些自动化扩展，最著名的是Kantu ，但由于 Chrome 的安全限制，它们无法处理文件上传。

因此，如果您想自动选择文件，则需要使用浏览器外的本机自动化工具，例如 Kantu 的XModules、AutoHotkey或SikuliX。商业解决方案是存在的，但考虑到您对无头浏览器的特殊要求，也有类似的限制。

• AutoHotkey 将专注于模拟键盘（打开浏览器，等待 5 秒，按 Tab 10 次，按 Enter，等待 2 秒，键入文件名，按 Enter 等），并且可以编译为可部署的 exe。

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

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

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

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

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

命令行怎么样？

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

可分发的版本比编译后的 AutoHotkey 重，但移动部件少得多，因此更可靠：

• 独立于 Chrome 版本或 XModules 的存在。
• 所有处理都发生在自己的进程中，而不是劫持用户的 Chrome。
• 可以无头执行，这对于自动化非常重要。
• 灵活的命令行参数。

但我喜欢浏览器自动化，它是如此简单

再想一想。

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

1. 不寻常的屏幕分辨率、浏览器缩放、操作系统缩放或最后记住的 Chrome 尺寸都会使您的页面扭曲得无法识别。
2. 更改页面元素的浏览器扩展，例如广告拦截器。
3. IME 和其他使用热键拦截键盘输入的程序。
4. 弹出程序，例如防病毒、Windows 更新或插入 CD。
5. 意外锁定、睡眠、注销、按键留在键盘上或电源中断。
6. 或者一个简单的 Chrome 更新会破坏您所依赖的 100 个东西中的任何一个。

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

我的代码安全吗？

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

从技术上讲，您的代码受版权保护。但祝你好运。如果你想让你的代码不被提取/解密/取消混淆/无论什么（咳嗽），你需要将其保留为在线黑匣子，没有客户端处理。