HeadlessChrome101:Jit-Browser 如何将 Chrome 转变为全功能浏览器–服务器-浏览器层
这是对 Jit-Browser 如何使用无头 Chrome、如何使用专有的 Jit-TR 运行时以及为了使其成为一流的浏览器功能而不是仅仅是另一个脚本所需的内容的通俗语言演练。
从一个简单的截图工具到 Jit-Browser
我们从一个小的命令行工具开始: getpage https://example.com page.png. 它在 Docker 容器中启动 Chrome,截取渲染的 example.com 页面截图,然后退出。
有用的概念验证。每次调用都是冷启动。它对翻译、会话或状态一无所知。它只是一个无头相机。
Jit-Browser 是下一步。它仍然使用真实的 Chrome,但现在:
- 它记录页面内部发生的事情。
- 它将 Jit-TR 脚本注入为翻译层。
- 它可以遵循简单的流程,如 cookie 横幅或下拉菜单。
- 它捕获完全翻译的 HTML,而不仅仅是截图。
本页面解释了该管道,以便您可以看到我们并没有敷衍。我们展示了浏览器级多语言层如何实际工作。
Jit-Browser 管道的 6 个步骤
在高层次上,每次捕获都遵循相同的顺序。
-
在 Docker 内启动真实的 Chrome(无头)。
我们使用 Puppeteer (pptr.dev) 启动与普通浏览器相同的引擎,但没有可见窗口。没有自定义解析器,没有假渲染。 -
应用 cookie 或登录状态(如果已配置)。
对于需要登录会话的演示,我们重放您的 cookie。没有暴力破解,没有密码猜测,没有抓取我们无法控制的账户。 -
像用户一样精确加载目标页面。
HTML、CSS、JavaScript、字体、图像。我们等待networkidle2(https://pptr.dev/api/puppeteer.page.waitfornetworkidle) 以便慢速包和字体可以完成加载。 -
注入 Jit-TR 片段作为层。
我们添加一个指向我们专利申请中运行时代码的脚本标签 – 例如:. Jit-TR 运行时模块遍历暴露的 DOM(document.head 和 document.body),将提取的有效负载发送回我们的(或任何)服务器进行处理,接收结果(翻译、增强或新信息),重写可见文本,并在原始文本上添加新的意义层。 唯一存在的限制很简单:脚本可以增强,但新指令绝不能干扰网站自己的脚本。 这通常通过使用MutationObserver实例来监视 DOM 中的相关更改,应用小而有针对性的补丁更新,并避免触及任何现有的应用程序逻辑或事件处理程序来实现。 -
运行可选流程:cookie、点击和滚动。
真实页面通常需要一两个操作:关闭 cookie 横幅、打开菜单、滚动以加载更多优惠。Jit-Browser 可以运行一个简单的流程脚本,以便在捕获之前这些元素可见。 -
捕获增强的输出。
我们保存:- 用于托管或审核的完全修改的 HTML。
- 识别潜在瓶颈的时间跟踪。
这就是我们的 HeadlessChrome101 的核心。这是浏览器如何将新数据或现有数据视为任何浏览器内置层的思维模型。
为什么这不仅仅是一个玩具脚本
Jit-Browser 之所以重要,是因为它证明了可以使用浏览器供应商每天使用的相同组件构建浏览器级层,并且该层可以安全地托管与任何外部服务的完整客户端-服务器交互,包括我们自己的 Jit-TR 运行时。这也是我们添加 SEO 感知增强功能的地方,例如 rel="alternate" hreflang="..." 链接和丰富的 sitemap.xml 条目。实际上,这意味着我们可以在非破坏性 HTML 区域内公开增强信息,例如 现有页面左侧或右侧的元素,或通过使用 JavaScript 模态框附加语言选择和 SmartSearch 而不干扰原始布局或脚本。
-
真实的 Chrome 引擎。
一切都在 Chrome 本身上运行 - 只是没有可见窗口。如果它在 Chrome 中对您的访问者有效,它在 Jit-Browser 中也有效。 -
内容安全策略感知。
大多数网站使用 CSP 锁定脚本。在无头模式下,我们可以使用 Chrome 的setBypassCSP(true)(https://pptr.dev/api/puppeteer.page.setbypasscsp) 在捕获环境中注入 Jit-TR。我们不要求任何生产站点削弱其安全策略。 -
完整的计时和日志记录。
我们记录启动时间、页面加载时间、Jit-TR 启动、流程步骤和捕获。您可以看到毫秒的去向以及 Jit-TR 在页面上实际做了什么。 -
脚本和层的分离。
今天,Jit-TR 可以是您添加到站点的“仅仅是一个脚本”。在 Jit-Browser 中,我们将其视为始终运行的稳定层。这非常接近浏览器供应商可以本地集成它的方式。
Jit-TR API 已经解决的问题
难点不在于无头 Chrome。难点在于可靠地将实时、混乱的网页转换为安全的多语言版本。我们的专有运行时在 api.jit-tr.com 已经完成了这项工作。
今天,API 运行时处理:
-
语言选择。
它读取参数,如jittr=ES-419,规范化边缘情况,并记录所选语言,例如:[Jit-TR] 选择的语言 → ES-419. -
DOM 提取、翻译和语义重写。
运行时遍历真实的 Chrome DOM,仅提取可见文本,构建结构化翻译负载,并将结果写回页面。所有困难的边缘情况都是自动处理的:表情符号序列、HTML 实体、标点和间距规则、混合语言字符串以及从左到右/从右到左的切换。它还重写特定语言的脚本块 — 包括和其他结构化数据标签 — 确保每种语言都有正确、独立、缓存的元数据供搜索引擎和 AI 系统使用。 -
客户端行为。
它呈现语言标志,尊重不安全的根,并尽可能安全地与单页应用程序和框架一起运行。
所有这些今天都在 Jit-TR 站点上运行。Jit-Browser 只是将其在受控的无头环境中重用。
本地浏览器功能仍需的内容
本地浏览器功能仍需的内容
将 Jit-Browser 转变为内置浏览器功能,无需奇迹 - 只需能够放置一小组浏览器引擎已经理解的更改。
将 Jit=-Browser 转变为内置浏览器功能。这不是奇迹,只是浏览器已经理解的一小组更改。
-
引擎中的本地挂钩。
今天我们通过从无头 Chrome 注入脚本来模拟这一点。真正的集成将为 Jit-TR 提供一个专用的翻译插槽,以便它可以在渲染管道的正确点读取和写入 DOM 文本。 -
表达语言意图的标准方式。
我们已经使用?jittr=LANG和 cookies。浏览器级解决方案可以尊重浏览器语言设置和用户选择,例如“始终将此站点翻译为 ES-419”。 -
明确的安全和隐私框架。
应明确记录哪些文本可以离开设备、可以缓存多长时间以及站点或用户如何选择退出的规则。浏览器内的本地实现实际上可以比临时脚本更安全。
示例:HarmonyOS 在 ES-419
这是管道实际运行的一个具体示例。
我们调用:
getpageJtrBrowser \
"https://www.harmonyos.com/" \
"jittr=ES-419" \
null \
"ES-419/index.php"
Jit-Browser:
- 在 Docker 内启动无头 Chrome。
- 加载
https://www.harmonyos.com/. - 注入带有 ES-419 参数的 Jit-TR 代码片段。
- 让 Jit-TR 将可见的中文文本翻译为西班牙语(拉丁美洲)。
- 将结果保存为
ES-419/index.php.
HarmonyOS 站点无需更改。从用户的角度来看,它看起来就像站点支持他们的语言。
为什么此页面存在
HeadlessChrome101 是一个摘要,显示:
- 我们正在使用真实的浏览器引擎和真实的 CSP 规则。
- 我们已经有一个可用的专有翻译运行时。
- 到本地浏览器功能的剩余差距很小且定义明确。
如果您构建浏览器、操作系统或大型平台,并希望拥有一个尊重您的安全模型的通用多语言层,我们随时准备洽谈。代码已经存在。行为是可测量的。下一步是合作。