@
XIU2 #57 #58 做个最后总结吧!
Chrome 内置全页谷歌翻译,其实并不是完全不受扩展控制,准确来说是:
一部分不受扩展控制走直连(但受系统代理设置控制),一部分则可以正常受扩展控制走代理。
打开浏览器后,第一次访问其他语言的网页时(即右上角提示翻译,但你还没有去点击翻译),浏览器就会访问一次 translate. googleapis. com 来获取什么,而这次访问是不受浏览器扩展控制的。
也就是,浏览器监测到网页语言不一样时,就会去不受扩展控制的强制直连访问一次 translate. googleapis. com ,后续在浏览器关闭之前就不会再这样做了,因此只要这一次强制直连访问成功,那么后续进行翻译都可以由扩展控制走代理或重定向了。
而一些人之所以会出现明明手动访问 CSS/JS 等静态文件可以正常走代理 /重定向,但依然无法翻译的情况,就是因为这个 Chrome 强制直连的链接没有被重定向导致的,而另外一批成功翻译的人,其实就是因为这次强制直连因为某些原因访问成功了,所以后续的翻译请求才会被重定向至国内 CDN 加速地址。
——————
在 Chrome 浏览器中点击 翻译 选项后的流程逻辑是:
(注意,只有强制直连那次访问成功,浏览器才会进行下面这些的步骤环节)
1. 浏览器加载翻译所需的静态文件( JS/CSS 等)
2. 由刚刚加载的 JS 脚本发起 POST 翻译请求并处理
而这两个环节产生的网络链接都能正常受扩展控制,可以走代理或被重定向。
——————
我前几天写的这个教程,就是依靠扩展把 translate. googleapis. com 重定向至 gtranslate. cdn. haah. net ,结果评论区 /私信中,有大量用户反馈依然不行,但是也有部分人反馈可以,这种奇怪的现象迫使我仔细研究了一番 Chrome 的翻译机制,才大致搞明白了,确实挺奇葩的,我也想不明白,为什么 Chrome 浏览器要这样做,而且还是内核中写死的。。。
https://zhuanlan.zhihu.com/p/576290326现在想来,我之所以能重定向成功,就是因为当初测试效果时,我的 Hosts 文件中已经加的有将其指向可用的谷歌国外 IP 的内容了,而我当时还不清楚这么多弯弯道道,以为只靠扩展重定向就完美解决了,还很兴奋的第一时间熬夜写教程,结果第二天大量用户在评论区反馈不行。。。搞得我就很尴尬,刚才我又重写了这篇文章教程,这次应该没啥问题了~
想要验证这点也很简单,只需要在 Hosts 中将 translate. googleapis. com 指向一个不可用的错误 IP 并重启 Chrome 浏览器(刷新缓存),然后再去尝试翻译,就会发现翻译失败了。
而一旦指向一个可用的 IP (我用的是谷歌国外 IP ),那么翻译时就能在 F12 - NetWork (网络)中看到发起的 POST 翻译请求被扩展控制走了代理 /重定向(如果是前面那样将其指向不可用的错误 IP ,那么这种情况下尝试翻译,会发现 NetWork 看不到任何 翻译请求 的网络链接信息)。
——————
以上就是我这两天,断断续续抽空研究的成果(非专业,只是根据各种测试、抓包来判断)。
毕竟我既然发了文章教程,就要负责到底,熬夜写半天结果搞出个有缺陷的教程那就是在太亏了,而且还每天一群人评论区 /私信反馈说用不了来 “打我脸” ,属实把我搞烦的不行。。。
迫使我研究了一番,并重写了一下这个文章教程才终于舒服一点了~