上回书说的是小程序【BugOSC】与PC软件交互的全过程
上次教程里留了1%没讲，在小程序BugOSC里通过中文语音识别后得到的中文字符，进行OSC传输时需要编解码，否则接收端会显示为乱码。
因为OSC1.0的协议规定，只支持最基本的ASCII，不支持Unicode即中文、日文等字符。
毕竟OSC多用在交互的场合，大部分时候用来做控制指令，或者传输参数的具体数值，用到中文日文等场景相对较少。
这里强行插入一个用BugOSC语音识别中英文，并用Blender可视化的demo，观众先热热身。
小程序语音识别及Blende可视化https://www.zhihu.com/video/1228757696679079936
BugOSC打包封装数据用到了OSC.js这个库，它遵循的就是OSC1.0的协议，只支持最基本的ASCII，简单说就是26个英文字母、数字及一些字符。
而BugOSC还是可以传输中文的，这是因为在传输前对中文做了编码，把中文用一串有规则的英文字母数字及符合来表示；
相应的你的接收端，需要做解码，用同样的规则，把这串英文字母数字符号还原成中文。
这里用的是很常规的编解码方式，大部分编程语言或软件都有现成的解决方案，也很简单。
例如JavaScript里，编码就一句：encodeURI()解码也是一句:decodeURI()
关于字符编解码的详细介绍，推荐维基百科上的定义，或者Google这几个关键词：URI，Unicode，UTF-8，ASCII。
通过编解码的方式，就可以用BugOSC愉快的进行中文语音识别和传输了。
下面用MaxMSP演示如何接收BugOSC的中文字符并解码：
如上图所示，收到的字符串，未解码前，是这样的：
%E6%B2%A1%E5%90%83%20%E5%9B%9E%E5%AE%B6%E5%90%83%E5%8E%BB%E5%90%A7%20
通过decode.js解码后，得到：
没吃 回家吃去吧
流程演示完毕，就这么简单。
负责具体解码过程的decode.js也很简单：
顺便附上一个说明，刚才解码后得到的语句是：
没吃 回家吃去吧
实际上语音识别引擎识别后的原文是含有标点符号的：
没吃，回家吃去吧！
BugOSC在传输语句时，自动过滤了标点符号，因为由引擎生成的标点符号目前生成规则不太可控，尤其末尾的句号感叹号问号。
为了方便在接收端直接将字符串结果做 if else 比对，过滤掉了标点符号。
但是我留下了空格，用意是方便一开始在熟悉语音识别特性的时候，分辨连读与间隔的区别。
如果对这方面有更好的建议，欢迎反馈！
扩展
OSC接收端对中文要额外做解码，总觉得有一点不方便。
其实OSC在1.x之后的版本，协议Spec做了扩展，支持了Unicode字符串。
很多语言的库也相应做了扩展，直接拿来使用就好。甚至你手头的OSC插件，可能本身就是可以正常收发中文的。
但是BugOSC的OSC封装部分由于使用了OSC.js，遵循的是OSC 1.0的协议，所以使用BugOSC的时候，接收中文要做decodeURI解码（好尴尬）。
如果你的软件有解码插件或内置了解码功能，或总之能正常接收显示BugOSC发出的中文，烦请给我留言。
另外，解码的程序逻辑里无需对英文和中文区别对待，统一做解码处理就好。
中文通过解码会正常还原，而英文即便做一次解码仍然是原有英文保持不变。
正所谓你大妈已经不是原来的大妈了，你大爷还是你大爷。
