NDEF消息格式(翻譯版)

1、1 概覽國際標準ISO / IEC 18092 ，近場通信 - 接口和協(xié)議（ NFCIP -1），定義了一個接口和協(xié)議用于工作在13.56MHz的設(shè)備間進行近距離、簡單的無線互連。NFC數(shù)據(jù)交換格式（ NDEF ）規(guī)范定義了一個交換信息的消息封裝格式，例如在一個NFC論論壇設(shè)備和其他NFC 論壇設(shè)備，或NFC 論壇標簽之間。NDEF是一種輕便的二進制消息格式，可以用于封裝一個或多個任意類型的應(yīng)用程序定義的有效載荷，并構(gòu)成一個單一消息結(jié)構(gòu)。每個有效載荷是由一個類型、長度和一個可選的標識符進行描述。類型標識符可能是URI ， MIME媒體類型，或特定NFC類型。后者的格式支持NFC論壇應(yīng)用中常用的

2、簡潔標識，或那些出于自身特定NFC目的的組織采用的標識。凈荷長度是一個無符號整數(shù)，表明有效載荷的字節(jié)數(shù)，小的有效載荷可以采用結(jié)構(gòu)緊湊的短記錄布局?？蛇x的有效負載標識符允許多個有效載荷相相互參照，產(chǎn)生聯(lián)系。NDEF有效載荷可能包括嵌套的NDEF消息或數(shù)據(jù)生成時長度未知的鏈塊。NDEF是嚴格意義上的信息格式，它沒有提供一個連接或邏輯電路的概念，也不涉及線頭的問題。1.1 目標NFC數(shù)據(jù)交換格式（ NDEF ）規(guī)范是NFC論壇的通用數(shù)據(jù)格式用于NFC 論壇設(shè)備和NFC 論壇標簽。NFC數(shù)據(jù)交換格式規(guī)范定義NDEF數(shù)據(jù)結(jié)構(gòu)格式以及規(guī)則，構(gòu)造一個有效的NDEF消息作為有序和完整的NDEF記錄集合。此外，

3、它還定義了一種機制用于指定封裝在NDEF記錄里的應(yīng)用數(shù)據(jù)的類型。NDEF規(guī)范只定義了數(shù)據(jù)結(jié)構(gòu)格式，用來交換應(yīng)用程序或服務(wù)之間互操作的具體數(shù)據(jù)，它沒有詳細定義任何記錄類型 記錄類型在單獨的規(guī)范中定義。NDEF規(guī)范假定一個可靠的基礎(chǔ)協(xié)議，因此本規(guī)范不指定兩個NFC論壇設(shè)備之間，或論壇設(shè)備與標簽之間的交換的數(shù)據(jù)。建議讀者回顧NFCIP - 1的傳輸協(xié)議ISO / IEC 18092 。使用NDEF的一個例子是，當兩個NFC論壇設(shè)備相互接近，一個NDEF消息基于NFC論壇LLCP協(xié)議被交換。當一個NFC論壇設(shè)備接近一個NFC論壇標簽，一條 NDEF消息通過NFC論壇標簽協(xié)議，從NFC論壇標簽被檢索到。

4、NDEF消息的數(shù)據(jù)格式在這兩種情況下是一樣的，因此一個NFC論壇設(shè)備可以處理NDEF信息，而與它正在通信的設(shè)備或標簽的類型無關(guān)。由于大量的現(xiàn)有消息封裝格式、記錄標記協(xié)議和復用協(xié)議，最好明確有關(guān)NDEF的設(shè)計目標，特別是，關(guān)于NDEF范圍之外的。1.1.1設(shè)計目標NDEF的設(shè)計目標是提供一個高效的和簡單的消息格式，可滿足以下幾點：封裝任意文件和實體，包括加密的數(shù)據(jù)，XML文檔，XML片段，圖像數(shù)據(jù)如GIF、JPEG文件等；封裝的文件和實體最初大小未知。這種能力可以用來封裝動態(tài)生成的內(nèi)容或非常大的由數(shù)據(jù)塊構(gòu)成的實體。匯總多個以某種方式在邏輯上相關(guān)聯(lián)的文檔和實體封裝成一個單一的消息，例如， NDEF

