HeadlessChrome101: Hvordan Jit-Browser gjør Chrome til en fullverdig multifunksjons nettleser–server-nettleser lag
Dette er en enkel gjennomgang av hva Jit-Browser gjør med headless Chrome, hvordan det bruker den proprietære Jit-TR runtime, og hva som fortsatt trengs for å gjøre dette til en førsteklasses nettleserfunksjon i stedet for bare et annet skript.
Fra et enkelt skjermbildeverktøy til Jit-Browser
Vi startet med et lite kommandolinjeverktøy: getpage https://example.com page.png. Det startet Chrome i en Docker-container, tok et skjermbilde av den gjengitte example.com fra siden, og avsluttet.
Nyttig bevis på konseptet. Hver kall var en kald start. Det visste ingenting om oversettelse, økter eller tilstand. Det var bare et headless kamera.
Jit-Browser er neste steg. Det bruker fortsatt ekte Chrome, men nå:
- Det logger hva som skjer inne på siden.
- Det injiserer Jit-TR skriptet som et oversettelseslag.
- Det kan følge enkle flyt som informasjonskapsler eller nedtrekksmenyer.
- Det fanger den fullt oversatte HTML-en, ikke bare et skjermbilde.
Denne siden forklarer den prosessen slik at du kan se at vi ikke bare snakker. Vi viser hvordan et nettleser-nivå flerspråklig lag faktisk kan fungere.
Jit-Browser prosessen i 6 trinn
På et høyt nivå følger hver fangst den samme sekvensen.
-
Start ekte Chrome (headless) inne i Docker.
Vi bruker Puppeteer (pptr.dev) for å starte den samme motoren som driver normale nettlesere, men uten et synlig vindu. Ingen tilpasset parser, ingen falsk gjengivelse. -
Bruk informasjonskapsler eller innloggingsstatus (hvis konfigurert).
For demoer som trenger en innlogget økt, gjentar vi informasjonskapslene dine. Ingen brute force, ingen passordgjetting, ingen scraping av kontoer vi ikke kontrollerer. -
Last inn mål siden nøyaktig som en bruker.
HTML, CSS, JavaScript, skrifttyper, bilder. Vi venter pånetworkidle2(https://pptr.dev/api/puppeteer.page.waitfornetworkidle) slik at langsomme pakker og skrifttyper kan fullføre lasting. -
Injiser Jit-TR-snippet som et lag.
Vi legger til et skript-tag som peker til vår patent-pågående runtime-kode – for eksempel:. Jit-TR runtime-modulen går gjennom det eksponerte DOM (document.head og document.body), sender den utdragne payloaden tilbake til vår (eller hvilken som helst) server for behandling, mottar resultatene (oversettelse, forbedring eller ny informasjon), omskriver synlig tekst, og legger til nye lag med mening på toppen av den originale. De eneste restriksjonene som eksisterer er enkle: skript kan utvides, men nye instruksjoner kan aldri forstyrre nettstedets egne skript. Dette implementeres vanligvis ved å brukeMutationObserverinstanser for å overvåke relevante endringer i DOM, anvende oppdateringer i små, målrettede oppdateringer, og unngå å berøre eksisterende applikasjonslogikk eller hendelseshåndterere. -
Kjør valgfrie flyt: informasjonskapsler, klikk og rulling.
Ekte sider trenger ofte en eller to handlinger: lukke en informasjonskapselbanner, åpne en meny, rulle for å laste flere tilbud. Jit-Browser kan kjøre et enkelt flytskript slik at disse elementene er synlige før fangst. -
Fang den utvidede utgangen.
Vi lagrer:- Den fullt modifiserte HTML-en for hosting eller revisjon.
- En tidslinje for å identifisere potensielle flaskehalser.
Det er kjernen i vår HeadlessChrome101. Det er den mentale modellen for hvordan en nettleser kan behandle nye eller eksisterende data som et innebygd lag inne i hvilken som helst nettleser.
Hvorfor dette ikke bare er et leketøysskript
Jit-Browser er viktig fordi det beviser at et nettleser-nivå lag kan bygges med de samme delene nettleserleverandører allerede bruker hver dag, og at dette laget trygt kan være vert for en full klient-server interaksjon med enhver ekstern tjeneste, inkludert vår egen Jit-TR runtime. Det er også punktet hvor vi legger til SEO-bevisste forbedringer som rel="alternate" hreflang="..." lenker og beriket sitemap.xml oppføringer. I praksis betyr dette at vi kan eksponere utvidet informasjon inne i ikke-forstyrrende HTML-regioner som elementer til venstre eller høyre for den eksisterende siden, eller ved å bruke JavaScript-modaler som knytter til språkvalg og SmartSearch uten å forstyrre den originale layouten eller skriptene.
-
Ekte Chrome-motor.
Alt kjører på Chrome selv - bare uten det synlige vinduet. Hvis det fungerer i Chrome for besøkende dine, fungerer det i Jit-Browser. -
Innholdssikkerhetspolicy bevisst.
De fleste nettsteder låser skript med CSP. I headless-modus kan vi bruke ChromessetBypassCSP(true)(https://pptr.dev/api/puppeteer.page.setbypasscsp) for å injisere Jit-TR inn i fangstmiljøet. Vi krever ikke at produksjonssteder svekker sikkerhetspolicyene sine. -
Full timing og logging.
Vi logger oppstartstider, sideinnlastningstider, Jit-TR oppstart, flyttrinn og fangst. Du kan se hvor millisekundene går og hva Jit-TR faktisk gjør på siden. -
Separasjon av skript og lag.
I dag kan Jit-TR være "bare et skript" du legger til et nettsted. I Jit-Browser behandler vi det som et stabilt lag som alltid kjører. Det er veldig nært hvordan en nettleserleverandør kunne integrere det nativt.
Hva Jit-TR API allerede løser
Den vanskelige delen er ikke headless Chrome. Den vanskelige delen er pålitelig å gjøre levende, rotete nettsider om til trygge flerspråklige versjoner. Vår proprietære runtime på api.jit-tr.com gjør allerede det arbeidet.
I dag håndterer API-runtime:
-
Språkvalg.
Den leser parametere somjittr=ES-419, normaliserer kanttilfeller, og logger det valgte språket, for eksempel:[Jit-TR] Språk valgt → ES-419. -
DOM-ekstraksjon, oversettelse og semantiske omskrivninger.
Runtime går gjennom den virkelige Chrome DOM, ekstrakterer kun synlig tekst, bygger en strukturert oversettelseslast, og skriver resultatene tilbake inn på siden. Alle vanskelige kanttilfeller er automatiske: emoji-sekvenser, HTML-enheter, tegnsetting og mellomromsregler, blandede språkstrenger, og venstre-til-høyre / høyre-til-venstre bytting. Den omskriver også språkspesifikke skriptblokker — inkludertog andre strukturerte datatagger — og sikrer at hvert språk har korrekt, uavhengig, bufret metadata for søkemotorer og AI-systemer. -
Klientatferd.
Den gjengir språkflagg, respekterer usikre røtter, og spiller så trygt som mulig med enkelt-sides apper og rammeverk.
Alt dette kjører allerede på Jit-TR nettsteder i dag. Jit-Browser gjenbruker det enkelt i et kontrollert headless-miljø.
Hva som fortsatt trengs for en innebygd nettleserfunksjon
Hva som fortsatt trengs for en innebygd nettleserfunksjon
For å gjøre Jit-Browser til en innebygd nettleserfunksjon, trenger ingen et mirakel - bare evnen til å plassere et lite, veldefinert sett med endringer som nettlesermotorer allerede forstår.
For å gjøre Jit-Browser til en innebygd nettleserfunksjon. Dette er ikke et mirakel, bare et lite sett med endringer som nettlesere allerede forstår.
-
En innebygd hook i motoren.
I dag simulerer vi dette ved å injisere et skript fra headless Chrome. En ekte integrasjon ville gi Jit-TR en dedikert oversettelsesplass slik at den kan lese og skrive DOM-tekst på riktig punkt i gjengivelseslinjen. -
En standard måte å uttrykke språkintensjon.
Vi bruker allerede?jittr=LANGog informasjonskapsler. En nettlesernivåløsning kunne respektere nettleserspråkinnstillinger og brukervalg som "oversett alltid dette nettstedet til ES-419". -
En klar sikkerhets- og personvernsramme.
Reglene for hva tekst kan forlate enheten, hvor lenge den kan bufres, og hvordan nettsteder eller brukere kan velge bort, bør være klare og dokumenterte. En innebygd implementering inne i nettleseren kan faktisk være tryggere enn ad-hoc skript.
Eksempel: HarmonyOS i ES-419
Her er et konkret eksempel på pipelinen i aksjon.
Vi kaller:
getpageJtrBrowser \
"https://www.harmonyos.com/" \
"jittr=ES-419" \
null \
"ES-419/index.php"
Jit-Browser:
- Starter headless Chrome inne i Docker.
- Laster
https://www.harmonyos.com/. - Injiserer Jit-TR-snippet med ES-419 parameteren.
- Lar Jit-TR oversette den synlige kinesiske teksten til spansk (Latin-Amerika).
- Lagrer resultatet som
ES-419/index.php.
HarmonyOS-nettstedet trenger ikke å endres. Fra brukerens perspektiv ser det ut som om nettstedet ganske enkelt støtter språket deres.
Hvorfor denne siden eksisterer
HeadlessChrome101 er et sammendrag som viser:
- Vi bruker ekte nettlesermotorer og ekte CSP-regler.
- Vi har allerede en fungerende, proprietær oversettelsesruntime.
- Gapet som gjenstår til en innebygd nettleserfunksjon er lite og veldefinert.
Hvis du bygger nettlesere, operativsystemer eller store plattformer og ønsker et universelt flerspråklig lag som respekterer din sikkerhetsmodell, er vi klare til å prate. Koden eksisterer. Atferden er målbar. Neste steg er partnerskap.