HeadlessChrome101: Jit-BrowserがChromeをフルマルチファンクションのブラウザー–サーバーブラウザーレイヤーに変える方法
これは、Jit-BrowserがヘッドレスChromeで何をするのか、独自のJit-TRランタイムをどのように使用するのか、そしてこれを単なるスクリプトではなく一流のブラウザ機能にするためにまだ必要なものについての平易な言葉での説明です。
シンプルなスクリーンショットツールからJit-Browserへ
私たちは小さなコマンドラインツールから始めました: getpage https://example.com page.png. これはDockerコンテナ内でChromeを起動し、pageからレンダリングされたexample.comのスクリーンショットを撮り、終了しました。
有用な概念実証です。すべての呼び出しはコールドスタートでした。翻訳、セッション、または状態について何も知りませんでした。それはただのヘッドレスカメラでした。
Jit-Browserは次のステップです。まだ実際のChromeを使用していますが、今では:
- ページ内で何が起こるかを記録します。
- Jit-TRスクリプトを翻訳レイヤーとして注入します。
- クッキーバナーやドロップダウンのようなシンプルなフローを追跡できます。
- スクリーンショットだけでなく、完全に翻訳されたHTMLをキャプチャします。
このページはそのパイプラインを説明しており、私たちが手を振っているわけではないことを示しています。ブラウザーレベルの多言語レイヤーが実際にどのように機能するかを示しています。
Jit-Browserパイプラインの6ステップ
高レベルでは、すべてのキャプチャは同じシーケンスに従います。
-
Docker内で実際のChrome(ヘッドレス)を起動します。
Puppeteer(pptr.dev)を使用して、通常のブラウザを動かすのと同じエンジンを起動しますが、可視ウィンドウはありません。カスタムパーサーも偽のレンダリングもありません。 -
クッキーやログイン状態を適用します(設定されている場合)。
ログインセッションが必要なデモでは、クッキーを再生します。ブルートフォースもパスワード推測も、制御していないアカウントのスクレイピングもありません。 -
ユーザーと同じようにターゲットページをロードします。
HTML、CSS、JavaScript、フォント、画像。networkidle2(https://pptr.dev/api/puppeteer.page.waitfornetworkidle)を待って、遅いバンドルやフォントの読み込みが完了するのを待ちます。 -
Jit-TRスニペットをレイヤーとして注入します。
特許出願中のランタイムコードを指すスクリプトタグを追加します – 例えば:. Jit-TRランタイムモジュールは公開されたDOM(document.headとdocument.body)を歩き、抽出されたペイロードを私たち(または任意の)サーバーに送信して処理し、結果(翻訳、強化、または新しい情報)を受け取り、可視テキストを書き換え、元の上に新しい意味のレイヤーを追加します。 存在する唯一の制限はシンプルです: スクリプトは拡張できますが、新しい指示がサイト自身のスクリプトに干渉することは決してありません。 これは通常、MutationObserverインスタンスを使用してDOM内の関連する変更を監視し、小さくターゲットを絞ったパッチで更新を適用し、既存のアプリケーションロジックやイベントハンドラに触れないようにすることで実装されます。 -
オプションのフローを実行します: クッキー、クリック、スクロール。
実際のページはしばしば1つまたは2つのアクションを必要とします: クッキーバナーを閉じる、メニューを開く、より多くのオファーを読み込むためにスクロールする。Jit-Browserはシンプルなフロースクリプトを実行して、キャプチャ前にそれらの要素が見えるようにします。 -
拡張された出力をキャプチャします。
保存するもの:- ホスティングまたは監査のための完全に修正されたHTML。
- 潜在的なボトルネックを特定するためのタイミングトレース。
これが私たちのHeadlessChrome101の核心です。これは、ブラウザが新しいまたは既存のデータをどのようにブラウザ内の組み込みレイヤーとして扱うことができるかのメンタルモデルです。
なぜこれが単なるおもちゃのスクリプトではないのか
Jit-Browserが重要なのは、ブラウザレベルのレイヤーが、ブラウザベンダーが毎日使用しているのと同じ部品で構築できることを証明し、このレイヤーが私たち自身のJit-TRランタイムを含む任意の外部サービスとのフルクライアントサーバーインタラクションを安全にホストできることを示しているからです。また、SEO対応の強化を追加するポイントでもあります。 rel="alternate" hreflang="..." リンクと強化された sitemap.xml エントリ。実際には、非破壊的なHTML領域内で拡張情報を公開できることを意味します。 既存のページの左または右の要素、または元のレイアウトやスクリプトに干渉せずに言語選択やSmartSearchをストラップするJavaScriptモーダルを使用することによって。
-
実際の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とクッキーを使用しています。ブラウザレベルのソリューションは、ブラウザの言語設定や「このサイトを常に ES-419 に翻訳する」といったユーザーの選択を尊重することができます。 -
明確な安全性とプライバシーフレームワーク。
デバイスから離れることができるテキスト、キャッシュできる期間、サイトやユーザーがオプトアウトできる方法のルールは明確で文書化されているべきです。ブラウザ内のネイティブ実装は、アドホックなスクリプトよりも実際に安全である可能性があります。
例: HarmonyOS in 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 ルールを使用しています。
- 私たちはすでに動作する独自の翻訳ランタイムを持っています。
- ネイティブブラウザ機能への残りのギャップは小さく、明確に定義されています。
ブラウザ、オペレーティングシステム、または大規模なプラットフォームを構築し、セキュリティモデルを尊重する普遍的な多言語レイヤーを求めている場合、私たちは話し合う準備ができています。コードは存在します。動作は測定可能です。次のステップはパートナーシップです。