5、可用于封裝NFC特定消息和一組引用NFC特定消息的標準類型的附件。小型有效載荷的緊湊型封裝應(yīng)當避免引入沒有必要的復雜性到解析器。為了獲得效率和簡單性，本規(guī)范提供的機制已經(jīng)刻意限制。 NDEF還沒有被設(shè)計成一個通用的消息說明或文件格式，如MIME或XML ，而是NFC的應(yīng)用程序可以利用這種格式在NDEF消息封裝它們。1.1.2反目標 以下列表標識NDEF范圍以外的項目： NDEF不關(guān)心NDEF消息攜帶的有效載荷的類型，也不關(guān)心有關(guān)該信息所隱含的消息交換模式。 NDEF不以任何方式引入連接或邏輯電路（虛擬的或其他）的概念。 NDEF不會嘗試處理，當使用面向流的協(xié)議，如TCP，線頭可能發(fā)生的阻塞問題

6、。 1.2 參考ISO/IEC 18092 ISO/IEC 18092, “Information Technology- Telecommunications and information exchange between systems- Near Field Communication -Interface and Protocol (NFCIP-1)”.NFC RTD “NFC Record Type Definition (RTD) Specification”, NFC Forum, 2006. RFC 1700 Reynolds, J. and J. Postel, “Assi

7、gned Numbers”, STD 2, RFC 1700,October 1994.RFC 1900 B. Carpenter, Y. Rekhter, “Renumbering Needs 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. Moor

8、e, “MIME (Multipurpose Internet Mail Extensions) Part Three:Message Header Extensions for Non-ASCII Text”, RFC 2047,University of Tennessee, November 1996.RFC 2048 N. Freed, J. Klensin, J. Postel, “Multipurpose Internet Mail Extensions(MIME) Part Four: Registration Procedures”, RFC 2048, Innosoft, M

9、CI,ISI, November 1996.RFC 2119 S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels”, RFC 2119, Harvard University, March 1997./rfc/rfc2119.htmlRFC 2616 R. Fielding, J. Gettys, J. C. Mogul, H. F. Nielsen, T. Berners-Lee,“Hypertext Transfer Protocol - HTTP/1.1”

10、, RFC 2616, U.C. Irvine,DEC W3C/MIT, DEC, W3C/MIT, W3C/MIT, January 1997.RFC 2717 R. Petke, I. King, “Registration Procedures 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 ne

11、w URL Schemes”, RFC 2718, Xerox Corporation, Maxware, Pirsenteret,WebTV Networks, Inc., UUNET Technologies, November 1999.RFC 2732 R. Hinden, B. Carpenter, L. Masinter, “Format for Literal IPv6 Addresses in URL's”, RFC 2732, Nokia, IBM, AT&T, December 1999.RFC 3023 M. Murata, S. St. Laurent,

12、 D. Kohn, “XML Media Types” RFC 3023,IBM Tokyo Research Laboratory, , Skymoon Ventures,January 2001.RFC 3986 T. Berners-Lee, R. Fielding, L. Masinter, “Uniform Resource Identifiers(URI):Generic Syntax”, RFC 3986, MIT/LCS, U.C. Irvine, Xerox Corporation, January 2005. /rfc/rfc3

13、986.htmlURI SCHEME List of Uniform Resource Identifier (URI) schemes registered by IANA is available at:/assignments/uri-schemes1.3 實施NFC論壇數(shù)據(jù)交換格式規(guī)范是一個開放的，由近場通信論壇支持的規(guī)范，該公司位于：401 Edgewater Place, Suite 600Wakefield, MA, 01880Tel.: +1 781-876-8955Fax: +1 781-224-1239http:/www.nfc-foru

14、/該設(shè)備技術(shù)工作組包含了本規(guī)范。1.4 特殊字使用這篇文檔中的關(guān)鍵字“MUST”，“MUST NOT”，“REQUIRED”，“SHALL”，“SHALL NOT”，“SHOULD”，“SHOULD NOT”，“RECOMMMENDED”，“MAY”和“OPTIONAL”在RFC 2119中解釋。1.5 名字和logo使用近場通信論壇有關(guān)使用NFC論壇商標和NFC論壇標志的政策如下：無論是否為NFC論壇的會員，任何公司可以要求兼容NFC論壇的規(guī)格。最新會員特權(quán)文件規(guī)定使用NFC論壇標志的權(quán)利被自動授予那些在一段時間內(nèi)支付會費的指定成員。會員的分銷商和銷售代表可以使用NFC論壇標志促進

