Google ofertas la API de Google Translation kun uzokostita kostostrukturo kiel parto de sia Google Cloud. Ekzistas ankaŭ nedokumentita API uzebla sen ŝlosilo , sed kiu rifuzas funkcii post nur kelkaj petoj. Kiam vi uzas la retejan tradukan funkcion de Google Chrome, rimarkeblas, ke paĝoj povas esti tradukitaj tre bonkvalite sen rimarkinda limigo.
#000000
Ŝajne la altnivela nmt-modelo jam estas uzata ĉi tie. Sed kiun API Google Chrome uzas interne por traduki la enhavon kaj ĉu ĉi tiu API ankaŭ povas esti traktita rekte - eĉ ĉe la servila flanko? Por analizi retan trafikon, iloj kiel Wireshark aŭ Telerik Fiddler , kiuj ankaŭ povas analizi ĉifritan trafikon, estas rekomendindaj. Sed Chrome eĉ liveras la petojn, kiujn ĝi sendas por la paĝa traduko senpage: Ili facile videblas per Chrome DevTools:
#000001
Se vi efektivigas tradukon, tiam kaptu la decidan POST-peton al per "Kopii> Kopii kiel cURL (bash)" kaj plenumi ĝin per ilo kiel Poŝtisto , ekzemple, vi povas sendi la peton denove senprobleme.:
#000002
La signifo de la URL-parametroj ankaŭ estas plejparte evidenta:
#000003
Iuj petaj titoloj ankaŭ estas agorditaj - sed ĉi tiuj plejparte povas esti ignorataj. Post permane malelektado de ĉiuj kaplinioj, inkluzive de tiuj de la uzanto-agento , koda problemo estas malkovrita kiam vi enigas specialajn signojn (ĉi tie kiam tradukas " Saluton Mondo "):
#000004
Se vi reaktivigas la uzantan agenton (tio ĝenerale ne damaĝas), la API liveras koditajn signojn UTF-8:
#000005
Ĉu ni jam estas tie kaj ĉu ni havas ĉiujn informojn por uzi ĉi tiun API ekster Google Chrome? Se vi ŝanĝas la tradukindan ĉenon (datuma kampo q de la POST-peto) de, ekzemple, "Saluton mondo" al "Saluton mondo ! “, Ni ricevas erarmesaĝon:
#000006
Ni nun tradukas ĉi tiun modifitan denove ene de Google Chrome per la retejo-traduko-funkcio kaj trovas, ke krom la parametro q , la parametro tk ankaŭ ŝanĝiĝis (ĉiuj aliaj parametroj restis samaj):
#000007
Evidente, ĝi estas signo, kiu dependas de la ĉeno, kies strukturo ne facile videblas. Kiam vi komencas la retejan tradukon, la jenaj dosieroj estas ŝarĝitaj:
#000008
1 CSS-dosiero: translateelement.css4 grafikaĵoj: translate_24dp.png (2x), gen204 (2x)2 JS-dosieroj: main_de.js , element_main.js
#000009
Nun ni povas elpurigi la kodon ( CORS unue devas esti aktivigita sur la loka servilo). La koncerna koda sekcio por generi la ĵetonon ŝajnas esti kaŝita en la dosiero element_main.js en ĉi tiu sekcio:
#000010
Ĉi tie la teksto estas hakita kun la helpo de iuj pecŝanĝoj . Sed bedaŭrinde ankoraŭ mankas al ni unu peco de la enigmo: Krom la argumento a (kiu estas la tradukota teksto), alia argumento b estas transdonita al la funkcio Bp () - speco de semo, kiu ŝajnas ŝanĝiĝi de tempo al tempo kaj kiu ankaŭ inkluzivas fluas en hakadon. Sed de kie li venas? Se ni saltas al la funkcio alvoko de Bp () , ni trovas la sekvan kodosekcion:
#000011
La funkcio Hq antaŭe estas deklarita jene:
#000012
La Deobfuscater lasis iom da rubo ĉi tie; Post kiam ni anstataŭigis String.fromCharCode ('...') per la respektivaj signokordoj , forigu la malnoviĝintan a () kaj kunmetu la funkciojn nomas [c (), c ()] , la rezulto estas:
#000013
La funkcio yq estas antaŭe difinita kiel:
#000014
La semo ŝajnas esti en la tutmonda objekto google.translate._const._ctkk , kiu haveblas dum rultempo. Sed kie ĝi estas metita? En la alia antaŭe ŝarĝita JS-dosiero main_de.js, almenaŭ ĝi ankaŭ haveblas komence. Ni aldonas jenon komence:
#000015
En la konzolo ni efektive ricevas la nunan semon:
#000016
La variablo kun la URL estas malfacile difinita en la sama dosiero:
#000018
Se ni nun ekzamenas la dosieron element.js pli atente (post malfokusigi ĝin denove), ni trovas la malfacilan eniron c._ctkk - la google.translate- objekto ankaŭ estas agordita laŭe kaj la ŝarĝo de ĉiuj koncernaj aktivaĵoj (kiujn ni jam malkovris antaŭe) ekas:
#000019
La ŝlosilo estas generita en google_apis / google_api_keys.cc de imita valoro:
#000021
Tamen testo montras, ke la API-vokoj funkcias same sen ĉi tiu ŝlosila parametro. Se vi eksperimentas kun la API, vi ricevos la statan kodon 200 se vi sukcesos. Se vi tiam renkontas limon, vi reakiras la statan kodon 411 kun la mesaĝo " POST-petoj postulas enhavan longan kapon ". Tial estas konsilinde enmeti ĉi tiun kaplinion (kiu aŭtomate estas agordita kiel portempa kaplinio en Poŝtisto).
#000022
La revenformato de la tradukitaj ĉenoj estas nekutima kiam estas pluraj frazoj en unu peto. La unuopaj frazoj estas enfermitaj per la i- / b-HTML-etikedoj:
#000023
Ankaŭ Google Chrome ne sendas la tutan HTML al la API, sed konservas atributajn valorojn kiel href en la peto (kaj anstataŭe starigas indicojn por ke la etikedoj estu poste atribuitaj al la klienta flanko):
#000024
Se vi ŝanĝas la valoron de la kliento POST- kliento de te_lib (Google Chrome) ĉe retapo ( retejo de Google Translation ), vi ricevas la finan tradukitan ĉenon:
#000025
La problemo estas, ke vi multe pli ofte ekhavas rapidecon-limigon ol per te_lib (por komparo: per retapo ĉi tio atingiĝas post 40 000 signoj, kun te_lib ne ekzistas tarifo-limigo). Do ni devas rigardi pli proksime kiel Chrome analizas la rezulton. Ni trovos ĝin ĉi tie en element_main.js:
#000026
Jen la rezultoj de komenca testo, kiu estis farita sur kvin malsamaj sistemoj kun malsamaj bendolarĝoj kaj IP-adresoj:
#000027
Noto: Ĉi tiu bloga afiŝo kun ĉiuj skriptoj estis verkita nur por testaj celoj. Ne uzu la skriptoj por produktivaj uzo, anstataŭ labori kun la oficiala Google Tradukado API .
#000028
GitHubTwitterPinboardPinterestYouTubeButikvaroSpotifyDribbbleLinkedInXingPGPValidigo de markado de W3CGugla Lumturo
#000030