NDEF 技术规范
NDEF 技术规范
概览
国际标准 ISO/IEC 18092,近场通信-接口与协议(NFCIP-1),定义了在 13.56M Hz 下工作的紧耦合设备间的简单无线互连的接口和协议。
NFC 数据交换格式(NFC Data Exchange Format,NDEF)规范定义了信息交换的消息封装格式。例如,一个 NFC 论坛设备与另一个 NFC 论坛设备或 NFC 论坛标签之间的信息交换。
NDEF是一个轻量级的二进制消息格式,可用于将一个或多个任意类型和大小的应用程序定义的有效载荷封装到单个消息结构中。每个有效载荷由类型、长度和可选标识符描述。
类型标识符可以是 URIs、MIME媒体类型或 NFC特定类型。后一种格式允许紧凑地标识 NFC 论坛应用程序中常用的类型,或者为希望将其用于自己的为 NFC 特定目的组织的自分配名称空间。
载荷长度是一个无符号整数,指示载荷中的字节个数。为非常小的载荷提供了一个紧凑的、短记录的布局。
可选的载荷标识符支持多个载荷的关联和它们之间的交叉引用。
在生成数据时,NDEF 载荷可能包括嵌套的 NDEF 消息或长度未知的链接块链。
严格地说,NDEF 是一种消息格式,它不提供连接或逻辑电路的概念,也不解决队头问题。
目的
NFC 数据交换格式(NDEF)规范是 NFC 论坛设备和 NFC 论坛标签的公共数据格式。
NFC 数据交换格式规范定义了 NDEF 数据结构格式以及规则,以构造有效的 NDEF 消息作为 NDEF 记录的有序和不间断的集合。此外,它还定义了指定封装在 NDEF 记录中的应用程序数据类型的机制。
NDEF 规范只定义数据结构格式,以便以可互操作的方式交换应用程序或服务指定数据,并且它没有详细定义任何记录类型--记录类型是在单独的规范中定义的。
本 NDEF 规范假设一个可靠的底层协议,因此本规范没有指定两个 NFC 论坛设备之间的数据交换或 NFC 论坛设备与 NFC 论坛标签之间的数据交换。建议读者复习 NFCIP-1 传输协议[ISO/IEC 18092]。
一个使用 NDEF 的例子是当两个 NFC 论坛设备相互靠近时,将会通过 NFC 论坛 LLCP 协议交换一条信息。当 NFC 论坛设备接近 NFC 论坛标签时,将依靠 NFC 论坛标签协议从 NFC 论坛标签中检索 NDEF 消息。两种情况下的 NDEF 消息数据格式是相同的, 因此,NFC 论坛设备可以处理与其通信的设备或标签类型无关的 NDEF 信息。
由于现有的消息封装格式、记录标记协议和多路复用协议的数量很多,所以最好是明确说明 NDEF 的设计目标,特别是哪些内容不属于 NDEF 的范围。
设计目标
NDEF 的设计目标是提供一个高效简单的消息格式,以实现如下功能:
- 封装任意文档和实体,包括加密数据、XML 文档、XML 片段以及 GIF 和 JPEG 图像数据等文件。
- 封装初始大小未知的文档和实体。此功能可用于将动态生成的内容或非常大的实体封装为一系列块。
- 将逻辑关联的多个文档和实体以某种方式聚合成一条消息。例如,NDEF 可以用来封装一个 NFC 特定消息和一组从 NFC 特定消息引用的标准化类型的附件。
- 应容纳小型载荷的紧凑封装,而不会给解析器带来不必要的复杂性。
为了高效和简单,本规范提供的机制被故意限制为服务于这些功能。NDEF 未被设计为如 MIME 或 XML 的一般消息描述或文档格式,相反,NFC 应用程序可以利用这种格式,将它们封装在 NDEF 消息中。
非设计目标
以下条目不属于 NDEF 考虑的范围:
- NDEF 不对在 NDEF 消息中携带的载荷类型或此类消息所隐含的消息交换模式做任何假设。
- NDEF 不以任何方式引入连接或逻辑电路(虚拟或其他)的概念。
- NDEF 不会试图处理当使用像 TCP 这样的面向流协议时可能发生的队头阻塞问题。
本节剩余(略)
NDEF 机制
本节讲述 NDEF 中使用的机制。这些机制的具体语法在第3节中定义。
介绍
NFC 论坛数据交换格式是一个轻量级二进制消息格式,设计用于将一个或多个应用程序定义的载荷封装到单个消息结构中。一个 NDEF 消息包含一或多条 NDEF 记录,每个记录都携带一个任意类型的载荷,最高可达到 $2^{31} -1$ 字节。记录可以链接在一起以支持更大的载荷。每条 NDEF 记录携带三个参数用于描述它的载荷:载荷长度、载荷类型和一个可选的载荷标识符。各参数作用如下:
载荷长度\ 载荷长度指示载荷占用的字节数。通过在记录的前8个字节内提供载荷长度,可以进行有效的记录边界检测。
载荷类型\ NDEF 载荷类型标识符指定载荷的类型。NDEF 支持 URIs[RFC 3986]、MIME 媒体类型结构[RFC 2046]以及 NFC 特定类型作为类型标识符。通过指定载荷类型,使将载荷发送到适当的用户应用程序成为可能。
载荷标识符 载荷可以以绝对或相对 URI 的形式给出可选标识符。标识符的使用使支持 URI 链接技术的载荷能够交叉引用其他载荷。
预定用途
NDEF 的预定用途如下:用户应用程序希望将一个或多个相关文档封装到单个 NDEF 消息之中。例如,这可以是特定于应用程序的消息,以及一组附件,每个附件都是标准化类型。NDEF 生成器将 NDEF 记录中的每个文档封装为载荷或分块载荷,并指示载荷的类型和长度以及可选标识符。然后将 NDEF 记录放在一起形成单个 NDEF 消息。将 NDEF 消息通过 NFC 链接传输到另一个 NFC 论坛设备,在那里接收和解析它们,或者作为中间步骤,将消息写入 NFC 论坛标签。靠近这个 NFC 论坛标签的 NFC 论坛设备将从这个标签中读取 NDEF 消息并将其传递给 NDEF 解析器。NDEF 解析器解构 NDEF 消息,并将载荷交给(可能不同的)用户应用程序。每个 NDEF 消息必须完整地发送或接收。
NDEF 记录可包装任意类型的文档。它可以通过使用诸如“message/rfc822”的媒体类型在 NDEF 记录中携带 MIME 消息。一个 NDEF 消息可通过使用 NFC 特定预定义类型(参考[NFC RTD])封装在 NDEF 记录中。
需要注意,虽然支持 MIME 实体,但并未假定在 NDEF 中记录的载荷一定是 MIME;NDEF 不对 NDEF 消息中携带的载荷的类型做任何假设。换句话说,NDEF 解析器不需要检查 NDEF 记录类型,也不需要在 NDEF 记录中匹配以解析 NDEF 消息。
NDEF 不支持错误处理。由 NDEF 解析器来确定接收格式错误的 NDEF 消息或包含超出其处理能力的字段长度的 NDEF 消息。所涉及的用户应用程序有责任提供任何额外的功能,如他们可能需要的 QoS,作为他们参与的整个系统的一部分。
NDEF 封装结构
消息
一个 NDEF 消息由一或多条 NDEF 记录组成。第一条记录的 MB(Message Begin)标志位置 1,最后一条记录的 ME(Message End)标志位置 1。最小消息长度带有一条记录,在这条记录内的 MB 和 ME 标志位都为 1。请注意,分块载荷的编码至少需要两个记录块。可以在 NDEF 消息中携带的 NDEF 记录的最大数量是无界的。
NDEF 信息不能重叠;也就是说,MB 以及 ME 标志位不能被用于嵌套 NDEF 消息。可以通过在 NDEF 记录中将完整的 NDEF 消息作为载荷进行嵌套。
图 1:NDEF 消息携带多条记录示例
此消息首部在左端,尾部在右端,其中逻辑记录索引 t>s>r>l。第一条记录的 MB 标志位置 1,最后一条记录的 ME 标志位置 1。
直接的 NDEF记录并不携带索引号,排序是由记录序列化的顺序隐式地给出的。例如,如果记录由中间应用程序重新打包,则该应用程序负责确保记录的顺序被保存。
记录
记录是在 NDEF 消息中承载载荷的单元。每个载荷都由自己的参数集描述。
记录块
记录块携带分块载荷。分块载荷可用于将动态生成内容或非常大的实体划分进相同 NDEF 消息内的多个连续记录块。
分块不是一种将多路复用或数据流引入 NDEF 的机制,它绝不能用于这些目的。它是一种减少对生成端出站缓冲需求的机制。这类似于 HTTP/1.1 [RFC 2616] 中定义的消息分块机制。
一个 NDEF 消息可包含 0 或多个分块载荷。每个分块载荷被编码为一个初始记录块,后面跟随 0 或多个中间记录块,最后是结束记录块。每个记录块通过使用以下规则被编码为一个 NDEF 记录:
- 初始记录块是一个 CF(Chunk Flag)标志位为 1 的 NDEF 记录。整个分块载荷的类型必须在
TYPE
字段中指示,而不管PAYLOAD_LENGTH
字段值是否为零。ID
字段可用于携带整个分块载荷的标识符。初始记录的PAYLOAD_LENGTH
字段仅指示初始记录的PAYLOAD
字段所携带的数据的尺寸,而不是整个载荷尺寸。 - 每个中间记录块都是 CF 标志位置 1 的 NDEF 记录,表示此记录块包含具有与初始记录块相同标识符的相同类型的下一个数据块。
TYPE_LENGTH
和IL
字段的值必须为 0,TNF
(Type Name Format)字段的值必须为 0x06(不可更改)。PAYLOAD_LENGTH
字段仅指示这一中间记录的PAYLOAD
字段所携带的数据的尺寸。 - 结束记录块为 CF 标志位置 0 的 NDEF 记录,指示此记录块包含具有与初始记录块相同标识符的相同类型的最后一个数据块。就像中间记录块一样,
TYPE_LENGTH
和IL
字段的值必须为 0,TNF
(Type Name Format)字段的值必须为 0x06(不可更改)。PAYLOAD_LENGTH
字段仅指示这一结束记录块的PAYLOAD
字段所携带的数据的尺寸。
一个分块载荷必须被完整封装在单个 NDEF 消息中,也就是说,一个分块载荷绝不允许跨越多个 NDEF 消息。因此,无论是初始还是中间记录块都不能设置 ME(Message End)标志为 1。
NDEF 载荷描述
每条记录都包含有关在其中携带的载荷的信息。本节介绍描述这些载荷的机制。
载荷长度
无论一条记录与其他记录的关系如何,载荷长度总是指示本记录封装的载荷长度。载荷的长度由PAYLOAD_LENGTH
字段指示。PAYLOAD_LENGTH
字段在短记录中为单个字节,在普通记录中为四个字节。将 SR 位置 1 表示短记录。0 是有效的载荷长度。
载荷类型
记录的载荷类型指示记录载荷中携带的是何种数据。这可用于指导用户应用程序如何处理载荷。按照惯例,第一条记录的类型不仅应该为第一条记录提供处理上下文,而且应该为整个 NDEF 消息提供处理上下文。处理消息的附加上下文可由接收消息的链路层服务访问点(LSAP)或传输服务端口(如 TCP、UDP 等)提供,也可由其他通信参数提供。
需要强调的是,NDEF 没有为 NDEF 消息指定特定的处理模型。载荷类型的使用完全由用户应用程序自行决定。关于上述使用的解释应作为构建处理约定的指南,包括将更高级别的应用程序语义映射到 NDEF。
TYPE
字段值的格式由 TNF(Type Name Format)字段指示。本规范支持如下TYPE
字段值形式:NFC 论坛知名类型、NFC 论坛外部类型,绝对 URIs[RFC 3986]以及 MIME 媒体类型结构。第一种形式允许 NFC 论坛指定支持 NFC 论坛相关应用[NFC RTD]的载荷类型;URIs 规定了对值空间的分散控制;媒体类型允许 NDEF 利用 IANA[RFC 1700]维护的媒体类型值空间。
媒体类型注册过程在 RFC 2048[RFC 2048]中讲述。不鼓励使用非注册媒体类型。URI 架构注册过程在 RFC 2717[RFC 2717]中描述。建议只使用 IANA 注册的知名 URI 结构(参考[URI SCHEME]获取当前列表)。
URIs 可被用于由 URIs 定义的消息类型。携带基于 XML 的消息类型载荷的记录可以使用根元素的 XML 命名空间标识符作为TYPE
字段值。一个 SOAP/1.1 消息可通过 URI 来表现,如:
http://schemas.xmlsoap.org/soap/envelope/
注意:URI 字符编码不属于 US-ASCII 范围,它留给 NDEF 应用程序。因此,NDEF 解析器不能为此字段假定任何特定的编码。参考[RFC 3986]和特定协议方案的规格(例如,HTTP、URN 等)获取有关 URI 的解析和非 ASCII 字符的字符编码要求的更多信息。
携带现有注册媒体类型载荷的记录应该携带该媒体类型的TYPE
字段值。TYPE
字段指示载荷的类型;它不引用包含给定类型实体的 MIME 消息。例如,媒体类型:
image/jpeg
指示载荷是一个 JPEG 格式的图像,使用由 RFC 2046[RFC 2046]定义的 JFIF 编码。类似地,媒体类型
message/http
指示载荷是一个由 RFC 2616[RFC 2616]定义的 HTTP 消息。值
application/xml;charset="utf-16"
指示载荷是由 RFC 3023[RFC 3023]定义的 XML 文档。
载荷标识符
可选的载荷标识符允许用户应用程序标识在 NDEF 记录中携带的载荷。通过提供载荷标识,支持基于 URI 的链接技术的其他载荷可以引用该载荷。NDEF 没有授权任何特定的链接机制或格式,但将其留给用户应用程序以其所喜欢的语言定义。
维护载荷标识符以使对这些载荷的引用不被破坏是很重要的。如果记录被重新包装,例如,由中间应用程序,那么该应用程序负责确保保存已识别的载荷之间的链接关系。
NDEF 机制测试要求
本节确定了第 2 章中定义的 NDEF 机制的可测试要求。本节和下表的目的是指导一致性测试的开发,而不是取代本章其他章节中提出的规范要求。
测试要求 1:NDEF 机制测试要求 | 消息要求 | | - | | 每个 NDEF 消息必须完整地交换。 | | 消息的第一条记录的 MB(Message Begin)标志位设置为 1 | | 消息的最后一条记录的 ME(Message End)标志位设置为 1 | | NDEF 消息不可重叠;也就是 MB 和 ME 标志不能被用于嵌套 NDEF 消息。 |
| 记录块要求 |
| ---------------------------------------------------------- |
| 每个分块载荷被编码为一个初始记录块,然后是 0 个或更多个中间记录块,最后是一个结束记录块。 |
| 初始记录块是一个 CF 位置 1 的 NDEF 记录 |
| 整个分块载荷的类型必须在初始记录块的TYPE
字段中指定 |
| 初始记录的PAYLOAD_LENGTH
字段仅指示初始记录中PAYLOAD
字段中携带数据的尺寸 |
| 每个中间记录块都是 CF 标志置 1 的 NDEF 记录 |
| 每个中间记录块的TYPE_LENGTH
和IL
字段的值都必须为 0 |
| 每个中间记录块的TNF
(Type Name Format)字段的值必须为 0x06(不可更改)。 |
| 对于每个中间记录块来说,PAYLOAD_LENGTH
字段仅指示此单个记录中PAYLOAD
字段中携带数据的尺寸 |
| 结束记录块为 CF 标志位置 0 的 NDEF 记录 |
| 结束记录块的TYPE_LENGTH
和IL
字段必须设置为 0 |
| 结束记录块的TNF
(Type Name Format)字段的值必须为 0x06(不可更改) |
| 对于每个结束记录块来说,PAYLOAD_LENGTH
字段仅指示此单个记录中PAYLOAD
字段中携带数据的尺寸 |
| 分块载荷必须完全封装至单个 NDEF 消息之中 |
| 初始记录块不可将 ME(Message End)标志位置 1 |
| 中间记录块不可将 ME(Message End)标志位置 1 |
| NDEF 载荷要求 |
| ---------------------------------------------------- |
| 普通块的PAYLOAD_LENGTH
字段为 4 个字节 |
| SR(Short Record)标志位置 1 的记录的PAYLOAD_LENGTH
字段为一个字节 |
| 短记录的PAYLOAD_LENGTH
字段值在 0 至 255 之间 |
| 普通记录的PAYLOAD_LENGTH
字段值在 0 至 $2^{32}-1$ 之间 |
NDEF 规范
数据传输顺序
本文档中描述的 NDEF 记录的传输顺序解析为字节级别。对于显示一组字节的图表,这些字节的传输顺序首先是从左到右,然后从上到下,因为它们是用英语阅读的。例如图 2 中,字节按编号顺序进行传输。
图 2:NDEF 字节序
每当字节表示一个数字量时,图中最左边的位是高阶位或最高位。对于表示 NDEF 定义的数字量的每个多字节字段,整个字段的最左边位是最高位。这样的数字量是以大端方式传输的,最高的字节首先传输。
记录格式
NDEF 记录是具有通用格式的可变长度记录,如下图所示。在下面的章节中,将更详细地描述单个记录字段。
图 3:NDEF 记录格式
MB(Message Begin)
MB 标志是 1-bit 字段,置 1 表示 NDEF 消息的开始。
ME(Message End)
ME 标志是 1-bit 字段,置 1 表示 NDEF 消息的结束。注意,在分块载荷的情况下,ME 标志仅在此分块载荷结束记录块置 1。
CF(Chunk Flag)
CF 标志是 1-bit 字段,一个记录块在分块载荷中要么是第一个块,要么是最后一个块。
SR(Short Record)
SR 标志是 1-bit 字段,如果置 1,则PAYLOAD_LENGTH
字段为单字节。此 short record 格式是为了紧凑地封装小型载荷,这适合于大小在0到255字节之间的PAYLOAD
字段。
图 4:NDEF Short-Record 格式
虽然对于实现者来说,只为给定的应用程序选择一个或另一个记录格式是很诱人的,NDEF 解析器必须同时接受正常和short record格式。NDEF 生成器可以生成他们认为合适的记录格式。单个 NDEF 消息可包括正常和短记录。
IL(ID_LENGTH 字段是否存在)
IL标志位是 1-bit 字段,如果置 1,则表示在首部存在一个单字节ID_LENGTH
字段。如果IL标志为 0,则记录首部省略ID_LENGTH
字段,并且记录的ID
字段也会省略。
TNF(Type Name Format)
TNF字段值指示TYPE
字段值的结构(参考2.4.2节获取TYPE
字段的描述,第4节获取与TYPE
字段有关的国际化声明)。TNF
字段是一个 3-bit 字段,值定义如下表所示:
表1:TNF 字段值
| Type Name Format | 值 | | ----------------------------- | ---- | | 空 | 0x00 | | NFC 论坛知名类型[NFC RTD] | 0x01 | | 定义于RFC 2046[RFC 2046]的媒体类型 | 0x02 | | 定义于 RFC 3986[RFC 3986]的绝对 URI | 0x03 | | NFC 论坛外部类型[NFC RTD] | 0X04 | | 未知 | 0x05 | | 不可更改(参考2.3.3节) | 0x06 | | 保留 | 0x07 |
值 0x00(Empty)指示没有类型或载荷关联此记录。如果使用,TYPE_LENGTH
、ID_LENGTH
和 PAYLOAD_LENGTH
字段必须为 0,因此记录的Type
、ID
和PAYLOAD
字段都会省略。当需要空记录时,可以使用此TNF
值;例如,在没有用户应用程序定义载荷的情况下终止 NDEF 消息。
值 0x01(NFC 论坛知名类型)指示TYPE
字段所包含的值遵循 NFC 论坛 RTD 规范[NFC RTD]中定义的 RTD 类型名称格式。
值 0x02(媒体类型)指示TYPE
字段所包含的值遵循 RFC 2046[RFC 2046]所定义的媒体类型 BNF 结构。
值 0x03(绝对 URI)指示TYPE
字段所包含的值遵循由 RFC 3986[RFC 3986]所定义的绝对 URI BNF 结构。
值 0x04(NFC 论坛外部类型)指示TYPE
字段所包含的值遵循[NFC RTD]中为外部类型名称定义的类型名称格式。
值 0x05(未知)用于指示载荷类型未知。这类似于由 MIME[RFC 2046]定义的"application/octet-stream"媒体类型。如果使用,TYPE_LENGTH
字段必须置 0,因而 NDEF 记录的TYPE
字段将省略。关于实现,建议接收这种类型的 NDEF 记录的 NDEF 解析器提供一种机制,用于存储但不处理载荷。
值 0x06(不可更改)必须在分块载荷中的所有中间记录块和结束记录块中使用。如果使用,TYPE_LENGTH
字段必须置 0,因而 NDEF 记录的TYPE
字段将省略。
TNF
字段没有默认值。保留(或未分配)TNF
字段值供将来使用,现在不可使用。NDEF 解析器收到一个TNF
字段值为未知或不支持的TNF
字段值时,将会把它当成 0x05(未知)。
TYPE_LENGTH
TYPE_LENGTH
字段是一个无符号 8-bit 整数,指示 TYPE
字段的以字节为单位的长度。对于TNF
字段的某些值,TYPE_LENGTH
字段总是为 0。
ID_LENGTH
ID_LENGTH
字段是一个无符号 8-bit 整数,指示ID
字段的以字节为单位的长度。此字段仅在IL
标志位置 1 时存在于记录首部。可以将ID_LENGTH
设置为 0 字节,这种情况下,NDEF 记录的ID
字段将省略。
PAYLOAD_LENGTH
PAYLOAD_LENGTH
字段是一个无符号整数,它指示了PAYLOAD
字段(应用程序载荷)以字节为单位的长度。PAYLOAD_LENGTH
字段的大小由SR
标志位决定。
如果SR
标志为 1,PAYLOAD_LENGTH
字段为单个字节,表示一个 8-bit 无符号整数。
如果SR
标志为 0,PAYLOAD_LENGTH
字段为 4 字节,表示一个 32-bit 无符号整数。字节的传输顺序为高位优先。
允许载荷长度为 0,在这种情况下,PAYLOAD
字段在 NDEF 记录中省略。应用程序载荷大于$2^{32}-1$字节的可使用分块载荷。
TYPE
TYPE
字段的值是一个描述载荷类型的标识符。TYPE
字段的值必须遵循TNF
字段的值所隐含的结构、编码和格式。
NDEF 解析器接收到的 NDEF 记录如果携带的的TNF
字段值是它支持的,TYPE
值是未知的,则应当将类型标识符当成 0x05(未知)。
强烈建议类型标识符具有全局唯一性,并随着时间的推移具有稳定和定义良好的语义。
ID
ID
字段的值是一个 URI 引用[RFC 3986]形式的标识符(参考2.4.3和4.4节)。消息标识符的所需唯一性由生成器保证。URI 引用可以是相对的,也可以是绝对的;NDEF 不定义基 URI,这意味着使用相对 URIs 的用户应用程序必须提供实际的或虚拟的基 URI(参考[RFC 3986])。
中间和结束记录块(也就是说,记录除了初始块,还包含其它块;参考2.2.3节)不可拥有ID
字段。所有其它记录可以拥有一个ID
字段。
PAYLOAD
PAYLOAD
字段携带用于 NDEF 用户应用程序的载荷。在PAYLOAD
字段中携带数据的任何内部结构对 NDEF 都是不透明的。
NDEF 规范测试要求
本节确定了第 3 章中定义的 NDEF 机制的可测试要求。本节的目的是指导一致性测试的开发,而不是取代本章其他章节中提出的规范要求。
测试要求2:NDEF 规范测试要求 | 数据传输顺序要求 | | - | | 数字量以大端的方式传输,最高字节先传 |
| 记录格式要求 |
| --------------------------------------------------------------------------------------------------- |
| NDEF 解析器必须可以接爱普通和短记录格式 |
| NDEF 解析器必须可以接收混合了普通和短记录的单个 NDEF 消息 |
| 如果IL
标志位为 1,ID_LENGTH
字段必须存在 |
| 如果IL
标志位为 0,ID_LENGTH
字段不可存在 |
| 如果IL
标志位为 0,ID
字段不可存在 |
| TNF
字段的值必须在 0x00 和 0x06 之间 |
| 如果TNF
值为 0x00,TYPE_LENGTH
、ID_LENGTH
和PAYLOAD_LENGTH
字段必须为 0,并且记录中的TYPE
、ID
和PAYLOAD
字段必须省略。 |
| 如果TNF
值为 0x05(未知),TYPE_LENGTH
字段必须为 0,并且 NDEF 记录中的TYPE
字段必须省略 |
| 如果TNF
值为 0x06(不可更改),TYPE_LENGTH
字段必须为 0,并且 NDEF 记录中的TYPE
字段必须省略 |
| TNF
值不可为 0x07 |
| 如果ID_LENGTH
字段的值为 0,则ID
字段不可存在 |
| 如果SR
标志位为 0,PAYLOAD_LENGTH
字段为 4 字节,表示一个 32-bit 无符号整数,并且传输字节序为高位优先 |
| 如果SR
标志位为 1,PAYLOAD_LENGTH
字段为单字节,表示一个 8-bit 无符号整数。 |
| 如果PAYLOAD_LENGTH
字段值为 0,则PAYLOAD
字段不可存在 |
| TYPE
字段的值必须遵循TNF
字段的值所隐含的结构、编码和格式。 |
| 中间和结束记录块不可拥有ID
字段 |
特别考虑
国际化
在 NDEF 中使用的标识符,如 URIs 和 MIME 媒体类型结构,可能为国际化提供不同程度的支持。实现者可参考 RFC 2718[RFC 2718],用于 URIs 的国际化考虑,RFC 2046 [RFC 2046]用于 MIME 媒体类型的国际化考虑,RFC 2047[RFC 2047]用于消息报头的国际化(MIME)。
安全
实现者应该特别注意任何记录类型的安全影响,这些类型可能导致接收方环境中任何操作的远程执行。在接受任何类型的记录之前,应用程序应该知道与该类型相关的特定安全影响。
一般来说,在 RFC 2048[RFC 2048] 和 RFC 2046 [RFC 2046] 中的“应用”媒体类型的内容中讨论了媒体类型的安全性考虑。
最大字段尺寸
PAYLOAD
字段的尺寸以及ID
字段和TYPE
字段中使用的值受到这些字段的最大尺寸的限制。PAYLOAD
字段的最大尺寸在正常的 NDEF 记录格式中为 $2^{32}-1$ 字节,在 short record 格式中为 255 个字节(见第3.2.4节)。两种记录格式中的ID
和TYPE
字段的最大尺寸都为 255 字节。
虽然这些最大记录和字段尺寸所形成的消息被认为是格式良好的,但并不是所有用户应用程序都有能力或需要处理这些最大尺寸的载荷内容、载荷ID或类型标识符。资源受限的 NDEF 解析器可以选择拒绝不适合其特定需求的消息。
但是,NDEF 解析器不能拒绝仅基于SR
标志的 NDEF 消息。
在 NDEF 中使用 URIs
NDEF 使用 URIs[RFC 3986]作为某些标识符。对于 NDEF 来说,URI 只是一个格式化的字符串,它通过名称、位置或任何其他特性来标识资源。
尽可能避免在 URIs 中使用 IP 地址(参考 RFC 1900[RFC 1900])。然而,当使用时,应该支持 RFC 2732[RFC 2732]所描述的 URI 中的 IPv6 地址的文字格式。
一般来说,NDEF 不定义 URIs 的任何等价规则,因为这些规则是由单个 URI 方案和 RFC 3986[RFC 3986]定义的。尽管如此,由于许多当前 URI 解析器中的一些 URI 等价规则不一致,建议 NDEF 消息的生成器只依赖于 RFC 3986 定义的最基本的等价规则。
特别考虑的测试要求
本节确定第4节定义的 NDEF 机制的可测试要求。本节和下表的目的是指导一致性测试的开发,而不是取代本章其他章节中提出的规范要求。
测试要求3:特别考虑的测试要求
| |
| ---------------------------------------------------- |
| NDEF 解析器不能拒绝仅基于SR
标志的值的 NDEF 消息。 |
| NDEF 解析器可以拒绝记录中包含的TYPE
、ID
或PAYLOAD
字段大于其设计限制的消息。