15、該成員名下的產(chǎn)品銷售。該標志應(yīng)印刷成黑色或彩色像Logo頁面所示的那樣，這個從可從NFC論壇中獲得。標志的縱橫比應(yīng)維持，但大小可以變化。標志中任何內(nèi)容均不得添加或刪除。由于NFC論壇的名稱是近場通信論壇的一個商標，以下聲明應(yīng)包括出現(xiàn)該名稱或標志的已發(fā)表的文獻和廣告材料：NFC論壇和NFC論壇商標是近場通信論壇的商標。1.6 知識產(chǎn)權(quán)NFC數(shù)據(jù)交換格式（NDEF）規(guī)格符合在2004.11.9批準的NFC論壇知識產(chǎn)權(quán)政策規(guī)定，并且符合在 2004.12.17批準的NFC論壇規(guī)定。1.7 術(shù)語NDEF應(yīng)用在NFC論壇設(shè)備邏輯高層的應(yīng)用使用NDEF來組織信息用于和其他NFC論壇設(shè)備或NFC論壇標簽進行

16、交換數(shù)據(jù)。也可以稱為用戶應(yīng)用或NDEF用戶應(yīng)用。NDEF消息本規(guī)范定義的基本消息結(jié)構(gòu)。一個NDEF消息中包含一個或多個NDEF記錄（見2.3.1節(jié)） 。NDEF記錄一個NDEF記錄中包含一個由類型、長度和可選的標識符描述的有效載荷（見第2.3.2節(jié)） 。NDEF短記錄SR標志設(shè)置為1的NDEF記錄；短記錄中的PAYLOAD_LENGTH是一個八字節(jié)，允許攜帶最多255個字節(jié)的有效載荷或塊（見第3.2.4節(jié)） 。NDEF記錄塊包含有效載荷的一個塊，而不是一個完整的有效載荷的NDEF記錄（見第2.3.3節(jié)） 。每個記錄塊攜帶分塊有效載荷的一部分，除了每個有效載荷塊的最后一個記錄，其他記錄的CF標志

17、設(shè)置為1。NDEF負載應(yīng)用數(shù)據(jù)由NDEF記錄攜帶。NDEF分塊有效載荷應(yīng)用數(shù)據(jù)已經(jīng)被劃分成多個塊，每個塊次攜帶單獨的NDEF記錄，其中除了最后一個記錄，其他記錄的CF標志設(shè)置為1 。這種機制可以用來攜帶事先未知有效負荷大小的動態(tài)生成內(nèi)容，或者非常大、不適合到一個單一的NDEF記錄的實體。分塊的有效載荷并不打算支持復用的內(nèi)容或流，因此這種用法不贊成使用。（參見第2.3.3節(jié)）。NDEF負載長度在一個NDEF記錄中的有效載荷的大小表示為字節(jié)數(shù)（見第2.4.1節(jié)） 。NDEF負載類型一個標識符，用于指示有效負載的類型。該規(guī)范支持的URIRFC 3986 ， MIME媒體類型結(jié)構(gòu) 2616 ，以及NF

18、C的具體記錄類型作為類型標識符（見第2.4.2 ） 。NDEF負載標識符可選的URI可以被用來確定一個有效載荷（見第2.4.3節(jié)） 。NDEF發(fā)生器一個將應(yīng)用程序定義的有效載荷封裝在NDEF消息的實體或模塊。NDEF解析器一個用來解析NDEF消息取出有效負荷送往NDEF應(yīng)用的實體或模塊。用戶應(yīng)用見NDEF應(yīng)用。2 NDEF機制本節(jié)介紹NDEF使用的機制。具體的語法機制在第3節(jié)中定義。2.1 簡介NFC論壇的數(shù)據(jù)交換格式是一種輕量級的二進制消息格式設(shè)計，用來封裝一個或多個應(yīng)用程序定義的有效載荷送入一個單一的消息結(jié)構(gòu)。一個NDEF消息包含一個或多個NDEF記錄，每個記錄攜帶任意類型的有效載荷和高達

19、232 -1個字節(jié)的大小。記錄可以鏈接在一起，以支持更大的有效載荷。一個NDEF記錄帶有三個參數(shù)用于描述它的有效載荷：有效載荷長度，有效載荷類型，和一個可選的有效負載標識符。這些參數(shù)的意義如下所示：有效載荷長度有效負荷長度指示有效載荷的字節(jié)數(shù)（見2.4.1節(jié)） 。通過提供記錄前8位的有效負荷長度，邊界檢測是可能的。有效負荷類型NDEF有效載荷類型標識符指示的是有效載荷的類型。 NDEF支持的URIRFC 3986 ， MIME媒體類型結(jié)構(gòu) RFC 2046 ，以及NFC特定類型的格式類型標識符（見第2.4.2節(jié) ） 。通過指示一個有效負載的類型，可以調(diào)度有效載荷到相應(yīng)的用戶應(yīng)用程序。有效載荷標

