我们也有这个问题。翻译器的 v1 似乎已停产(或停止服务)。但是 API 的 v2 有效。
我猜您使用的身份验证形式只需要您的 MS 数据市场帐户密钥(在此处找到的密钥:https ://datamarket.azure.com/account/keys )。
使用这种形式的身份验证,您可以使用类似于以下的代码进行翻译:
Microsoft.TranslatorContainer xlator = new Microsoft.TranslatorContainer("https://api.datamarket.azure.com/Bing/MicrosoftTranslator/v1/Translate");
xlator.Credentials = new NetworkCredential("account key, "account key");
DataServiceQuery<Microsoft.Translation> xlateQry = xlator.Translate("translate me", "en", "fr");
Microsoft.Translation xlateResult = xlateQry.Execute().First();
translateOutput = xlateResult.Text;
Microsoft 命名空间中的 TranslatorContainer 和 Translation 类来自 MS 在第一版翻译中提供的生成代码。
这就是我们所做的,昨天它也停止了对我们的工作。似乎 MS 已经强行(并且秘密地 AFAIK)停止了这种形式的身份验证,转而支持他们更新的身份验证方案和 API。值得注意的是,从 MS translate API 主页导航时,您将无法再访问 API v1 的文档。
但是,我能够在这些 URL 上按照 API v2 的说明使用我现有的帐户成功创建临时 HTTP 翻译请求:
使用 HTTP 接口
获取访问令牌
查看“获取访问令牌”时,请转到特定 URL 的底部 PowerShell 示例,并记住使用 POST 获取身份验证令牌并使用 GET 获取翻译请求。还要记住对身份验证令牌请求使用 url 编码参数。我之所以这么说,是因为在使用 Chrome 中的 PostMan 处理临时请求的示例时,这些都是让我感到困惑的事情。
很可能这种转变是有据可查的,但是对于像我这样的一些可怜的 sap 来说,他们继承了一个使用翻译 API v1 的应用程序,看起来 MS 只是让每个使用 v1 的人都冷落了,因为它不是在浏览翻译 API 文档时很明显,甚至有 2 个版本,更不用说将停产的版本了。