通过

NDEF 协议

  • 项目

“NDEF”协议是一种直接与通过 NFP 提供程序发布/订阅模型映射的 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 论坛设备 (而不是 NFC 论坛标记) 时，不得传输“*：WriteTag”发布。
  • 如果在驱动程序检测到具有足够空间的可写标记至少一个有效负载时启用了一个或多个“*：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 或有效负载。 从 Windows 客户端的角度来看，“NDEF：Empty”类型的订阅似乎没有任何意义。

必需的措施

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

所有 NDEF 类型的订阅：“NDEF”

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

必需的措施

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

外部 NDEF RTD 类型的订阅：“NDEF：ext。

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

泛型示例类型：“NDEF：ext。<SomeExternalType>”

具体示例类型：“NDEF：ext.contoso.com：mytype”

必需的措施

驱动程序必须与“NDEF：ext”的订阅匹配。<SomeExternalType>“仅包含接收的 NDEF 消息，这些消息的 TNF 字段值为 0x04，并且具有根据 [NFC RTD] 中指定的等效规则匹配”<SomeExternalType“的 TYPE 字段>。

“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，并且具有根据 [NDEF] 中指定的等效规则匹配”<SomeWellKnownType“的 TYPE 字段>。
  • 驱动程序不得验证已知类型，以便 NFC 论坛可以定义未来的已知类型，而无需更新驱动程序。

未知 NDEF 类型的订阅：“NDEF：Unknown”

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

必需的措施

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

NFC) API 参考 (近场通信