20、識符有效負載可以給出在一個絕對的或相對的URI形式的可選標識符（見第2.4.3節(jié)） 。標識符的使用能夠支持URI鏈接技術(shù)交叉引用其他有效載荷。2.2 預期用途NDEF的預期用法如下：用戶應(yīng)用程序要封裝一個或多個相關(guān)文件到一個單一的NDEF消息。例如，這可以是包含一組標準化類型附件的、應(yīng)用程序特定的消息。該NDEF發(fā)生器以有效載荷或分塊有效載荷形式封裝每個文檔在NDEF記錄，包含了有效載荷的類型、長度和可選的標識符。NDEF記錄被放置在一起形成一個單一的NDEF消息。NDEF消息通過鏈路被傳輸?shù)搅硪粋€NFC論壇設(shè)備，接收并解析，或者作為一個中間步驟，該消息被寫入到一個NFC論壇標簽。接近這個NF

21、C標簽的NFC論壇設(shè)備將從這個標簽讀取NDEF消息，并把它交給了NDEF解析器。該NDEF解析器解構(gòu)NDEF消息和獲取有效載荷送到一個（也可能是不同的）用戶應(yīng)用程序。每個NDEF消息一定是以一個整體形式被發(fā)送或接收。NDEF記錄可以封裝任何類型的文件。通過使用媒體類型，例如“ MESSAGE/RFC822 ”，NDEF記錄可以攜帶MIME消息。一個NDEF消息可以使用NFC特定的預定義類型（見 NFC RTD ）封裝在一個NDEF記錄。要注意，雖然MIME實體被支持，但是不能假定一個記錄有效負載是MIME ； NDEF 不作出任何有關(guān)NDEF消息中攜帶的有效載荷的類型假設(shè)。換句話說，一個NDE

22、F解析器不需要檢查NDEF記錄類型，也不對一個NDEF記錄內(nèi)部進行檢查。NDEF沒有提供任何錯誤處理。接收到的包含錯誤的NDEF消息或包含一個超出處理能力的字段的NDEF消息，由NDEF解析器來確定它們的含義。用戶應(yīng)用程序有責任提供額外的功能，例如作為整個系統(tǒng)一部分的QoS 。2.3 NDEF封裝結(jié)構(gòu)2.3.1消息一個NDEF消息是由一個或多個NDEF記錄。消息中的第一個記錄有MB（消息開始）標志設(shè)置，消息中的最后一條記錄有 ME（消息結(jié)束）標志設(shè)置（見第3.2.1和3.2.2節(jié)）。最小消息長度是由在同一個記錄設(shè)置的MB和ME標志決定。注意至少需要兩個記錄塊是才能對分塊有效載荷進行編碼（見 2

23、.3.3節(jié)）?？梢栽贜DEF消息中攜帶的NDEF記錄最大數(shù)目沒有限制。 NDEF消息不能重疊，也就是說，MB和ME的標志不得用于NDEF消息之間。NDEF消息可以嵌套，將一個完整的NDEF消息作為有效負荷放在一個NDEF記錄中 。NDEF消息R1MB=1RrRsRt ME=1圖1.包含多個記錄的NDEF消息該消息頭在左，尾在右，通過邏輯記錄索引符 t> s>r>1標識。MB（消息開始）標志設(shè)置在第一條記錄（索引1），ME（消息結(jié)束） 標志設(shè)置在最后一個記錄（索引t）。 實際NDEF記錄并沒有索引號，該順序由記錄產(chǎn)生的順序隱式給出。例如，如果記錄由一個中間應(yīng)用程序重新打包 ，則

24、該應(yīng)用程序負責確保記錄的順序被保留。2.3.2記錄一條記錄是NDEF消息攜帶有效負荷的單位。每個有效負荷由它自帶的參數(shù)（見2.4節(jié)）描述。2.3.3記錄塊記錄塊是攜帶一個分塊有效負荷。分塊有效載荷可以被用來分割動態(tài)生成的內(nèi)容或大的實體，合并形成多個后續(xù)記錄塊有序放置同在一個NDEF消息中。 分塊并非引入復用或數(shù)據(jù)流到NDEF機制，它絕不能用于這些用途。它是一種減少發(fā)生器側(cè)輸出緩沖的機制。類似于在HTTP/1.1RFC2616所定義的消息分塊機制 。 一個NDEF消息可以包含零個或多個分塊有效載荷。每個分塊有效載荷被編碼成初始記錄塊加零個或多個中間記錄塊，最后是一個終止記錄塊。每個記錄塊以下面的

