Summary

  • Web MIDI 让网页应用发现 MIDI 输入、输出端口，接收键盘动作，向合成器或灯光设备发送消息。MIDI 传的是音符、控制器和节拍等事件，不是扬声器里的声音。
  • 端口身份会透露使用者的设备组合；System Exclusive（SysEx）还能进入厂商自定义的设备功能。标准因此把普通 MIDI 与 SysEx 分成两级权限。

一台老键盘为什么值得接到浏览器？因为它的琴键、旋钮和手感都还在，网页软件却可以随时换。W3C 的 2012 年草案 给出了桥梁：列出输入和输出端口，收发 MIDI 消息，让键盘、鼓机、合成器乃至舞台灯光与网页应用说话。这里有个容易闹笑话的误会：MIDI 不运送声音。按键传来“某个音符开始了”，真正发声的仍是合成器。网页可以当指挥，不能因此自称交响乐团。

这个设计的好处在于克制。浏览器无须判断某个旋钮是加颤音、调亮灯，还是让鼓手突然紧张。它只负责把设备的消息交给应用，把应用的消息交给设备。应用和演奏者自己决定含义。同一条通道能管音乐，也能管灯光，正因为浏览器没有硬塞一套“音乐理论”给所有机器。

但“找到设备”本身就是一件有分量的事。早期草案给端口设计了可持续识别的 fingerprint，方便应用下次启动还认得同一把键盘。在摆着几台相似设备的录音室，这很实用；在好奇的网站眼里，这也是设备清单的线索。厂商、名称和版本也属于端口信息。草案已经把枚举端口和特殊消息的隐私、安全问题摆上桌面。要让程序记住自己的琴，便得考虑谁还会翻看这本器材簿。

真正需要另一把钥匙的是 System Exclusive，简称 SysEx。普通消息叫乐器弹一个音、改一个控制值；SysEx 可以说厂商自己的语言，查询或改动音色、配置等设备特有的数据。两种请求不能混成一句“我要用 MIDI”。2015 年草案 把区别写进 requestMIDIAccess({sysex:true})。额外能力若遭拒绝，请求就会失败。想弹琴可以谈弹琴；想打开设备背后的抽屉，得把话说清楚。

这道门还有日常脾气。设备会在演奏中被拔掉；音符有发送时间，晚半拍可不是网页加载图标那种小事；一个应用还可能嵌在别人的页面里。接口因此要处理端口状态和定时发送，却把“这个按钮在这首曲子里代表什么”留给应用。浏览器修的是交通规则，曲谱归乐手。

2026 年 10 月 20 日的 W3C 草案 把门牌写得更清楚。权限名是 midi，其中 sysex: true 比普通访问更强；没有这项许可，发送 SysEx 会抛错，收到的 SysEx 也会被屏蔽。requestMIDIAccess() 属于安全上下文。Permissions Policy 对 midi 的默认允许列表是 'self'，所以嵌进页面的小框架不能顺手领走录音室钥匙。草案还讨论设备特定消息可能造成的硬件风险，那是对攻击路径的分析，并非每台合成器都曾遭遇袭击的新闻。

翻看 W3C 的发布记录，2012、2013、2015 年有草案，2024 至 2026 年又密集修订。日期说明标准文本何时公开，不会自动告诉我们所有浏览器何时一齐支持。多年没变的难题倒很具体：网页要借用真人的乐器，但网页不该因此拿到整个房间的万能钥匙。

乐手再按一次中央 C。消息过去，合成器回话。旧键盘依旧是旧键盘，网页成了好用的连接线。门卫也没有妨碍演奏：他只是把设备内部抽屉的钥匙留在了乐手手里。