NDEF 协议

"NDEF"协议是一种直接与通过 NFP 提供程序 pub/sub 模型映射的 NFC 论坛设备交互的方式。 使用此协议的任何客户端都需要了解如何对 NDEF 数据包进行编码和解码。 对于发布消息,客户端只会将类型指定为"NDEF",因为其余类型信息嵌入在 NDEF 消息本身中。 发布"NDEF"类型允许客户端进行几乎直接的直通访问,以通过 NFC 发送 NDEF 消息。 若要订阅,客户端将指定"NDEF",后跟":" (冒号) 。

冒号后是六种记录类型之一。

  • 内线
  • MIME
  • URI
  • wkt
  • 未知

提供程序遵循本部分中列出的基本提供程序要求以及特定于 NDEF 协议的要求,支持 NDEF。

为了侦听这些 NDEF 消息,客户端订阅支持的类型之一,例如"NDEF:wkt"。Sp"。 每当提供程序检测到与类型匹配的 NDEF 消息时,整个 NDEF 消息 (仍编码在 NDEF) 发送到订阅客户端。 根据 [NDEF] 中的约定,要匹配 NDEF 消息的"type"是在 NDEF 消息的第一条 NDEF 记录中指定的 TYPE 字段。 同样,为了传输 NDEF 消息,客户端将发布指定"NDEF"协议的完整 NDEF 消息。

还有一种订阅所有 NDEF 消息的机制;这是通过订阅"NDEF"完成的。

常见的 NDEF 协议驱动程序要求

在所有支持 NFC 的 NFP 提供程序的驱动程序上,NDEF 支持有几个常见的要求。

必需的措施

  • 根据 [NDEF] 中指定的 NDEF 消息中第一条 NDEF 记录的 TNF 和 TYPE 字段,驱动程序必须将收到的 NDEF 消息与订阅匹配。
  • 如果启用了一个或多个"*:WriteTag"发布,并且驱动程序检测到具有足够可用空间的可写标记,则出于匹配其他订阅的目的,不得读取标记的现有有效负载。 这样,标记写入应用可以抢占可能订阅标记上消息的其他应用或服务。
  • 对于支持 NFC 的 NFP 提供程序,连接到 NFC 论坛设备时,驱动程序不得传输"*:WriteTag"发布 (而不是 NFC 论坛标记) 。
  • 如果在驱动程序检测到具有足够空间的可写标记时启用了一个或多个"*:WriteTag"发布,则驱动程序必须恰好将一个有效负载写入标记。 o 如果多个发布处于活动状态且足够小,足以写入标记,则最近创建或启用的"*:WriteTag"发布必须是写入的发布。
  • 如果在驱动程序当前与具有足够可用空间的可写标记通信时创建或启用"*:WriteTag"发布,则驱动程序必须将有效负载写入标记,即使驱动程序以前写入标记。
  • 驱动程序必须以覆盖以前内容的方式写入标记。
  • 如果成功将"*:WriteTag"有效负载写入标记,驱动程序必须触发 IOCTL_NFP_GET_NEXT_TRANSMITTED_MESSAGE 处理 (,) 发布。

"NDEF:WriteTag"的发布

这是一种特殊类型的发布,允许将一个或多个 NDEF 消息写入 NFC 论坛标记。

必需的措施

  • 其他位置所述的常见"*:WriteTag"要求适用。
  • 由于 NFC 论坛标记可以包含多个 NDEF 消息,因此驱动程序必须正确接受"NDEF:WriteTag"发布,这些发布正好具有多个串联的 NDEF 消息作为有效负载。

"SetTagReadOnly"的发布

此发布允许客户端将标记锁定为只读。 提供程序必须将已格式化的 NDEF 读/写标记转换为只读。

必需的措施

  • 驱动程序必须先检查连接的标记是否符合 NDEF。
  • 如果一个或多个"*:"。WriteTag"发布已启用,驱动程序检测到可写标记,驱动程序必须先写入标记,并遵循其他位置所述的常见"*:WriteTag"要求,然后将 NDEF 读/写标记转换为只读。

空 NDEF 记录:"NDEF:Empty"

此消息中没有任何类型、ID 或有效负载。 从客户端的角度看,具有"NDEF:Empty"类型的订阅似乎Windows意义。

必需的措施

具有此类型的订阅或发布必须由具有此类型的邻近提供程序驱动程序STATUS_INVALID_PARAMETER。

所有 NDEF 类型的订阅:"NDEF"

客户端可以订阅所有收到的 NDEF 消息。 通常,如果应用程序知道它感兴趣的消息类型,它将专门订阅该类型。 但是,订阅每个 NDEF 消息有时很有用。 例如,可以复制和写入重复 NDEF 标记的应用程序可能会发现这很有用。

必需的措施

驱动程序必须将"NDEF"的订阅与它收到的每个 NDEF 消息匹配。

外部 NDEF RTD 类型的订阅:"NDEF:ext."

供应商可以使用自定义可扩展 RTD 命名空间来定义其专有消息的内容。 这样,客户端可以订阅不是由 NFC 论坛定义的 RTD 外部类型,而是由应用或第三方定义的。

泛型示例类型:"NDEF:ext.<SomeExternalType>"

具体示例类型:"NDEF:ext.contoso.com:mytype"

必需的措施

驱动程序必须与"NDEF:ext.<SomeExternalType>"仅适用于收到的 NDEF 消息,这些消息的 TNF 字段值为 0x04,<并且 TYPE 字段基于 [NFC RTD] 中指定的等效规则与"SomeExternalType>"匹配。

"NDEF:MIME"的订阅。

消息可以使用 MIME 命名空间来定义消息的内容。

泛型示例类型:"NDEF:MIME。<SomeMimeType>"

具体示例类型:"NDEF:MIME.image/jpeg"

必需的措施

驱动程序必须与"NDEF:MIME"的订阅匹配。<SomeMimeType>"仅适用于收到的 NDEF 消息,这些消息的 TNF 字段值为 0x02,并且具有基于 [NDEF] 中指定的等效规则与"SomeMimeType>"匹配的 TYPE< 字段。

"NDEF:wkt"的订阅。

消息可以使用 NFC 论坛已知类型命名空间来定义消息的内容。

必需的措施

  • 驱动程序必须与"NDEF:wkt"的订阅匹配。<SomeWellKnownType>"仅适用于接收的 NDEF 消息,这些消息的 TNF 字段值为 0x01,<并且 TYPE 字段基于 [NDEF] 中指定的等效规则与"SomeWellKnownType>"匹配。
  • 驱动程序不得验证已知类型,以便 NFC 论坛无需更新驱动程序即可定义将来的已知类型。

未知 NDEF 类型的订阅:"NDEF:未知"

这允许客户端订阅数据的非类型有效负载。

必需的措施

驱动程序必须与 TNF 字段值为 0x05 [NDEF] 中指定的 NDEF 消息仅匹配"NDEF:Unknown"的订阅。

NFC (API) 近场通信