25、編碼規(guī)則進行編碼：初始記錄塊是包含CF（分塊標志）標志設(shè)置（見3.2.3節(jié)）的NDEF記錄塊。不管PAYLOAD_LENGTH字段是不是0，整個分塊有效負荷的類型必須可以在TYPE字段中被查找。ID字段可以用來攜帶整個有效負荷塊的標識符。初始記錄的PAYLOAD_LENGTH字段只表明了初始記錄中PAYLOAD攜帶的數(shù)據(jù)大小，并不是整個有效負荷的大?。ㄒ?.4.1）。中間記錄塊是一個包含CF標志設(shè)置的NDEF記錄，表明了該記錄塊包含相同類型的下一個數(shù)據(jù)塊，并且包含和初始記錄塊相同的標識符。TYPE_LENGTH和IL字段必須是0，TNF（類型名稱格式）字段必須是0x06（不能改變）（見3.2.

26、6節(jié)）。PAYLOAD_LENGTH字段僅表明該單一中間記錄PAYLOAD所包含的數(shù)據(jù)大小。終止記錄塊是CF標志被清除的NDEF記錄塊，表明該記錄是最后一個相同類型、并包含和初始記錄塊相同標識符的數(shù)據(jù)塊。和中間數(shù)據(jù)塊一樣，TYPE_LENGTH值和IL值必須是0，TNF（類型名稱格式）值必須是0x06（不能改變）（見3.2.6節(jié)）。PAYLOAD_LENGTH值僅表明該終止記錄PAYLOAD所包含的數(shù)據(jù)大小。分塊有效負荷數(shù)據(jù)必須是被整體封裝在一個單一的NDEF消息中。也就是說，一個有效負荷塊不能分割成多個NDEF消息。因此，初始記錄塊和中間記錄塊都不能使ME標志被設(shè)置。2.4 NDEF有效負荷

27、描述符每個記錄包含關(guān)于所攜帶的有效負荷的信息。這節(jié)介紹有效負荷描述機制。2.4.1有效負荷長度不管兩個記錄之間如何聯(lián)系，有效負荷長度總是表明了封裝在該記錄的有效負荷長度。這個長度值在PAYLOAD_LENGTH字段中。PAYLOAD_LENGTH值在短記錄中是一個字節(jié)，在正常記錄中是4個字節(jié)。短記錄由SR標志置1來表明（見3.2.4節(jié)）。有效負荷長度可以為0。2.4.2有效負荷類型記錄的有效負荷類型表明有效負荷所攜帶數(shù)據(jù)的種類。這可以用來指導用戶應(yīng)用程序?qū)τ行ж摵商幚磉^程。第一個記錄的類型，通常提供的處理上下文應(yīng)當不僅僅針對第一個記錄而是整個NDEF消息。附加的用于處理消息的上下文應(yīng)當被提供，

28、例如，消息被接收是通過鏈接層服務(wù)接口（LSAP）還是傳輸服務(wù)接口（例如TCP,UDP等）和其他通信參數(shù)。需要強調(diào)的是，NDEF沒有具體的處理模型應(yīng)用于NDEF消息。有效載荷類型的用法是完全由用戶應(yīng)用程序決定。以上關(guān)于用法的意見應(yīng)被視為構(gòu)建處理約定，包括更高級別的NDEF應(yīng)用程序語義的映射準則。TYPE值的格式使用TNF（類型名稱格式）值（見3.2.6節(jié)）描述。這種規(guī)范支持TYPE字段以NFC論壇熟知（well-known）的類型，NFC論壇以外的類型，絕對URIRFC3986和MIME媒體類型結(jié)構(gòu)表述。NFC論壇規(guī)定的第一種有效載荷類型支持NFC論壇參考應(yīng)用NFC RTD; URI提供價值空間

29、的分散控制; 媒體類型允許NDEF利用由IANA維護RFC1700的媒體類型值空間的優(yōu)勢。 媒體類型注冊過程在RFC2048RFC2048中概述。不支持使用非注冊媒體類型。 URI方案注冊過程在RFC2717RFC 2717描述。推薦的做法是只使用由IANA注冊的熟知（well-known）URI方案 （參見URI方案的最新列表）。URI可以用于那些由URI的定義的消息類型?；赬ML的消息類型、攜帶有效負載的記錄 可以使用根元素的XML命名空間標識符作為 TYPE字段值。例如， SOAP/1.1信息可以由URI所表示：/soap/envelo

