在github上找到了近期相关问题4天前的讨论，edge(bing)修改了调用TTS的方案，需要加自定义请求头header，外部词典没有也无法随意加。我自己也测试了一下，wss请求会一直报403，以前的请求链接，服务器已经拒绝接受了。看看后续讨论还有没有什么巧思。
这几天时好时坏。。。
1 个赞
英语tts轻量好用的多了去了，可以本地部署一个kokoro。
edge的tts已经过时了，index tts\x tts等开源tts对英语支持都很好，和真人录音差别对一般的学习者已经不大，各家词典应该也会很快用起这些新型的tts。
1 个赞
真正的原因在于中美间的网络路由调整，导致时好时坏，这些在线语音，全是直接抓取的美国服务器上的内容。
1 个赞
好像是这样的，我试了下，挂代理就好了
我这会挂梯子也可以，问题就是edge本身倒是没毛病，不知道是否挂了独立的服务
我也在考虑更换，后来看到bing TTS是嵌入到js中的调用，部署繁琐。如果是其它备选TTS，可以便利部署在牛津高阶10里吗？
上一条没理解，现在明白了，指的是全局TTS，确实是最好的方案了。我一会研究搞一个，对比欧路自带的TTS的效果。另外内置词典的TTS确实用着方便，一键点击式的。
研究了一会，不是GFW的问题，是微软加强了对中国大陆地区的风险管控
解决方案：js中搜索speech.platform.bing.com替换为tts.knitsky.com
6 个赞
感谢k兄，成功。
原理是绕过SecMsGecToken的代理接口吧？这个knitsky是什么神仙网站，谷歌和github也搜不到相关信息，方便告知怎么找到的吗？
我不懂这个
我这个原理是用cloudflare的workers中转请求，过程中修改了请求的headers
（knitsky是我自己的域名）
原来如此，和1楼放的那条做法是一致的
1 个赞
我也部署了一个转发bing speech的链接，具体方案和参考项目介绍给大家。除了搭建cloudflare转发平台worker外，还需要在worker中配置请求协议转换的js代码，用来完成词典原wss链接解析重建为新https请求体并封装新header的工作。请求协议转换github项目我放下面，新header的配置参考2#。
1 个赞
其实安装 这个 帖子 中的 NaturalVoiceSAPIAdapter 就可以在只要是使用了chrome内核的应用(比如 goldendict-ng)中，离线或者在线调的调用微软的那些自然语音tts朗读句子了，调用的js的 speechSynthesis api 。当然不安装也可以，只是自带的效果不太好就是。
确实是Windows下的好方案，移动设备上只能使用在线调用了。
哦，对，跨平台的话确实不太好弄，特别是手机上那自带的tts简直了。。。。。。