以支持NFC功能的智能终端为例，NFC R/W运行模式所包含的组件如图8-4[6]所示： :-:  图8-4 R/W运行模式组件 图8-4展示了一个包含NFC芯片的智能终端与NFC Tag交互所涉及到的组件，其中： * 先看最左边的智能终端，它扮演NFC Reader角色。位于其内部的NFC芯片包含NFC Controller（NFC控制器，它可和Device Host或Secure Element安全单元交互）、Antenna（天线）和Contactless Front-End（非接触式前端，简称CLF，负责射频信号的调制解调等工作）三个部分。注意，图中所示的SWP等内容将留待8.2.4节再介绍。 * 在R/W模式中，交互操作的发起方只能是NFC Reader，故它也被称为Initiator或Active Device。 * 再来看最右边的NFC Tag，由于它需要NFC Reader通过电磁感应为其提供电能，所以在R/W模式中，NFC Tag只能作为交互操作的Target（也被称为Passive Device）。NFC Forum定义了四种类型的Tag，分别为Type 1、Type 2、Type 3和Type 4。这四种类型NFC Tag的区别在于存储空间大小，数据传输率以及底层使用的协议上。下文的表8-1列举了它们的不同点。 NFC Forum定义了两个通用的数据结构用于在NFC Device之间（包括R/W模式中的NFC Reader和NFC Tag）传递数据。这两个通用数据结构分别是NFC Data Exchange Format（简写为NDEF）以及NFC Record。 我们先来看NFC 4种不同Type的Tag有何区别，如表8-1[7]所示： :-: 表8-1 NFC Tag Type说明 | 参数 | Type 1 | Type 2 | Type 3| Type 4 | | --- | --- | --- | --- | --- | | 对应规范 | ISO 14443 Type A | ISO 14443 Type A | Felica | ISO 14443 Type A，Type B | | 常见芯片名 | Topaz | MIFARE | Felica | MIFARE-DESFire | | 存储容量 | 最大1KB | 最大2KB | 最大1MB | 最大64KB | | 读写速率 | 106kbps | 106kbps | 212kbps | 106-424kbps | | 价格 | 低 | 低 | 高 | 中等/高 | | 安全性 | 数字签名保护 | 不安全 | 数字签名保护 | 可选 | | 说明 | Topaz由Innovision公司推出 | MIFARE由NXP公司推出 |由Sony公司推出，价格比较贵 | 这类芯片在出厂时就被配置好是否只读或可读写 | >[info] 注意：这里需要特别指出的一点是：虽然NFC Froum只有四种Type的Tag，但由于NFC本身源自RFID技术，二者在一些底层协议上也相互兼容，所以很多RFID Tag也能被NFC Reader识别和操作。为了书写方便，除非特别说明，本章所指的NFC Tag也包括那些和NFC相关规范兼容的RFID Tag。 虽然NFC Tag有四种不同类型（由上文可知，实际上能被NFC Reader读写的RFID Tag还远不止四种），但为了保证最大得兼容性，NFC Forum建议NFC设备之间尽量使用通用数据结构NDEF和NFC Record来交换信息。 NFC R/W模式涉及到的规范比较多，包括： NFC Reader如何与不同Type的Tag交互，这部分内容涉及到非常底层的一些协议。 NDEF和一些常用数据类型定义。 出于篇幅和实用性考虑，笔者拟仅介绍NDEF和相关的数据类型，感兴趣的读者可自行研究NFC Reader和Tag之间的交互协议。 **1、NDEF和NFC Record介绍** **①、NDEF和NFC Record[8][9]之间的关系** 根据NFC Forum的定义，R/W模式下，NFC设备之间每一次交互的数据都会封装在一个NDEF Message中，而一个NDEF Message可以包含多个NFC Record，真正的数据则封装在NFC Record中。图8-5展示了NDEF Message和NFC Record之间的关系。 :-:  图8-5 NDEF Message和NFC Record的关系 由图8-5可知：一个NDEF Message可包含一个或多个NFC Record。在一个NDEF Message中，第一个NFC Record需设置其MB位（Message Begin）为1，表示它是该消息中第一个NFC Record，最后一个NFC Record需设置ME位（Message End）位为1，表示它是此消息中最后一个NFC Record。 NFC Record本身的组织结构则如图8-6所示： :-:  图8-6 NFC Record组织结构 由图8-6可知：NFC Record分为NFC Record Header（头部信息）和Payload（数据载荷）两大部分。 Record Header中最重要的是其第一个字节。该字节有6个标志信息，它们分别是 * MB（Message Begin标志） * ME（Message End标志） * CF（Chunk Flag标志，表示该Record是否为分片Record） * SR（Short Record标志。如果该标志被设置，则图8-6中的4个PayLoad Length字段仅需一个，这表明PayLoad数据长度将限制在255个字节以内） * IL（ID_LENGTH标志，它用于指明Header中是否包含ID Length和ID这两个字段） * TNF（Type Name Format标志，用于指明PayLoad的类型，NFC Forum定义了一些常用的PayLoad类型，详情见下文分析）。 * Type Length指明Record Header中Type字段的长度。 * PayLoad Length 3到PayLoad Length 0这4个字段共同指明PayLoad字段的长度。如果SR标志被设置，则Record Header仅包含一个PayLoad Length字段。 * ID Length指明ID字段的长度。如图IL标志未设置，则ID Length和ID字段都不存在。 * Type字段表明PayLoad的类型，NFC Forum定义了诸如URI、MIME等类型的Type，其目的是为了方便不同的应用来处理不同Type的数据，例如URI类型的数据就交给浏览器来处理。 * ID：ID需要配合URI类型的PayLoad一起使用，它使得一个NFC Record能通过ID来指向另外一个NFC Record。 NFC Record中，常令初学者感到困惑的是TNF字段，其作用是什么？来看下文。 **②、TNF和RTD** TNF用于描述一个NFC Record中数据（Payload）的类型，为了方便应用程序能正确解析NFC Record中的数据，NFC Forum规定了一些常用的数据类型，如表8-2所示。 :-:  表8-2TNF取值 目前NFC支持七种数据类型。 * Empty：表示该Record中没有数据，即相当于一个空的NFC Record。 * NFC Forum Well-Known Type：由NFC Forum定义的一些较为常用的数据类型，包括URI、TEXT等，其格式遵循NFC Forum RTD（Record Type Definition）规范。下文将详细介绍它。 * MIME：它是Multipurpose Internet Mail Extensions的缩写，遵循RFC2046规范。例如，当TNF取值为MIME时，其Type字段取值可为"text/plain"或"image/png"等。 * Absolute URI：绝对URI，遵循RFC 3986规范。例如某文件的绝对URI为"http://android.com/robots.txt" ，而其相对URI则为"robots.txt"。 * NFC Forum External Type：也由NFC Forum的RTD规范定义，下文将介绍它。 * Unknown：代表Payload中的数据类型未知，它和MIME类型"application/octet-stream"有些类似，这种类型的数据由相应的应用程序来解析。 * Unchanged：这种类型的数据用于NFC Record分片。例如一个大的数据需要通过多个NFC Record来承载，除第一个NFC Record分片外，该数据对应的其他NFC Record分片都必须设置TNF为Unchanged。关于这部分内容，读者可参考NDEF规范的2.3.3节"Record Chunks"。 在TNF七大类型中，NFC Forum通过RTD规范定义了其中的WKT（Well-Known Type）和External Type两种类型。虽然RTD规范全长只有20来页，但阅读起来比较枯燥，在此，笔者总结其核心内容。 简单点说，WKT就是NFC Forum自己定义的一些常用数据类型，目前常用类型如下。 * URI Record Type：用于存储URI数据，对应Type字段取值为"U"。 * Text Record Type：用于存储文本数据，对应Type字段取值为"T"。 * Signature Record Type：用于存储数字签名数据，对应Type字段取值为"Sig"。 * Smart Poster Record Type：智能海报，用于存储与该海报相关的一些资讯信息，如图片、相关介绍等，对应Type字段取值为"Sp"。 * Generic Control Record Type：用于传递控制信息，对应Type字段取值为"Gc"。 * External Type：为第三方组织定义的类型，目前NFC Forum没有定义相关的数据类型。 >[info] 提示　NFC Forum目前定义的所有WKT类型列表可参考http://www.nfcforum.org/specs/nfc_forum_assigned_numbers_register。 掌握了上述理论知识后，下面将通过两个实例来看看NFC Record各个字段到底该如何设置。 **2、NFC Record实例[10][11]** 本节这两个实例分别来自URI Record Type规范和TEXT Record Type规范。先来看URI Record Type实例。 **①、URI Record Type实例** URI Record Type属于NFC Forum Well-known Type的一种，其对应的Type字段取值为"U"。对于这种类型的NFC Record，其Payload组织结构如表8-3所示。 :-:  表8-3 URI Record Payload组织结构 在URI Record Payload中，第一个字节指明URI的ID码，表8-4为NFC Forum定义的几种ID码。 :-:  表8-4 ID Code示意 了解上述信息后，我们来看"http://www.nfc.com" 这样的信息该如何封装为一个NDEF消息，图8-7所示为NDEF消息各字段的取值情况。 :-:  图8-7　URI Record实例 由于该NDEF消息只包含一个NFC Record，所以这个唯一的NFC Record将设置MB和ME标志位为1。另外，由于数据量小于255字节，所以SR标志位为1。最后，该Record携带的数据属于URI类型，它为Well-Known Type的一种，所以TNF取值为0x01。 Type Length字段取值为0x01，对应的Type字段取值为"U"，代表URI Record Type。 根据本节对URI Record的介绍，这种类型Record的Payload包含ID Code和data两个部分。IDCode取值为0x01占据1字节（代表"http://www" ），而data为"nfc.com"占据7字节，所以整个Payload长度为8字节，故Payload length字段取值为0x08。 当应用程序获取Payload信息后，将根据ID Code和Data的取值最终计算出对应的URI为"http://www.nfc.com" 。 相信本节所述的URI Record实例能帮助读者更加直观得了解NDEF和NRC Record，下面再来看一个实例。 **②、Text Record Type实例** Text Record Type和URI Record Type类似，其Payload组织结构如表8-5所示。 :-:  表8-5 Text Record Payload组织结构 :-:  图8-8　TEXT Record实例 图8-8所示为携带"Hello World"字符串信息的NDEF消息各字段的取值情况。 实例比较简单，请读者根据本节对TEXT Record知识的介绍来自行解释图8-8各个字段的取值。 至此，NFC R/W运行模式介绍完毕。在R/W模式下，对应用程序而言最重要的工作就是解析NDEF消息。NFC Forum定义了七种数据类型，其中内容比较丰富的属于NFC Forum WellKnown Type。本节介绍了WKT中最简单的URI Record和TEXT Record。读者可在本节基础上自行研究其他几种数据类型。