30、pe/注意：在US-ASCII 范圍外的URI 字符編碼預留給NDEF 應(yīng)用。因此，NDEF 解析器不能指定該區(qū)域的任何特定編碼。關(guān)于解析URI 和非ASCII 字符的字符編碼要求的更多信息，請參見 RFC 3986 和特定協(xié)議計劃規(guī)范（如HTTP ，URN 等）。攜帶現(xiàn)有的、已注冊媒體類型的有效載荷的記錄應(yīng)攜帶該媒體類型的TYPE 字段值。TYPE 字段值表示有效負載的類型，它不適用于包含給定類型的實體的 MIME 消息。例如，媒體類型image / jpeg 表示該有效載荷是采用JFIF 編碼的，RFC 2046所定義的RFC 2046 ，JPEG 格式的圖像，。同樣，媒體類型messag

31、e/ http 表示該有效載荷是一個HTTP 消息，由RFC 2616定義的 RFC 2616 。該值application/ xml；charset= “UTF - 16 “ 表示該有效載荷是一個XML 文檔,由RFC 3023 RFC3023 中定義。2.4.3有效載荷識別可選的有效負載標識符允許用戶應(yīng)用程序確定在一個NDEF 記錄攜帶的有效載荷。通過提供一個有效負載的標識符，就能夠為其他支持基于URI 連接技術(shù)的有效載荷與該有效負荷產(chǎn)生關(guān)聯(lián)。 NDEF 不要求任何特定的鏈接機制或格式，并將它留給用戶應(yīng)用程序用它喜歡的語言來定義。重要的是，有效負載的標識符被保持，以便引用那些完整的有效載荷

32、。如果記錄被重新包裝，例如，通過一個中間的應(yīng)用程序，則該應(yīng)用程序負責確保有效載荷之間的鏈接關(guān)系被保留。2.5 NDEF機制測試要求本節(jié)確認在第2章中定義的NDEF 機制的可測試的需求。 本節(jié)和下表的目的是指導一致性測試過程，并不能取代在本章的其他部分提出的規(guī)范性要求。測試要求1.NDEF機制測試要求消息要求每個NDEF 消息必須以整體的形式被交換。消息的第一個記錄中MB（消息開始）標志被設(shè)置。消息的最后一個記錄中ME（消息結(jié)束）標志被設(shè)置。NDEF消息禁止重疊，也就是說，MB和ME標志不能用于NDEF 消息內(nèi)部。記錄塊要求每個有效負荷塊被編碼成一個初始記錄塊、0個或多個中間記錄塊和終止記錄塊。

33、初始記錄塊是包含CF（記錄標志）標志設(shè)置的NDEF記錄塊。整個有效負荷塊的類型必須在初始記錄塊的TYPE 字段標識。每個中間記錄塊是一個包含CF標志設(shè)置的NDEF記錄。每個中間記錄塊的TYPE_LENGTH字段和IL字段值必須是0。 每個中間記錄塊的TNF（類型名稱格式）值必須是0x06（不能改變）。每個中間記錄塊的PAYLOAD_LENGTH字段僅表明單一中間記錄PAYLOAD所包含的數(shù)據(jù)大小。終止記錄塊是包含CF標志清除的NDEF記錄塊。終止記錄塊的TYPE_LENGTH值和IL值必須是0。 終止記錄塊的TNF（類型名稱格式）值必須是0x06（不能改變）。終止記錄塊的PAYLOAD_LEN

34、GTH字段僅表明該記錄PAYLOAD字段所包含的數(shù)據(jù)大小。分塊有效負荷數(shù)據(jù)必須是被整體封裝在一個單一的NDEF消息中。初始記錄塊禁止設(shè)置ME（消息結(jié)束）標志。中間記錄塊禁止設(shè)置ME（消息結(jié)束）標志。NDEF 有效負荷要求正常記錄的PAYLOAD_LENGTH 字段是4個字節(jié)。SR （短記錄）比特標志值為1的記錄的PAYLOAD_LENGTH 字段是1個字節(jié)短記錄的PAYLOAD_LENGTH 字段必須是0-255之間的值正常記錄的PAYLOAD_LENGTH 字段必須是0-232-1之間的值3 NDEF規(guī)范3.1 數(shù)據(jù)轉(zhuǎn)換順序本文檔中描述的NDEF 記錄發(fā)送順序被解析到字節(jié)水平。圖為一組字節(jié)，

