以支持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。讀者可在本節基礎上自行研究其他幾種數據類型。