HeadlessChrome101: Wie Jit-Browser Chrome in einen vollwertigen Multifunktionsbrowser–Server-Browser-Schicht verwandelt
Dies ist eine verständliche Anleitung, was Jit-Browser mit headless Chrome macht, wie es die proprietäre Jit-TR-Laufzeit verwendet und was noch benötigt wird, um dies zu einer erstklassigen Browserfunktion zu machen, anstatt nur ein weiteres Skript zu sein.
Von einem einfachen Screenshot-Tool zu Jit-Browser
Wir begannen mit einem kleinen Kommandozeilen-Tool: getpage https://example.com page.png. Es startete Chrome in einem Docker-Container, machte einen Screenshot von dem gerenderten example.com von der Seite und beendete sich.
Nützlicher Proof of Concept. Jeder Aufruf war ein Kaltstart. Es wusste nichts über Übersetzungen, Sitzungen oder Zustand. Es war einfach eine headless Kamera.
Jit-Browser ist der nächste Schritt. Es verwendet immer noch echtes Chrome, aber jetzt:
- Es protokolliert, was auf der Seite passiert.
- Es injiziert das Jit-TR-Skript als Übersetzungsschicht.
- Es kann einfachen Abläufen wie Cookie-Bannern oder Dropdowns folgen.
- Es erfasst das vollständig übersetzte HTML, nicht nur einen Screenshot.
Diese Seite erklärt diese Pipeline, damit Sie sehen können, dass wir nicht nur mit den Händen wedeln. Wir zeigen, wie eine browserseitige mehrsprachige Schicht tatsächlich funktionieren kann.
Die Jit-Browser-Pipeline in 6 Schritten
Auf hoher Ebene folgt jede Erfassung derselben Sequenz.
-
Echtes Chrome (headless) innerhalb von Docker starten.
Wir verwenden Puppeteer (pptr.dev), um die gleiche Engine zu starten, die normale Browser antreibt, jedoch ohne ein sichtbares Fenster. Kein benutzerdefinierter Parser, kein gefälschtes Rendering. -
Cookies oder Anmeldestatus anwenden (sofern konfiguriert).
Für Demos, die eine angemeldete Sitzung benötigen, spielen wir Ihre Cookies ab. Kein Brute-Force, kein Passwort-Raten, kein Scraping von Konten, die wir nicht kontrollieren. -
Laden Sie die Zielseite genau wie ein Benutzer.
HTML, CSS, JavaScript, Schriftarten, Bilder. Wir warten aufnetworkidle2(https://pptr.dev/api/puppeteer.page.waitfornetworkidle), damit langsame Bundles und Schriftarten das Laden abschließen können. -
Injizieren Sie den Jit-TR-Schnipsel als Schicht.
Wir fügen ein Skript-Tag hinzu, das auf unseren patentierten Laufzeitcode verweist – zum Beispiel:. Das Jit-TR-Laufzeitmodul durchläuft das exponierte DOM (document.head und document.body), sendet die extrahierte Nutzlast zurück an unseren (oder jeden) Server zur Verarbeitung, erhält die Ergebnisse (Übersetzung, Verbesserung oder neue Informationen), schreibt sichtbaren Text um und fügt neue Bedeutungsschichten über das Original hinzu. Die einzigen bestehenden Einschränkungen sind einfach: Skripte können erweitert werden, aber neue Anweisungen dürfen niemals mit den eigenen Skripten der Seite interferieren. Dies wird typischerweise implementiert, indemMutationObserverInstanzen verwendet werden, um relevante Änderungen im DOM zu überwachen, Updates in kleinen, gezielten Patches anzuwenden und zu vermeiden, dass bestehende Anwendungslogik oder Ereignis-Handler berührt werden. -
Führen Sie optionale Abläufe aus: Cookies, Klicks und Scrollen.
Echte Seiten benötigen oft eine oder zwei Aktionen: Schließen eines Cookie-Banners, Öffnen eines Menüs, Scrollen, um mehr Angebote zu laden. Jit-Browser kann ein einfaches Ablaufskript ausführen, damit diese Elemente vor der Erfassung sichtbar sind. -
Erfassen Sie die augmentierte Ausgabe.
Wir speichern:- Das vollständig modifizierte HTML für Hosting oder Audit.
- Eine Zeitverfolgung zur Identifizierung potenzieller Engpässe.
Das ist der Kern von unserem HeadlessChrome101. Es ist das mentale Modell dafür, wie ein Browser neue oder vorhandene Daten als integrierte Schicht innerhalb eines jeden Browsers behandeln könnte.
Warum dies nicht nur ein Spielzeug-Skript ist
Jit-Browser ist wichtig, weil es beweist, dass eine browserseitige Schicht mit denselben Komponenten aufgebaut werden kann, die Browseranbieter bereits jeden Tag verwenden, und dass diese Schicht sicher eine vollständige Client-Server-Interaktion mit jedem externen Dienst, einschließlich unserer eigenen Jit-TR-Laufzeit, hosten kann. Es ist auch der Punkt, an dem wir SEO-bewusste Verbesserungen wie rel="alternate" hreflang="..." Links und angereicherte sitemap.xml Einträge hinzufügen. In der Praxis bedeutet dies, dass wir augmentierte Informationen innerhalb nicht störender HTML-Bereiche wie Elemente auf der linken oder rechten Seite der bestehenden Seite oder durch die Verwendung von JavaScript-Modalen, die Sprachwahl und SmartSearch anbringen, ohne das ursprüngliche Layout oder die Skripte zu stören.
-
Echte Chrome-Engine.
Alles läuft auf Chrome selbst - nur ohne das sichtbare Fenster. Wenn es in Chrome für Ihre Besucher funktioniert, funktioniert es auch in Jit-Browser. -
CSP-bewusst.
Die meisten Seiten schränken Skripte mit CSP ein. Im headless-Modus können wir ChromessetBypassCSP(true)(https://pptr.dev/api/puppeteer.page.setbypasscsp) um Jit-TR in die Capture-Umgebung einzufügen. Wir verlangen nicht, dass Produktionsseiten ihre Sicherheitsrichtlinien schwächen. -
Vollständige Zeitmessung und Protokollierung.
Wir protokollieren Startzeiten, Seitenladezeiten, Jit-TR-Start, Fluss-Schritte und Capture. Sie können sehen, wo die Millisekunden hingehen und was Jit-TR tatsächlich auf der Seite macht. -
Trennung von Skript und Schicht.
Heute kann Jit-TR "nur ein Skript" sein, das Sie zu einer Seite hinzufügen. In Jit-Browser behandeln wir es wie eine stabile Schicht, die immer läuft. Das ist sehr nah daran, wie ein Browser-Anbieter es nativ einfügen könnte.
Was die Jit-TR API bereits löst
Der schwierige Teil ist nicht headless Chrome. Der schwierige Teil besteht darin, lebendige, unordentliche Webseiten zuverlässig in sichere mehrsprachige Versionen zu verwandeln. Unsere proprietäre Laufzeit bei api.jit-tr.com macht bereits diese Arbeit.
Heute kümmert sich die API-Laufzeit um:
-
Sprachauswahl.
Es liest Parameter wiejittr=ES-419, normalisiert Randfälle und protokolliert die gewählte Sprache, zum Beispiel:[Jit-TR] Gewählte Sprache → ES-419. -
DOM-Extraktion, Übersetzung und semantische Umschreibungen.
Die Laufzeit durchläuft das echte Chrome-DOM, extrahiert nur sichtbaren Text, erstellt eine strukturierte Übersetzungsnutzlast und schreibt die Ergebnisse zurück auf die Seite. Alle schwierigen Randfälle sind automatisch: Emoji-Sequenzen, HTML-Entitäten, Interpunktions- und Abstandsregeln, mehrsprachige Strings und Links-nach-Rechts / Rechts-nach-Links-Umschaltung. Es schreibt auch sprachspezifische Skriptblöcke um – einschließlichund anderer strukturierter Daten-Tags – und stellt sicher, dass jede Sprache korrekte, unabhängige, zwischengespeicherte Metadaten für Suchmaschinen und KI-Systeme hat. -
Client-Verhalten.
Es rendert Sprachflaggen, respektiert unsichere Wurzeln und spielt so sicher wie möglich mit Single-Page-Apps und Frameworks.
All dies läuft bereits heute auf Jit-TR-Seiten. Jit-Browser nutzt es einfach in einer kontrollierten headless Umgebung wieder.
Was noch für eine native Browserfunktion benötigt wird
Was noch für eine native Browserfunktion benötigt wird
Um Jit-Browser in eine integrierte Browserfunktion zu verwandeln, braucht niemand ein Wunder – nur die Fähigkeit, eine kleine, klar definierte Menge an Änderungen vorzunehmen, die Browser-Engines bereits verstehen.
Um Jit-Browser in eine integrierte Browserfunktion zu verwandeln. Das ist kein Wunder, sondern nur eine kleine Menge an Änderungen, die Browser bereits verstehen.
-
Ein nativer Hook im Engine.
Heute simulieren wir dies, indem wir ein Skript von headless Chrome injizieren. Eine echte Integration würde Jit-TR einen dedizierten Übersetzungsplatz geben, damit es DOM-Text an der richtigen Stelle in der Rendering-Pipeline lesen und schreiben kann. -
Eine standardisierte Möglichkeit, Sprachabsichten auszudrücken.
Wir verwenden bereits?jittr=LANGund Cookies. Eine browserseitige Lösung könnte die Spracheinstellungen des Browsers und die Benutzerentscheidungen wie "diese Seite immer auf ES-419 übersetzen" respektieren. -
Ein klares Sicherheits- und Datenschutzrahmen.
Die Regeln dafür, welcher Text das Gerät verlassen kann, wie lange er zwischengespeichert werden kann und wie Seiten oder Benutzer sich abmelden können, sollten klar und dokumentiert sein. Eine native Implementierung im Browser kann tatsächlich sicherer sein als ad-hoc Skripte.
Beispiel: HarmonyOS in ES-419
Hier ist ein konkretes Beispiel für die Pipeline in Aktion.
Wir rufen auf:
getpageJtrBrowser \
"https://www.harmonyos.com/" \
"jittr=ES-419" \
null \
"ES-419/index.php"
Jit-Browser:
- Startet headless Chrome in Docker.
- Lädt
https://www.harmonyos.com/. - Injiziert den Jit-TR-Schnipsel mit dem ES-419-Parameter.
- Lässt Jit-TR den sichtbaren chinesischen Text ins Spanische (Lateinamerika) übersetzen.
- Speichert das Ergebnis als
ES-419/index.php.
Die HarmonyOS-Seite muss sich nicht ändern. Aus der Perspektive des Benutzers sieht es so aus, als würde die Seite einfach ihre Sprache unterstützen.
Warum diese Seite existiert
HeadlessChrome101 ist eine Zusammenfassung, die zeigt:
- Wir verwenden echte Browser-Engines und echte CSP-Regeln.
- Wir haben bereits eine funktionierende, proprietäre Übersetzungs-Laufzeit.
- Die verbleibende Lücke zu einer nativen Browserfunktion ist klein und gut definiert.
Wenn Sie Browser, Betriebssysteme oder große Plattformen entwickeln und eine universelle mehrsprachige Schicht wünschen, die Ihr Sicherheitsmodell respektiert, sind wir bereit zu sprechen. Der Code existiert. Das Verhalten ist messbar. Der nächste Schritt ist die Partnerschaft.