35、這些字節(jié)傳輸?shù)捻樞蚴鞘紫葟淖蟮接?，再從上到下，就好像讀英文。例如在圖2中，字節(jié)組以它編號順序進行傳輸。圖2.NDEF字節(jié)順序每當一個字節(jié)表示一個數(shù)值量，圖中最左邊的位是高位或最重要的位。對于NDEF定義的、表示一個數(shù)值量的每個多字節(jié)字段，整個字段的最左邊的位是最重要的位。這樣的量是以大端方式傳輸，最重要的字節(jié)先傳輸。3.2 記錄布局NDEF 記錄是可變長度的記錄，通用格式如下圖中所示。 在以下章節(jié)中詳細地描述各個記錄的字段。圖3.NDEF記錄布局3.2.1 MB（消息起始）MB 標志的1比特字段被設(shè)置表明NDE F 消息開始。3.2.2 ME（消息結(jié)束）ME 標志的1比特字段被設(shè)置表明NDEF

36、 消息結(jié)束。3.2.3 CF（塊標志）CF 標志的1比特字段表明這是分塊有效負荷的第一個記錄塊或中間記錄塊（見2.3.3節(jié)關(guān)于如何編碼分塊有效負荷的描述）。3.2.4 SR（短記錄）SR 標志只有1比特字段，如果置位，表明PAYLOAD_LENGTH 字段是一個單一字節(jié)，這個簡短的記錄布局的目的是為緊湊封裝那些PAYLOAD 字段大小為0至255個字節(jié)不等的小型有效載荷。圖4.NDEF 短記錄布局（SR=1）雖然實施者傾向于針對特定應(yīng)用，選擇一個或另一個記錄布局，但NDEF 解析器必須接受正常和短記錄兩種布局。NDEF 產(chǎn)生器可能會生成它們認為合適的記錄布局。一個單一的 NDEF 消息可能包含

37、正常和短記錄。 3.2.5 IL（ID_LENGTH 字段） 所述IL 標志是一個1比特字段，如果置位，表明該ID_LENGTH 字段是作為一個單字節(jié)放在記錄頭部。如果IL 標志是0，ID_LENGTH 字段是從記錄頭省略，ID 字段被從記錄也被刪去。3.2.6 TNF（類型名稱格式）TNF 字段值表明表示TYPE 字段值的結(jié)構(gòu)（請參見2.4.2節(jié)TYPE 字段描述和第4節(jié)TYPE 字段相關(guān)的國際化問題的說明）。TNF 是3比特字段，值的定義如下表所示：表1.TNF字段值類型名稱格式 值空 0x00NFC 論壇 知名類型 NFC RTD 0x01 RFC 2046定義的媒體類型 RFC 204

38、6 0x02RFC 2986定義的絕對URI RFC 3986 0x03NFC 論壇外部類型 NFC RTD 0x04未知 0x05不變（見2.3.3節(jié)）0x06保留0x070x00值（空）表示不存在與該記錄相關(guān)的類型或有效載荷。在使用時， TYPE_LENGTH 、 ID_LENGTH 和 PAYLOAD_LENGTH 字段必須為零和類型，ID 和 PAYLOAD 字段從記錄省略。該TNF 值可以用于一個空記錄是必要的情況。例如，NDEF 消息結(jié)束的情況下，沒有由用戶應(yīng)用程序定義的有效載荷。值0x01 （ NFC 論壇知名類型）表示TYPE 字段包含的值遵循NFC 論壇的RTD 規(guī)范 NFC

39、 RTD 中 定義的 RTD 類型名稱格式。值0x02 （媒體類型）表示TYPE 字段包含一個值，遵循RFC 2046 RFC 2046 中定義的媒體類型的BNF 構(gòu)造。值0x03 （絕對URI）表示該類型字段包含一個值，該值遵循RFC 3986 RFC 3986 中定義的絕對 URI 的BNF 結(jié)構(gòu)。值0x04（ NFC 論壇外部類型）表示TYPE 字段包含一個值，遵循 NFC RTD 外部類型名稱定義的類型名稱格式。值0X05 （未知）被用來指示未知類型的有效負載。這類似于通過MIME RFC 定義的“應(yīng)用程序/ 字節(jié)流”媒體類型 2046 。使用時， TYPE_LENGTH 字段必須為零

