摘要

  • RFC 9695 建立的是可路由的 haptics/* 媒体家族；它没有承诺接收端认识精确格式、保留全部效果，或让真实设备安全地产生发送者设想的触感。
  • 可审计的完成凭证必须把源文件哈希、未知值、设备适配、策略和限幅、执行器命令、停止与归零状态逐层绑定，不能只保存“播放成功”。

IANA 注册表能够回答 haptics/hjif 是不是一个登记过的名字。它不能回答佩戴者身上的某个执行器是否存在，能否在指定部位产生相应效果，是否把强度压低，甚至是否移动过。RFC 9695 把 haptics 注册为顶层媒体类型，并首先登记 IVS、HJIF 和 HMPG 三个子类型。顶层类型把内容送向触觉子系统及其硬件，子类型说明具体表示格式。

这是重要的公共协调层，但它只是入口。进入本地系统后，格式识别、参数解释、能力发现、设备映射、用户许可、安全限幅和驱动执行依次接管权力。同一个“成功”如果没有说明成功发生在哪一层，就可能把一份有效文件误写成一次有效的身体体验。

未知子类型并不只有一个结局

RFC 9695 规定，无法识别的触觉子类型应按 application/octet-stream 处理。这延续了 RFC 2046 的保守原则：不知道格式，就不要凭顶层名称臆造解释器。

但同一节也允许实现把未知子类型继续交给触觉子系统和相关硬件。原因并不神秘：前端可能不认识一种未来格式，插件、系统服务或外设却认识。这个安排给扩展留下空间，也让审计不能把“退回通用二进制”理解成“与物理输出隔离”。

因此必须保留两个独立决定。第一是媒体层决定：使用了哪个注册表版本，子类型是否识别，是否退回通用二进制。第二是应用层决定：文件被保存、下载、查找解码器、送入触觉服务，还是在完成识别前禁止执行。没有第二份记录，“不支持格式”仍可能掩盖一次向硬件方向的传递。

RFC 6838 管理媒体类型登记流程，RFC 9694 讨论为何新增斜线左侧的顶层家族极为罕见。那篇邻近议题拥有命名与治理问题。本文从命名已经完成之后开始：公共名字如何在本地执行链中逐层失去决定权。

忽略一个值，可能就改变了完整意图

RFC 9695 允许参数包含逗号分隔的多个子值。处理器如果认识参数却不认识某个子值，应忽略未知项，并继续处理认识的部分。对长期扩展而言，这是务实的兼容机制；旧实现不必因为新能力名称而拒绝整个对象。

问题在于，发送者可能把这些子值当作一组共同约束，接收者却把它们当成任选菜单。未知项若代表设备类别、身体位置、输出模态或限制条件，删除它以后，语法仍然有效，效果的含义却可能已经缩小。“处理完成”只证明剩余部分能够继续，不证明原意完整保留。

收据应逐项列出原始参数、识别的子值、忽略的子值、采用的默认值，以及最终生成的解码配置。还要记录软件版本，因为一次升级可能开始识别旧值，一次模块下线也可能让原本识别的值再次变成未知。只有文件哈希而没有运行时能力表，无法复现同一文件为什么在两天产生两条路径。

设备无关不是设备等价

IVS 是基于 XML 的设备无关交换格式。RFC 9695 同时明确：并非所有设备都能呈现其中全部效果。“设备无关”意味着内容不被某一个产品型号锁死，不意味着目的地会凭空长出缺失的执行器、温度通道或力反馈能力。

HJIF 用 JSON 描述具有时间与空间属性的触觉材料；HMPG 是二进制 MPEG 触觉格式。两者都可以把效果关联到身体部位，并可携带参考设备描述，让渲染软件把效果适配到真实硬件。适配不是透明转发，而是一次有取舍的转换。

参考设备若有八个分布式执行器，现实设备只有两个，空间扫动可能被合并为两次脉冲，也可能退化为一次整体振动。现实设备的输出范围更窄，幅度就会被压缩或截断；缺少相应模态，效果就会被删除；时间分辨率不同，事件还会被重新排程。两个实现都正确接受同一对象，身体得到的结果仍可能明显不同。

Apple Core Haptics 的官方资料提供了一个本地实现层的例子：系统区分瞬态与连续事件，提供强度、锐度等参数，并通过引擎和播放器连接触觉服务。应用还要检查硬件能力；AHAP 文件里缺失参数会采用默认值。这些资料不证明 Apple 支持 RFC 9695，只证明“格式被读懂”之后仍存在能力、默认值和设备的本地决策层。

“媒体”分类不是安全证书

RFC 登记把这些格式归为媒体，而不是可执行代码。分类有助于选择处理模型，却不会让解析器消失。XML、JSON 和二进制结构仍要经过库、内存管理、用户态服务以及某些实现里的驱动或内核路径。恶意描述数据可以利用实现漏洞，而无须自称程序。

即使解析器完全正确，物理风险仍单独存在。触觉设备可能输出振动、动觉力、温度或纹理感。RFC 9695 特别提示，如果热学或动觉设备缺少约束，可能造成伤害。文件大小限制不能代替振幅、力、温度、持续时间、变化速率和重复暴露限制。

所以要有两套安全账本。软件安全账本覆盖结构校验、资源消耗、隔离、解码器和驱动；物理安全账本覆盖真实设备能力、用户同意、本地限幅、停止路径、归零状态和累计暴露。一个账本通过，不能替另一个签字。

W3C Vibration API 展示了另一类本地准入：浏览器可以根据文档可见性和 Permissions Policy 限制振动。它与 IVS、HJIF、HMPG 并非同一种格式，也不构成 RFC 9695 支持证据。它说明的是架构事实：合法请求可以被上下文策略拒绝，这个拒绝应与解析失败、硬件缺失分别记录。

从请求效果到实际命令，要做四次对账

第一份清单是对象要求的效果：时间、空间、身体部位、强度、力、温度以及参考设备。第二份清单是解析器真正理解的效果，其中要标出未知和默认。第三份清单是适配后可由真实设备实现的效果，列出合并、移动、压缩、截断和删除。第四份清单是经过许可、系统策略和安全限幅以后真正发给驱动的命令。

这四份清单的差异才是“触觉播放”的核心证据。随后还要保留执行器确认、错误状态、停止命令和归零证明。即使如此，命令记录仍不等于力或温度测量，物理测量也不等于人的主观感受。若要声称用户体验，必须另外说明传感器、实验条件和报告方法。

当前 IANA 媒体类型注册表 能证明名称状态。RFC 9993 更新了 haptics/hmpg，并定义 MPEG-I 触觉数据的 RTP 分片、聚合和 SDP 参数。那是传输与会话层：完整重组媒体单元是必要条件，但仍不能证明接收端保存了效果，或硬件安全执行。

Lu Heng 的最小初始规范原则正适合这条边界。公共层只标准化互操作所必需的名称、子类型、参数语法和基础退回行为；能力、适配、同意、限幅与未来模态留给本地决定。现实层纪律要求把 IANA 登记、Content-Type、解析结果、适配转换、驱动命令、物理测量和人的感受分开。运行代码优先则要求以这一台端点的实际收据为准，不能让标准允许什么替代设备做了什么。

来源