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 機制的可測試要求。本節和下表的目的是指導一致性測試的開發，而不是取代本章其他章節中提出的規範要求。

| 記錄塊要求 | | ---------------------------------------------------------- | | 每個分塊載荷被編碼為一個初始記錄塊，然後是 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 機制的可測試要求。本節的目的是指導一致性測試的開發，而不是取代本章其他章節中提出的規範要求。

| 記錄格式要求 | | --------------------------------------------------------------------------------------------------- | | 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欄位大於其設計限制的訊息。