40、，因此， TYPE 字段在 NDEF 記錄中被省略。關(guān)于執(zhí)行，建議NDEF 語法分析器接收到該類型的一個NDEF 記錄，并且沒有更多關(guān)于使用的上下文，提供一種只存儲但不處理有效負荷的機制（參見4.2節(jié)） 。0x06值（不變）必須在分塊有效載荷的所有中間記錄塊和終止記錄塊中使用（見2.3.3節(jié)） 。它不能用于其他記錄。使用時， TYPE_LENGTH 字段必須為零，因此， TYPE 字段在NDEF 記錄被省略。TNF 沒有默認值，未來用途的保留（或未分配）字段值禁止使用。獲取含有未知或不受支持的TNF 字段值的NDEF 記錄，NDEF 解析器視為0x05（未知）。3.2.7 TYPE_LENGT

41、H該TYPE_LENGTH 字段是一個無符號8比特整數(shù)，它指定TYPE 字段的字節(jié)長度。該TYPE_LENGTH 字段對某些TNF 值總是為零（見3.2.6節(jié)） 。3.2.8 ID_LENGTH該ID_LENGTH 字段是一個無符號8比特整數(shù)，指定ID 字段的字節(jié)長度。這個字段只有在記錄頭中IL 標志被設(shè)置為1時存在。允許0字節(jié) ID_LENGTH ，在這種情況下， ID 字段在NDEF 記錄省略。3.2.9 PAYLOAD_LENGTH該PAYLOAD_LENGTH 字段是一個無符號整數(shù)，它指定PAYLOAD（應(yīng)用程序有效載荷）字段的字節(jié)長度。該PAYLOAD_LENGTH 字段的大小是由S

42、R 標志的值確定（見3.2.4節(jié)） 。 如果SR 標志被設(shè)置， PAYLOAD_LENGTH 字段是表示一個8比特無符號整數(shù)的單字節(jié)。如果SR 標志被清除， PAYLOAD_LENGTH 字段占4個字節(jié)，表示一個32比特無符號整數(shù)。字節(jié)的傳輸順序是MSB 優(yōu)先（參見3.1節(jié)） 。0字節(jié)長度的有效載荷長度允許的，在這種情況下，有效載荷字段在NDEF 記錄中被省略。超過232 -1個字節(jié)大小的應(yīng)用程序有效載荷可以被分塊有效載荷容納（參見2.3.3節(jié)） 。3.2.10 TYPETYPE 字段的值是描述有效負載類型（參見2.4.2節(jié)）的標識符。TYPE 字段的值必須遵循TNF 字段值代表的結(jié)構(gòu)、編碼和

43、格式（見3.2.6節(jié)） 。一個NDEF 語法分析器接收了一個包含它支持被未知的TNF 字段值的NDEF 記錄，如果TNF字段值是0X05 （未知），TYPE 字段應(yīng)該解釋該記錄的類型標識符，。我們強烈建議該類型標識符是全球唯一的，并總是保持穩(wěn)定和明確的語義。3.2.11 IDID 字段的值是一個URI 引用RFC 3986 形式的標識符（見第2.4.3和4.4節(jié) ） 。消息標識符的唯一性需要由發(fā)生器保證。URI 引用可以是相對或絕對的； NDEF 沒有定義基本URI 意味著使用相對URI 的用戶應(yīng)用程序必須提供一個實際或虛擬基礎(chǔ)URI（參見 RFC 3986 ） 。中間和終止記錄塊（即不包含分

44、塊有效負荷初始記錄塊的其他記錄，見2.3.3節(jié)）不能有ID 字段。所有其他記錄可以有一個ID 字段。3.2.12 PAYLOADPAYLOAD 字段攜帶用于NDEF 應(yīng)用程序的有效負荷。任何內(nèi)部有效載荷字段中攜帶的數(shù)據(jù)結(jié)構(gòu)對NDEF 都是不透明的。3.3 NDEF機制測試要求本節(jié)確認在第3章中定義的NDEF 機制的可測試的需求。 本節(jié)和下表的目的是指導一致性測試過程，并不能取代在本章的其他部分提出的規(guī)范性要求。 測試要求2.NDEF規(guī)范測試要求數(shù)據(jù)傳輸順序要求大量數(shù)據(jù)時以大端方式傳送，最重要的字節(jié)先傳。記錄布局要求NDEF解析器必須接收正常記錄和短記錄兩種布局。NDEF 解析器必須接受正常布局和短記錄布局兩種方式組成的NDEF消息。如果IL 標志是1，ID_LENGTH 字段必須存在。如果IL 標志是0，ID_LENGTH 字段禁止存在。如果IL 標志是0，ID 字段禁止存在。TNF字段的值必須在0x00到0x06之間。如果TNF 值為0x00，那么TYPE_IENGTH,ID_