FAQ

常见问题解答

为什么 artyom 无法在本地文件工作？

Artyom 无法于 file:// protocol 环境下使用

Chrome 于 file:// 协议上屏蔽了许多内容，其中就包含了 webkitSpeechRecognition ，所以你无法在 window 中获取到这个属性。

你最好的选择（如果你没有服务器或者 Github 页面）是启动一个本地 webserver 运行 artyom， 或者通过增加 Chrome 启动参数 --allow-file-access-from-files。

浏览该页面获取更多可能的解决方案

为什么 voice 命令无法在 jsfiddle 上正常使用?

Artyom 无法在注入脚本中使用。

由于安全原因，Artyom.js无法在注入脚本上运行。如果没有该安全屏蔽，speech recognition 将成为不安全连接（http）的危险后门。

虽然大多是使用 Speech Recognition API 的方式都不会涉及注入脚本。JSFiddle 将脚本注入到 Iframe 中的方式进行工作，但在这种场景下，Speech Recognition 无法正常工作。你需要通过伺服于 http 或 https 链接的文件使用 webkitSpeechRecognition。

为什么在移动设备上，artyom.say (speech synthesis) 使用原生语音进行发音？

speech synthesis 需要使用浏览器语音的语音标识符进行初始化。但是语音标识符命名法并不存在统一标准。

从 artyom v1.0.3 版本之后，可以对移动设备的 speech synthesis 语言进行修改，其默认值为 （en_US, en-US）。如果设备仍然使用原生语言，你需要在源码中修改 voice 的变量。

如果你已经在移动设备中使用了 Artyom， 你可能已经发现 Voice synthesis 在移动版 Chrome 中的表现与 桌面版 Chrome 中的表现不太一致。个中缘由十分简单，然而官方并不准备给出解决方案去修复之，并强调只有在桌面版本的 Google Chrome 中 Artyom 才能绝对正常地使用。

为什么桌面版和移动版的Chrome中Artyom表现并不一致？

如果你在桌面版的 Google Chrome 中使用下述代码获取 voices 属性

console.log(artyom.getVoices());

你会得到下述结果

Google US English, Google Deutsch, Google español

这些语种的名字在所有语种的桌面版Chrome 上总是一致的，然而如果你在移动设备上进行同样的操作，你会得到与上述不一样的结果，比如:

english USA, german GERMANY, español ESPAÑA

在其他设备中，结果则可能是

en_US, de_DE, es_ES

理论上来说，我们只需要所有语种的对应编码和浏览器编码记录下来，那么这就不再是一个问题（理论上）。然而，这个方案只能在英语作为当前语种的设备上生效，比如一台位于德国的设备，上述代码的可能输出是：

englisch Vereinigte Staaten, deutsch Deutschland, Spanisch Spanien

尝试去对各个国家地区，各种名称识别器，并对各种设备及各种语言进行统一的适配，毫无疑问会大量增加 artyom 作为一个工具包的大小，更何况可能这样的适配可能并不能一本万利。

如果你尝试对某些特别的设备进行支持（设备的所选语种已知，语种对应代码已知），那你可以fork artyom.js 的项目并使用所需设备的语种代码编辑源码中的artyomLanguages variable。

兴许未来的版本中我们会提供一个方法支持自定义语言名称识别器，而不需要你再创造一个只属于你的 artyom.js

(截止到2019年第四季度并没有)

这样的现象对于 command recognition 也存在吗？

并不会，Speech Recognition 拥有特定的语种代码，并且其并不依赖于浏览器，相关信息将会发送给 Google 服务器进行处理，而不是浏览器本地。