问题起源

在几天之前,我的命令行翻译程序挂掉了,不过由于平时用的也少,所以就没太管,昨天才想起来再找个 API 用。

正如前文所述,我极少用到这个,所以我就懒得去申请腾讯、彩云或是 bing 的 API,毕竟太麻烦了。因此我决定找一个直接提供公用接口的 API,次数限制啥的只要不是太离谱就行。功夫不负有心人,在 Google 上翻了两页之后,我找到了由 厦门大学自然语言处理实验室 提供的 云译 CloudTranslation 的公开 API

解决过程

就当我读完短短的 API Doc 后准备开始写段小脚本时,悲剧发生了:它竟然乱码了!

图中的 Content 与 RawContent 都是乱码的
图中的 Content 与 RawContent 都是乱码的

然后我也很不能相信,于是又回去读了读文档,看到其中清楚地写着:

返回格式: UTF-8 编码纯文本

WHAT THE F@XK? 我的 Windows 系统一直都是默认 unicode 的,而当前 pwsh 的活动代码页也是 65001。换言之,这个接口的返回值乱码绝对不是本地是 gbk/gb2312 这种低级错误。那问题出在哪呢?

为了确定它返回的编码确实是 utf-8,我看了看它的 headers,以防出现他本身发送的是 gbk/gb2312 这种乌龙。

通过 乱码恢复 确定了乱码文字现在的编码是 iso-8859-1,其本身确实是 utf-8 的。

看起来并没有问题
看起来并没有问题

打眼一看确实没啥问题,但我注意到了其中并没有指定 charset/encoding 信息。

以防万一,我又在 wsl 中用 curl 对比执行了一下:

完 全 正 常
完 全 正 常

此时我已经基本确定,乱码是因为 headers 中缺了东西导致的,但为什么会导致这种问题呢?我想让他不乱码难道就只能通过 wsl 来调用 API 了么?

然后通过我西安市 top3 的信息检索能力的 Google 技术,找到了这个 StackOverflow 回答:

The problem is that Spotify is (unwisely) not returning the encoding it’s using in its headers. PowerShell obeys the standard by assuming ISO-8859-1, but unfortunately the site is using UTF-8. src

即一则网站未按规范在 headers 中指定编码信息;二则 powershell 遇到未指定编码的内容时,会假设其编码为 ISO-8859-1,问题就这样出现了。

想要解决也很简单,把内容从 ISO-8859-1 编码转换回 utf-8 即可。

等等,还有一个问题

命令行中的问题解决了,浏览器中的呢?

如果在浏览器中打开 此示例,浏览器中的内容会是 绁炵粡鏈哄櫒缈昏瘧,是被错误以 gbk 解码而出现的乱码,这个问题在 chromium 与 firefox 上都会出现。

然而在开发者工具的 network 中查看时,其响应会是正常的。时间与才学所限没能细看 chromium/firefox 的源代码,希望有朋友知道的话能指教一二(可看关于页中我的联系方式)。