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 條目。實際上,這意味著我們可以在不干擾原始佈局或腳本的情況下,在現有頁面的左側或右側的 元素內部或通過使用 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 規則。
- 我們已經有一個可運行的專有翻譯運行時。
- 到本地瀏覽器功能的剩餘差距很小且定義明確。
如果您正在構建瀏覽器、操作系統或大型平台,並希望擁有一個尊重您的安全模型的通用多語言層,我們隨時準備好與您洽談。代碼已經存在。行為是可測量的。下一步是合作。