转自百度文库
1 概览
国际标准ISO / IEC 18092 ，近场通信 – 接口和协议（ NFCIP -1），定义了一个接口和协议用于工作在13.56MHz的设备间进行近距离、简单的无线互连。
NFC数据交换格式（ NDEF ）规范定义了一个交换信息的消息封装格式，例如在一个NFC论论坛设备和其他NFC 论坛设备，或NFC 论坛标签之间。
NDEF是一种轻便的二进制消息格式，可以用于封装一个或多个任意类型的应用程序定义的有效载荷，并构成一个单一消息结构。每个有效载荷是由一个类型、长度和一个可选的标识符进行描述。
类型标识符可能是URI ， MIME媒体类型，或特定NFC类型。后者的格式支持NFC论坛应用中常用的简洁标识，或那些出于自身特定NFC目的的组织采用的标识。
净荷长度是一个无符号整数，表明有效载荷的字节数，小的有效载荷可以采用结构紧凑的短记录布局。
可选的有效负载标识符允许多个有效载荷相相互参照，产生联系。
NDEF有效载荷可能包括嵌套的NDEF消息或数据生成时长度未知的链块。
NDEF是严格意义上的信息格式，它没有提供一个连接或逻辑电路的概念，也不涉及线头的问题。
1.1 目标
NFC数据交换格式（ NDEF ）规范是NFC论坛的通用数据格式用于NFC论坛设备和NFC 论坛标签。
NFC数据交换格式规范定义NDEF数据结构格式以及规则，构造一个有效的NDEF消息作为有序和完整的NDEF记录集合。此外，它还定义了一种机制用于指定封装在NDEF记录里的应用数据的类型。
NDEF规范只定义了数据结构格式，用来交换应用程序或服务之间互操作的具体数据，它没有详细定义任何记录类型—记录类型在单独的规范中定义。
NDEF规范假定一个可靠的基础协议，因此本规范不指定两个NFC论坛设备之间，或论坛设备与标签之间的交换的数据。建议读者回顾NFCIP – 1的传输协议[ISO / IEC 18092 ] 。
使用NDEF的一个例子是，当两个NFC论坛设备相互接近，一个NDEF消息基于NFC论坛LLCP协议被交换。当一个NFC论坛设备接近一个NFC论坛标签，一条 NDEF消息通过NFC论坛标签协议，从NFC论坛标签被检索到。NDEF消息的数据格式在这两种情况下是一样的，因此一个NFC论坛设备可以处理NDEF信息，而与它正在通信的设备或标签的类型无关。
由于大量的现有消息封装格式、记录标记协议和复用协议，最好明确有关NDEF的设计目标，特别是，关于NDEF范围之外的。
1.1.1设计目标
NDEF的设计目标是提供一个高效的和简单的消息格式，可满足以下几点：
•封装任意文件和实体，包括加密的数据，XML文档，XML片段，图像数据如GIF、JPEG文件等；
•封装的文件和实体最初大小未知。这种能力可以用来封装动态生成的内容或非常大的由数据块构成的实体。
•汇总多个以某种方式在逻辑上相关联的文档和实体封装成一个单一的消息，例如， NDEF可用于封装NFC特定消息和一组引用NFC特定消息的标准类型的附件。
•小型有效载荷的紧凑型封装应当避免引入没有必要的复杂性到解析器。
为了获得效率和简单性，本规范提供的机制已经刻意限制。 NDEF还没有被设计成一个通用的消息说明或文件格式，如MIME或XML ，而是NFC的应用程序可以利用这种格式在NDEF消息封装它们。
1.1.2反目标
以下列表标识NDEF范围以外的项目：
•NDEF不关心NDEF消息携带的有效载荷的类型，也不关心有关该信息所隐含的消息交换模式。
•NDEF不以任何方式引入连接或逻辑电路（虚拟的或其他）的概念。
•NDEF不会尝试处理，当使用面向流的协议，如TCP，线头可能发生的阻塞问题。
1.2 参考
[ISO/IEC 18092] ISO/IEC 18092, “InformationTechnology- Telecommunications andinformationexchange between systems- NearField Communication -Interface and Protocol (NFCIP-1)”.
[NFC RTD] “NFC Record Type Definition (RTD)Specification”, NFC Forum, 2006.
[RFC 1700] Reynolds, J. and J. Postel,“Assigned Numbers”, STD 2, RFC 1700,October 1994.
[RFC 1900] B. Carpenter, Y. Rekhter, “RenumberingNeeds Work”, RFC 1900, IAB,February 1996.
[RFC 2046] N. Freed, N. Borenstein,“Multipurpose Internet Mail Extensions(MIME) Part Two: Media Types” RFC 2046,Innosoft, First Virtual,November 1996.
[RFC 2047] K. Moore, “MIME (MultipurposeInternet Mail Extensions) Part Three:Message Header Extensions for Non-ASCIIText”, RFC 2047,University of Tennessee, November 1996.
[RFC 2048] N. Freed, J. Klensin, J. Postel,“Multipurpose Internet Mail Extensions(MIME) Part Four: RegistrationProcedures”, RFC 2048, Innosoft, MCI,ISI, November 1996.
[RFC 2119] S. Bradner, “Key words for use inRFCs to Indicate RequirementLevels”, RFC 2119, Harvard University, March1997.http://www.apps.ietf.org/rfc/rfc2119.html
[RFC 2616] R. Fielding, J. Gettys, J. C.Mogul, H. F. Nielsen, T. Berners-Lee,“Hypertext Transfer Protocol — HTTP/1.1”,RFC 2616, U.C. Irvine,DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997.
[RFC 2717] R. Petke, I. King, “RegistrationProcedures for URL Scheme Names”,BCP: 35, RFC 2717, UUNET Technologies,Microsoft Corporation,November 1999.
[RFC 2718] L. Masinter, H. Alvestrand, D.Zigmond, R. Petke, “Guidelines for newURL Schemes”, RFC 2718, XeroxCorporation, Maxware, Pirsenteret,WebTV Networks, Inc., UUNET Technologies,November 1999.
[RFC 2732] R. Hinden, B. Carpenter, L.Masinter, “Format for Literal IPv6Addresses in URL’s”, RFC 2732, Nokia, IBM,AT&T, December 1999.
[RFC 3023] M. Murata, S. St. Laurent, D. Kohn,“XML Media Types” RFC 3023,IBM Tokyo Research Laboratory, simonstl.com,SkymoonVentures,January 2001.
[RFC 3986] T. Berners-Lee, R. Fielding, L.Masinter, “Uniform Resource Identifiers(URI):Generic Syntax”, RFC 3986,MIT/LCS, U.C. Irvine, XeroxCorporation, January 2005.http://www.apps.ietf.org/rfc/rfc3986.html
[URI SCHEME] List of Uniform ResourceIdentifier (URI) schemes registered by IANAis availableat:http://www.iana.org/assignments/uri-schemes
1.3实施
NFC论坛数据交换格式规范是一个开放的，由近场通信论坛支持的规范，该公司位于：
401Edgewater Place, Suite 600
Wakefield,MA, 01880
Tel.:+1 781-876-8955
Fax:+1 781-224-1239
http://www.nfc-forum.org/
该设备技术工作组包含了本规范。
1.4特殊字使用
这篇文档中的关键字“MUST”，“MUST NOT”，“REQUIRED”，“SHALL”，“SHALL NOT”，“SHOULD”，“SHOULD NOT”，“RECOMMMENDED”，“MAY”和“OPTIONAL”在RFC 2119中解释。
1.5名字和logo使用
近场通信论坛有关使用NFC论坛商标和NFC论坛标志的政策如下：
•无论是否为NFC论坛的会员，任何公司可以要求兼容NFC论坛的规格。
•最新会员特权文件规定使用NFC论坛标志的权利被自动授予那些在一段时间内支付会费的指定成员。
•会员的分销商和销售代表可以使用NFC论坛标志促进该成员名下的产品销售。
•该标志应印刷成黑色或彩色像Logo页面所示的那样，这个从可从NFC论坛中获得。标志的纵横比应维持，但大小可以变化。标志中任何内容均不得添加或删除。
•由于NFC论坛的名称是近场通信论坛的一个商标，以下声明应包括出现该名称或标志的已发表的文献和广告材料：
NFC论坛和NFC论坛商标是近场通信论坛的商标。
1.6知识产权
NFC数据交换格式（NDEF）规格符合在2004.11.9批准的NFC论坛知识产权政策规定，并且符合在2004.12.17批准的NFC论坛规定。
1.7术语
NDEF应用
在NFC论坛设备逻辑高层的应用使用NDEF来组织信息用于和其他NFC论坛设备或NFC论坛标签进行交换数据。也可以称为用户应用或NDEF用户应用。
NDEF消息
本规范定义的基本消息结构。一个NDEF消息中包含一个或多个NDEF记录（见2.3.1节）。
NDEF记录
一个NDEF记录中包含一个由类型、长度和可选的标识符描述的有效载荷（见第2.3.2节）。
NDEF短记录
SR标志设置为1的NDEF记录；短记录中的PAYLOAD_LENGTH是一个八字节，允许携带最多255个字节的有效载荷或块（见第3.2.4节）。
NDEF记录块
包含有效载荷的一个块，而不是一个完整的有效载荷的NDEF记录（见第2.3.3节）。每个记录块携带分块有效载荷的一部分，除了每个有效载荷块的最后一个记录，其他记录的CF标志设置为1。
NDEF负载
应用数据由NDEF记录携带。
NDEF分块有效载荷
应用数据已经被划分成多个块，每个块次携带单独的NDEF记录，其中除了最后一个记录，其他记录的CF标志设置为1 。这种机制可以用来携带事先未知有效负荷大小的动态生成内容，或者非常大、不适合到一个单一的NDEF记录的实体。分块的有效载荷并不打算支持复用的内容或流，因此这种用法不赞成使用。（参见第2.3.3节）。
NDEF负载长度
在一个NDEF记录中的有效载荷的大小表示为字节数（见第2.4.1节）。
NDEF负载类型
一个标识符，用于指示有效负载的类型。该规范支持的URI[RFC 3986 ] ， MIME媒体类型结构[ 2616 ] ，以及NFC的具体记录类型作为类型标识符（见第2.4.2 ）。
NDEF负载标识符
可选的URI可以被用来确定一个有效载荷（见第2.4.3节）。
NDEF发生器
一个将应用程序定义的有效载荷封装在NDEF消息的实体或模块。
NDEF解析器
一个用来解析NDEF消息取出有效负荷送往NDEF应用的实体或模块。
用户应用
见NDEF应用。
2 NDEF机制
本节介绍NDEF使用的机制。具体的语法机制在第3节中定义。
2.1简介
NFC论坛的数据交换格式是一种轻量级的二进制消息格式设计，用来封装一个或多个应用程序定义的有效载荷送入一个单一的消息结构。一个NDEF消息包含一个或多个NDEF记录，每个记录携带任意类型的有效载荷和高达232 -1个字节的大小。记录可以链接在一起，以支持更大的有效载荷。一个NDEF记录带有三个参数用于描述它的有效载荷：有效载荷长度，有效载荷类型，和一个可选的有效负载标识符。这些参数的意义如下所示：
有效载荷长度
有效负荷长度指示有效载荷的字节数（见2.4.1节）。通过提供记录前8位的有效负荷长度，边界检测是可能的。
有效负荷类型
NDEF有效载荷类型标识符指示的是有效载荷的类型。NDEF支持的URI[RFC 3986 ] ， MIME媒体类型结构[ RFC 2046 ] ，以及NFC特定类型的格式类型标识符（见第2.4.2节）。通过指示一个有效负载的类型，可以调度有效载荷到相应的用户应用程序。
有效载荷标识符
有效负载可以给出在一个绝对的或相对的URI形式的可选标识符（见第2.4.3节）。标识符的使用能够支持URI链接技术交叉引用其他有效载荷。
2.2预期用途
NDEF的预期用法如下：用户应用程序要封装一个或多个相关文件到一个单一的NDEF消息。例如，这可以是包含一组标准化类型附件的、应用程序特定的消息。该NDEF发生器以有效载荷或分块有效载荷形式封装每个文档在NDEF记录，包含了有效载荷的类型、长度和可选的标识符。NDEF记录被放置在一起形成一个单一的NDEF消息。NDEF消息通过链路被传输到另一个NFC论坛设备，接收并解析，或者作为一个中间步骤，该消息被写入到一个NFC论坛标签。接近这个NFC标签的NFC论坛设备将从这个标签读取NDEF消息，并把它交给了NDEF解析器。该NDEF解析器解构NDEF消息和获取有效载荷送到一个（也可能是不同的）用户应用程序。每个NDEF消息一定是以一个整体形式被发送或接收。
NDEF记录可以封装任何类型的文件。通过使用媒体类型，例如“ MESSAGE/RFC822 ”，NDEF记录可以携带MIME消息。一个NDEF消息可以使用NFC特定的预定义类型（见[ NFC RTD ] ）封装在一个NDEF记录。
要注意，虽然MIME实体被支持，但是不能假定一个记录有效负载是MIME ； NDEF 不作出任何有关NDEF消息中携带的有效载荷的类型假设。换句话说，一个NDEF解析器不需要检查NDEF记录类型，也不对一个NDEF记录内部进行检查。
NDEF没有提供任何错误处理。接收到的包含错误的NDEF消息或包含一个超出处理能力的字段的NDEF消息，由NDEF解析器来确定它们的含义。用户应用程序有责任提供额外的功能，例如作为整个系统一部分的QoS。
2.3NDEF封装结构
2.3.1消息
一个NDEF消息是由一个或多个NDEF记录。消息中的第一个记录有MB（消息开始）标志设置，消息中的最后一条记录有 ME（消息结束）标志设置（见第3.2.1和3.2.2节）。最小消息长度是由在同一个记录设置的MB和ME标志决定。注意至少需要两个记录块是才能对分块有效载荷进行编码（见 2.3.3节）。可以在NDEF消息中携带的NDEF记录最大数目没有限制。
NDEF消息不能重叠，也就是说，MB和ME的标志不得用于NDEF消息之间。NDEF消息可以嵌套，将一个完整的NDEF消息作为有效负荷放在一个NDEF记录中。
|
NDEF消息 |
||||||
|
R1MB=1 |
… |
Rr |
… |
Rs |
… |
Rt ME=1 |
图1.包含多个记录的NDEF消息
该消息头在左，尾在右，通过逻辑记录索引符 t>s>r>1标识。MB（消息开始）标志设置在第一条记录（索引1），ME（消息结束）标志设置在最后一个记录（索引t）。
实际NDEF记录并没有索引号，该顺序由记录产生的顺序隐式给出。例如，如果记录由一个中间应用程序重新打包，则该应用程序负责确保记录的顺序被保留。
2.3.2记录
一条记录是NDEF消息携带有效负荷的单位。每个有效负荷由它自带的参数（见2.4节）描述。
2.3.3记录块
记录块是携带一个分块有效负荷。分块有效载荷可以被用来分割动态生成的内容或大的实体，合并形成多个后续记录块有序放置同在一个NDEF消息中。
分块并非引入复用或数据流到NDEF机制，它绝不能用于这些用途。它是一种减少发生器侧输出缓冲的机制。类似于在HTTP/1.1[RFC2616]所定义的消息分块机制。
一个NDEF消息可以包含零个或多个分块有效载荷。每个分块有效载荷被编码成初始记录块加零个或多个中间记录块，最后是一个终止记录块。每个记录块以下面的编码规则进行编码：
•初始记录块是包含CF（分块标志）标志设置（见3.2.3节）的NDEF记录块。不管PAYLOAD_LENGTH字段是不是0，整个分块有效负荷的类型必须可以在TYPE字段中被查找。ID字段可以用来携带整个有效负荷块的标识符。初始记录的PAYLOAD_LENGTH字段只表明了初始记录中PAYLOAD携带的数据大小，并不是整个有效负荷的大小（见2.4.1）。
•中间记录块是一个包含CF标志设置的NDEF记录，表明了该记录块包含相同类型的下一个数据块，并且包含和初始记录块相同的标识符。TYPE_LENGTH和IL字段必须是0，TNF（类型名称格式）字段必须是0x06（不能改变）（见3.2.6节）。PAYLOAD_LENGTH字段仅表明该单一中间记录PAYLOAD所包含的数据大小。
•终止记录块是CF标志被清除的NDEF记录块，表明该记录是最后一个相同类型、并包含和初始记录块相同标识符的数据块。和中间数据块一样，TYPE_LENGTH值和IL值必须是0，TNF（类型名称格式）值必须是0x06（不能改变）（见3.2.6节）。PAYLOAD_LENGTH值仅表明该终止记录PAYLOAD所包含的数据大小。
分块有效负荷数据必须是被整体封装在一个单一的NDEF消息中。也就是说，一个有效负荷块不能分割成多个NDEF消息。因此，初始记录块和中间记录块都不能使ME标志被设置。
2.4NDEF有效负荷描述符
每个记录包含关于所携带的有效负荷的信息。这节介绍有效负荷描述机制。
2.4.1有效负荷长度
不管两个记录之间如何联系，有效负荷长度总是表明了封装在该记录的有效负荷长度。这个长度值在PAYLOAD_LENGTH字段中。PAYLOAD_LENGTH值在短记录中是一个字节，在正常记录中是4个字节。短记录由SR标志置1来表明（见3.2.4节）。有效负荷长度可以为0。
2.4.2有效负荷类型
记录的有效负荷类型表明有效负荷所携带数据的种类。这可以用来指导用户应用程序对有效负荷处理过程。第一个记录的类型，通常提供的处理上下文应当不仅仅针对第一个记录而是整个NDEF消息。附加的用于处理消息的上下文应当被提供，例如，消息被接收是通过链接层服务接口（LSAP）还是传输服务接口（例如TCP,UDP等）和其他通信参数。
需要强调的是，NDEF没有具体的处理模型应用于NDEF消息。有效载荷类型的用法是完全由用户应用程序决定。以上关于用法的意见应被视为构建处理约定，包括更高级别的NDEF应用程序语义的映射准则。
TYPE值的格式使用TNF（类型名称格式）值（见3.2.6节）描述。这种规范支持TYPE字段以NFC论坛熟知（well-known）的类型，NFC论坛以外的类型，绝对URI[RFC3986]和MIME媒体类型结构表述。NFC论坛规定的第一种有效载荷类型支持NFC论坛参考应用[NFC RTD]; URI提供价值空间的分散控制; 媒体类型允许NDEF利用由IANA维护[RFC1700]的媒体类型值空间的优势。
媒体类型注册过程在RFC2048[RFC2048]中概述。不支持使用非注册媒体类型。 URI方案注册过程在RFC2717[RFC 2717]描述。推荐的做法是只使用由IANA注册的熟知（well-known）URI方案（参见[URI方案]的最新列表）。
URI可以用于那些由URI的定义的消息类型。基于XML的消息类型、携带有效负载的记录
可以使用根元素的XML命名空间标识符作为 TYPE字段值。例如， SOAP/1.1信息可以由URI所表示：
http://schemas.xmlsoap.org/soap/envelope/
注意：在US-ASCII范围外的URI字符编码预留给NDEF应用。因此，NDEF解析器不能指定该区域的任何特定编码。关于解析URI和非ASCII字符的字符编码要求的更多信息，请参见[ RFC 3986 ]和特定协议计划规范（如HTTP ，URN等）。
携带现有的、已注册媒体类型的有效载荷的记录应携带该媒体类型的TYPE 字段值。TYPE 字段值表示有效负载的类型，它不适用于包含给定类型的实体的MIME消息。例如，媒体类型image / jpeg表示该有效载荷是采用JFIF编码的，RFC 2046所定义的[RFC 2046 ]，JPEG格式的图像，。同样，媒体类型message/ http 表示该有效载荷是一个HTTP消息，由RFC 2616定义的[ RFC 2616 ] 。该值application/ xml；charset= “UTF – 16 “表示该有效载荷是一个XML文档,由RFC 3023 [ RFC3023 ]中定义。
2.4.3有效载荷识别
可选的有效负载标识符允许用户应用程序确定在一个NDEF记录携带的有效载荷。通过提供一个有效负载的标识符，就能够为其他支持基于URI连接技术的有效载荷与该有效负荷产生关联。 NDEF不要求任何特定的链接机制或格式，并将它留给用户应用程序用它喜欢的语言来定义。
重要的是，有效负载的标识符被保持，以便引用那些完整的有效载荷。如果记录被重新包装，例如，通过一个中间的应用程序，则该应用程序负责确保有效载荷之间的链接关系被保留。
2.5NDEF机制测试要求
本节确认在第2章中定义的NDEF机制的可测试的需求。本节和下表的目的是指导一致性测试过程，并不能取代在本章的其他部分提出的规范性要求。
测试要求1.NDEF机制测试要求
|
消息要求 |
|
每个NDEF 消息必须以整体的形式被交换。 |
|
消息的第一个记录中MB（消息开始）标志被设置。 |
|
消息的最后一个记录中ME（消息结束）标志被设置。 |
|
NDEF消息禁止重叠，也就是说，MB和ME标志不能用于NDEF 消息内部。 |
|
记录块要求 |
|
每个有效负荷块被编码成一个初始记录块、0个或多个中间记录块和终止记录块。 |
|
初始记录块是包含CF（记录标志）标志设置的NDEF记录块。 |
|
整个有效负荷块的类型必须在初始记录块的TYPE字段标识。 |
|
每个中间记录块是一个包含CF标志设置的NDEF记录。 |
|
每个中间记录块的TYPE_LENGTH字段和IL字段值必须是0。 |
|
每个中间记录块的TNF（类型名称格式）值必须是0x06（不能改变）。 |
|
每个中间记录块的PAYLOAD_LENGTH字段仅表明单一中间记录PAYLOAD所包含的数据大小。 |
|
终止记录块是包含CF标志清除的NDEF记录块。 |
|
终止记录块的TYPE_LENGTH值和IL值必须是0。 |
|
终止记录块的TNF（类型名称格式）值必须是0x06（不能改变）。 |
|
终止记录块的PAYLOAD_LENGTH字段仅表明该记录PAYLOAD字段所包含的数据大小。 |
|
分块有效负荷数据必须是被整体封装在一个单一的NDEF消息中。 |
|
初始记录块禁止设置ME（消息结束）标志。 |
|
中间记录块禁止设置ME（消息结束）标志。 |
|
NDEF有效负荷要求 |
|
正常记录的PAYLOAD_LENGTH字段是4个字节。 |
|
SR（短记录）比特标志值为1的记录的PAYLOAD_LENGTH字段是1个字节 |
|
短记录的PAYLOAD_LENGTH字段必须是0-255之间的值 |
|
正常记录的PAYLOAD_LENGTH字段必须是0-232-1之间的值 |
3 NDEF规范
3.1数据转换顺序
本文档中描述的NDEF记录发送顺序被解析到字节水平。图为一组字节，这些字节传输的顺序是首先从左到右，再从上到下，就好像读英文。例如在图2中，字节组以它编号顺序进行传输。
图2.NDEF字节顺序
每当一个字节表示一个数值量，图中最左边的位是高位或最重要的位。对于NDEF定义的、表示一个数值量的每个多字节字段，整个字段的最左边的位是最重要的位。这样的量是以大端方式传输，最重要的字节先传输。
3.2记录布局
NDEF记录是可变长度的记录，通用格式如下图中所示。在以下章节中详细地描述各个记录的字段。
图3.NDEF记录布局
3.2.1MB（消息起始）
MB标志的1比特字段被设置表明NDE F 消息开始。
3.2.2ME（消息结束）
ME标志的1比特字段被设置表明NDEF 消息结束。
3.2.3CF（块标志）
CF标志的1比特字段表明这是分块有效负荷的第一个记录块或中间记录块（见2.3.3节关于如何编码分块有效负荷的描述）。
3.2.4SR（短记录）
SR标志只有1比特字段，如果置位，表明PAYLOAD_LENGTH 字段是一个单一字节，这个简短的记录布局的目的是为紧凑封装那些PAYLOAD 字段大小为0至255个字节不等的小型有效载荷。
图4.NDEF 短记录布局（SR=1）
虽然实施者倾向于针对特定应用，选择一个或另一个记录布局，但NDEF解析器必须接受正常和短记录两种布局。NDEF产生器可能会生成它们认为合适的记录布局。一个单一的NDEF消息可能包含正常和短记录。
3.2.5 IL（ID_LENGTH 字段）
所述IL标志是一个1比特字段，如果置位，表明该ID_LENGTH字段是作为一个单字节放在记录头部。如果IL标志是0，ID_LENGTH字段是从记录头省略，ID字段被从记录也被删去。
3.2.6TNF（类型名称格式）
TNF字段值表明表示TYPE 字段值的结构（请参见2.4.2节TYPE 字段描述和第4节TYPE字段相关的国际化问题的说明）。TNF 是3比特字段，值的定义如下表所示：
表1.TNF字段值
|
类型名称格式值 |
|
空 0x00 |
|
NFC 论坛知名类型 [NFC RTD] 0x01 |
|
RFC 2046定义的媒体类型 [RFC 2046] 0x02 |
|
RFC 2986定义的绝对URI [RFC 3986] 0x03 |
|
NFC 论坛外部类型 [NFC RTD] 0x04 |
|
未知0x05 |
|
不变（见2.3.3节） 0x06 |
|
保留 0x07 |
0x00值（空）表示不存在与该记录相关的类型或有效载荷。在使用时， TYPE_LENGTH 、 ID_LENGTH和PAYLOAD_LENGTH字段必须为零和类型，ID和 PAYLOAD 字段从记录省略。该TNF 值可以用于一个空记录是必要的情况。例如，NDEF消息结束的情况下，没有由用户应用程序定义的有效载荷。
值0x01 （ NFC论坛知名类型）表示TYPE字段包含的值遵循NFC论坛的RTD规范[ NFC RTD ]中定义的RTD类型名称格式。
值0x02 （媒体类型）表示TYPE字段包含一个值，遵循RFC 2046 [ RFC 2046 ]中定义的媒体类型的BNF构造。
值0x03 （绝对URI）表示该类型字段包含一个值，该值遵循RFC 3986 [ RFC 3986 ]中定义的绝对URI的BNF结构。
值0x04（ NFC论坛外部类型）表示TYPE字段包含一个值，遵循[ NFC RTD ]外部类型名称定义的类型名称格式。
值0X05 （未知）被用来指示未知类型的有效负载。这类似于通过MIME [ RFC定义的“应用程序/字节流”媒体类型2046 ] 。使用时， TYPE_LENGTH字段必须为零，因此， TYPE字段在NDEF记录中被省略。关于执行，建议NDEF语法分析器接收到该类型的一个NDEF记录，并且没有更多关于使用的上下文，提供一种只存储但不处理有效负荷的机制（参见4.2节）。
0x06值（不变）必须在分块有效载荷的所有中间记录块和终止记录块中使用（见2.3.3节）。它不能用于其他记录。使用时， TYPE_LENGTH字段必须为零，因此， TYPE字段在NDEF记录被省略。
TNF没有默认值，未来用途的保留（或未分配）字段值禁止使用。获取含有未知或不受支持的TNF 字段值的NDEF 记录，NDEF 解析器视为0x05（未知）。
3.2.7 TYPE_LENGTH
该TYPE_LENGTH字段是一个无符号8比特整数，它指定TYPE字段的字节长度。该TYPE_LENGTH字段对某些TNF 值总是为零（见3.2.6节）。
3.2.8 ID_LENGTH
该ID_LENGTH字段是一个无符号8比特整数，指定ID字段的字节长度。这个字段只有在记录头中IL标志被设置为1时存在。允许0字节 ID_LENGTH ，在这种情况下， ID字段在NDEF记录省略。
3.2.9 PAYLOAD_LENGTH
该PAYLOAD_LENGTH字段是一个无符号整数，它指定PAYLOAD（应用程序有效载荷）字段的字节长度。该PAYLOAD_LENGTH字段的大小是由SR标志的值确定（见3.2.4节）。
如果SR标志被设置， PAYLOAD_LENGTH字段是表示一个8比特无符号整数的单字节。
如果SR标志被清除， PAYLOAD_LENGTH字段占4个字节，表示一个32比特无符号整数。字节的传输顺序是MSB优先（参见3.1节）。
0字节长度的有效载荷长度允许的，在这种情况下，有效载荷字段在NDEF 记录中被省略。超过232 -1个字节大小的应用程序有效载荷可以被分块有效载荷容纳（参见2.3.3节）。
3.2.10TYPE
TYPE字段的值是描述有效负载类型（参见2.4.2节）的标识符。
TYPE字段的值必须遵循TNF字段值代表的结构、编码和格式（见3.2.6节）。
一个NDEF语法分析器接收了一个包含它支持被未知的TNF 字段值的NDEF 记录，如果TNF
字段值是0X05 （未知），TYPE 字段应该解释该记录的类型标识符，。
我们强烈建议该类型标识符是全球唯一的，并总是保持稳定和明确的语义。
3.2.11 ID
ID字段的值是一个URI引用[RFC 3986 ]形式的标识符（见第2.4.3和4.4节）。消息标识符的唯一性需要由发生器保证。URI引用可以是相对或绝对的； NDEF没有定义基本URI意味着使用相对URI的用户应用程序必须提供一个实际或虚拟基础URI（参见[ RFC 3986 ] ）。
中间和终止记录块（即不包含分块有效负荷初始记录块的其他记录，见2.3.3节）不能有ID字段。所有其他记录可以有一个ID字段。
3.2.12PAYLOAD
PAYLOAD字段携带用于NDEF 应用程序的有效负荷。任何内部有效载荷字段中携带的数据结构对NDEF 都是不透明的。
3.3NDEF机制测试要求
本节确认在第3章中定义的NDEF 机制的可测试的需求。本节和下表的目的是指导一致性测试过程，并不能取代在本章的其他部分提出的规范性要求。
测试要求2.NDEF规范测试要求
|
数据传输顺序要求 |
|
大量数据时以大端方式传送，最重要的字节先传。 |
|
记录布局要求 |
|
NDEF解析器必须接收正常记录和短记录两种布局。 |
|
NDEF 解析器必须接受正常布局和短记录布局两种方式组成的NDEF消息。 |
|
如果IL 标志是1，ID_LENGTH 字段必须存在。 |
|
如果IL标志是0，ID_LENGTH字段禁止存在。 |
|
如果IL标志是0，ID 字段禁止存在。 |
|
TNF字段的值必须在0x00到0x06之间。 |
|
如果TNF 值为0x00，那么TYPE_IENGTH,ID_LENGTH 和PAYLOAD_LENGTH 字段必须是0，TYPE,ID 和PAYLOAD 字段必须在记录中被省略。 |
|
如果TNF 值为0x05（未知），TYPE_LENGTH 字段必须是0，TYPE 字段必须在字段中被省略。 |
|
如果TNF值为0x06（不变），TYPE_LENGTH字段必须是0，TYPE字段必须在字段中被省略。 |
|
TNF 值不能是0x07。 |
|
如果ID_LENGTH 字段值为0，ID 字段禁止存在。 |
|
如果SR 标志为0，PAYLOAD_LENGTH字段是4个字节，代表一个32比特无符号整数，字节传输顺序MSB 优先。 |
|
如果SR标志为1，PAYLOAD_LENGTH字段是1个字节，代表一个8比特无符号整数。 |
|
如果PAYLOAD_LENGTH字段值为0，PAYLOAD字段禁止存在。 |
|
TYPE 字段值必须遵循TNF 字段值表明的结构、编码以及格式。 |
|
中间和终止记录块禁止包含ID字段。 |
4 特别注意事项
4.1国际化
NDEF中使用的标识符，如URI和MIME媒体类型的结构可以提供不同的对国际化支持的水平。实施者参考有关URI国际化的RFC 2718 [RFC 2718 ]，MIME媒体类型国际化的RFC 2046 [RFC 2046 ]和消息头（ MIME ）国际化的RFC 2047 [RFC 2047 ]。
4.2安全
实施者应特别注意任何记录类型的安全问题，导致收件人环境中远程执行任何操作。在接受任何类型的记录前，应用程序应该知道该类型相关联的特殊的安全影响。
一般媒体类型的安全注意事项在RFC 2048 [ RFC 2048]、RFC 2046 [ RFC 2046 ]“应用程序”媒体类型的上下文中讨论。
4.3最大字段大小
PAYLOAD字段的大小、ID字段中使用的值、TYPE字段受限于这些字段的最大尺寸。PAYLOAD字段，在正常的NDEF记录布局的最大长度为232 -1字节，在短记录布局（见3.2.4字节）的最大长度是255个字节。两种类型记录布局的ID和TYPE 字段值的最大大小为255个字节。
虽然形成这些最大记录和字段大小的消息被认为是良好的，但不是所有用户应用程序将有能力或需要处理有效载荷内容，有效载荷的ID ，或这些最大规模的类型标识符。 NDEF解析器是资源受限的，可以选择拒绝大小不适应其特定需求的信息。
然而， NDEF解析器不得拒绝纯粹以SR标志值为基础的NDEF消息。
4.4 NDEF中URI使用
NDEF使用URI [ RFC 3986 ]的一些标识符。对于NDEF ， URI只是一个格式化的字符串，通过名称，位置，或任何其他特性，用于标识一个资源。
应避免在URI中使用IP地址（请参阅RFC 1900 [ RFC 1900] ）。然而，在使用时，对RFC2732 [ RFC 2732 ]描述的IPv6的文字格式应予支持。
NDEF一般不定义任何URI的等价规则，因为它们由单个URI方案和RFC 3986 [ RFC 3986 ]定义。但是，由于许多的URI解析器某些URI等价规则不一致，建议NDEF消息发生器仅依靠由RFC 3986 定义的最基本的等价规则。
4.5 特殊注意事项测试要求
本节确认在第4章中定义的NDEF 机制的可测试的需求。本节和下表的目的是指导一致性测试过程，并不能取代在本章的其他部分提出的规范性要求。
测试要求3.特殊注意事项测试要求
|
NDEF 解析器不能拒绝仅基于SR 标志值得NDEF 消息。 |
|
NDEF 解析可以拒绝那些TYPE,ID 或PAYLOAD 字段超过设计大小的消息。 |
今天的文章nft消息_知云文献翻译「建议收藏」分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/57831.html
