NDEF進入NFC世界的任意門之 1

NFC的手機與 NFC標籤(TAG) 之所以可以達到許多網際連接與互動訊息，就是依靠解析存放在TAG記憶體內NDEF訊息區塊的資料，所得到的指示與行動。

你大概也知道，現在市面上的智慧型手機，有著不同的作業系統(OS)；就像 APPLE 的 iPhone 是 iOS、Google的手機用 Android；而不同廠牌的手機，就算是都以 Android 為主，也都還會有一些小小的差異。如果要讓不同廠牌、甚至不同作業系統的 NFC手機之間，都可以讀取同一個 NFC標籤，來共享信息的交換的話，就必須制定出一套標準，如同網頁的 HTML 語法。

這就是 NFC協會所制定 NDEF 規範的目的：『即便是使用不同的NFC的手機，都可以用來讀取 NFC標籤的資料。而之所以可以完成網際連接與互動訊息的傳遞，就是依靠解析存放在標籤記憶體內 NDEF 訊息區塊的資料，所得到的指示與行動。』基本上， NDEF 訊息的複雜程度和存放記憶體的容量大小，有著一定的關係。這意味著只要有足夠的容量，可以設定不只是網際資源的連接，還可以包含自行定義特殊格式(Proprietary)的資料。當然，這些自行定義的資料，還是需要開發特定的App來解讀。

常見的NDEF紀錄，可以不用APP就可以感應讀取

在 NFC協會所規範的NDEF紀錄，是很完整涵蓋多種的應用：包括網址、網路資源定址、藍牙配對、加密簽證......等等。但不是每一種紀錄，都可以直接被NFC手機讀取而被解析到，更何況iOS與Android的支援程度也不一定，所以有些還是必須靠特定的APP來解析。以下列出常用可被雙平台解析的NDEF範例：

網址：Website URL - https://www.example.com
電子郵箱：Email - mailto:user@example.com
簡訊：SMS - sms:+886988166888
電話：Telephone - tel:+886988166888[Website URL (HTTP/HTTPS)

https://www.example.com](Website%20URL%20(HTTP/HTTPS)%20%20https://www.example.com)[Website URL (HTTP/HTTPS)

https://www.example.com](Website%20URL%20(HTTP/HTTPS)%20%20https://www.example.com)

NDEF紀錄的格式

在標準的 NDEF 訊息區塊內所描述的 資源記錄(Record) 可以不只一筆(如 圖1 )，但均需符合 NFC協會的記錄類別標準 (RTD; Record Type Definition) 文件裡所定義的規範。

NFC的手機與NFC標籤之所以可以達到許多網際連接與互動訊息，就是依靠解析TAG的NDEF...

NDEF進入NFC世界的任意門之 1：內文圖片 1

圖1. NDEF訊息的基本格式

在 NFC協會所定義簡單的資源記錄(Record)中，如：文字記錄 (RTD_TEXT)、資源定址記錄 (RTD_URI)或是 MIME媒體位址記錄 (Media Recoed)，大都只包含單獨的一筆記錄。而較複雜的 智慧型海報記錄 (RTD_SMART_POSTER) 與 數位簽章記錄 (RTD_SIGNATURE)，則可以包含多筆的記錄來組成。

這些所謂不同類別的記錄，均以同一種格式，但其內的資料長度可能不同的方式來描述；為了能達到完整描述一連串的資料，均採用 表頭(Header)＋ 資料內容(Payload) 的格式來進行；而這裡所謂的表頭，其實是指這筆記錄的 類別與型式 (Flags & TNF)；每一筆記錄資料內容的長度，就由 表頭 這個位元組來定義，並依此決定其後所存在的欄位組成。

一筆正常的記錄其資料格式如 圖2 所示：大致包含有此記錄類別名稱的長度 (TYPE\_LENGTH)、最多有4個位元組的資料內容長度 (PAYLOAD\_LENGTH3~0)、資源標識碼的長度 (ID\_LENGTH)、類別名稱 (TYPE\_NAME)、資源標識碼 (ID)與資料本身的內容 (DATA PAYLOAD)。

NDEF進入NFC世界的任意門之 1：內文圖片 2

圖2. 只含單筆資源紀錄的NDEF訊息格式

在 圖2 這筆紀錄內，標示前往某特定網站的網址連結：『https://reactnative.dev/』

[在圖2 這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/

NDEF的靈魂：表頭 ](在%20圖2%20這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/%20%20%20NDEF的靈魂：表頭%20)**NDEF的靈魂：表頭

現在回顧一下，在 圖1 所顯示是由3筆 NDEF 紀錄所組成的訊息，我們來看看怎麼由各紀錄的表頭裡的各個功能位元(Bit)來把每筆紀錄串起來。在表頭的前兩個功能位元(Bit7, Bit6)，分別為：

MB (Message Begin) MB=1; 表示為訊息的第一筆記錄。
ME (Message End) ME=1; 表示為訊息的最後一筆記錄。

所以，如果訊息僅含一筆記錄，則該筆紀錄的表頭的 MB=1, ME=1；如果是圖中的多筆紀錄型態，第一筆的紀錄表頭的 MB=1, ME=0，這樣我們知道這是開頭的第一筆，因為ME=0就表示後面還有紀錄；再來看第二筆紀錄的表頭的 MB=ME=0，明顯地說明後面還有紀錄；最後，第三筆紀錄的表頭的 MB=0, 但ME=1，表示已經到了最後一筆紀錄。你有沒有發現，訊息本身並沒有什麼欄位明顯指名訊息裡有多少筆紀錄，所以當循序一筆一筆資料爬進來的同時，一邊解析的同時也要進行統計。再來，看看其他的功能位元：

CF (Chunked Message) CF=1; 表示為分段訊息，表示這個標籤內容，僅為一個超長訊息的其中一部分訊息；其他部分則存在其他的標籤中。
SR (Short Record) SR=1; 表示為短記錄型式，PAYLOAD_LENGTH僅以單一位元組來定義，表示其後資料內容長度將不超254個位元組。 SR=0; 表示資料內容的長度將以4個位元組來表示。
IL (ID Length) IL=1; 表示會有ID長度標示的位元組；反之，IL=0; 表示ID LENGTH與ID均被省略。

而最後的3個位元組合成所謂的TNF：

TNF (Type Name Format) 在NDEF訊息裡的每筆記錄，都先必須在記錄的表頭宣告其形態的名稱，而這些名稱又分成幾類的名稱格式 (Type Name Format)：
0x00 Empty Record; 僅有此狀態位元組。
0x01 Well_Known Record; (TEXT, URI(http, https, sms, mailto...), SmartPoster, Signature)
0x02 MIME Media Record; MIME所定義的媒體記錄
0x03 Absolute URI Record; 絕對URI記錄
0x04 External Record; Domain名稱＋“：”＋類形名稱
0x05 Unknown Record; TYPE_LENGTH=0且TYPE被省略。
0x06 Unchanged Record; TYPE_LENGTH=0且TYPE被省略。[在圖2 這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/

NDEF的靈魂：表頭

圖2. 只含單筆資源紀錄的NDEF訊息格式

在圖2 這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/ ](%20%20%20%20%20圖2.%20只含單筆資源紀錄的NDEF訊息格式%20%20%20在%20圖2%20這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/%20)[[[[\[NDEF基本篇-1\] by Roger Luo

NFC的手機與NFC標籤之所以可以達到許多網際連接與互動訊息，就是依靠解析存放在TAG記憶體內NDEF訊息區塊的資料，所得到的指示與行動。

你大概也知道，現在市面上的智慧型手機，有著不同的作業系統(OS)；就像APPLE的iPhone是 iOS、Google的手機用Android。而不同廠牌的手機，就算是都以 Android 為主，也都還會有一些小小的差異。如果要讓不同廠牌、甚至不同作業系統的 NFC手機之間，都可以讀取同一個 NFC標籤，來共享信息的交換的話，就必須制定出一套標準，如同網頁的 HTML語法。

這就是 NFC協會所制定 NDEF 規範的目的：即便是使用不同的NFC的手機，都可以用來讀取 NFC標籤的資料。而之所以可以完成網際連接與互動訊息的傳遞，就是依靠解析存放在標籤記憶體內 NDEF 訊息區塊的資料，所得到的指示與行動。基本上， NDEF 訊息的複雜程度和存放的記憶體的容量大小，有著一定的關係。這意味著只要有足夠的容量，可以設定不只是網際資源的連接，還可以包含自行定義特殊格式(Proprietary)的資料。當然，這些自行定義的資料，你必須開發特定的App來解讀。

在標準的 NDEF 訊息區塊內所描述的資源記錄(Record)可以不只一筆(如下圖)，但均需符合 NFC協會的記錄類別標準(RTD; Record Type Definition)文件裡所定義的規範。

圖1. NDEF訊息的基本格式

NDEF的記錄格式

在 NFC協會所定義簡單的資源記錄(Record)中，如：文字記錄 (RTD_TEXT)、資源定址記錄 (RTD_URI)或是 MIME媒體位址記錄 (Media Recoed)，大都只包含單獨的一筆記錄。而較複雜的智慧型海報記錄 (RTD_SMART_POSTER) 與數位簽章記錄 (RTD_SIGNATURE)，則可以包含多筆的記錄來組成。

這些所謂不同類別的記錄，均以同一種格式，但其內的資料長度可能不同的方式來描述；為了能達到完整描述一連串的資料，均採用表頭(Header)＋資料內容(Payload)的格式來進行；而這裡所謂的表頭，其實是指這筆記錄的類別與型式(Flags & TNF)；每一筆記錄資料內容的長度，就由表頭這個位元組來定義，並依此決定其後所存在的欄位組成。

一筆正常的記錄其資料格式如(圖2)所示：大致包含有此記錄類別名稱的長度(TYPE_LENGTH)、最多有4個位元組的資料內容長度(PAYLOAD_LENGTH3~0)、資源標識碼的長度(ID_LENGTH)、類別名稱(TYPE_NAME)、資源標識碼(ID)與資料本身的內容(DATA PAYLOAD)。

圖2. 只含單筆資源紀錄的NDEF訊息格式

在圖2 這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/

NDEF的靈魂：表頭

現在回顧一下，在圖1所顯示是由3筆NDEF紀錄所組成的訊息，我們來看看怎麼由各紀錄的表頭裡的各個功能位元(Bit)來把每筆紀錄串起來。在表頭的前兩個功能位元(Bit7, Bit6)，分別為： MB (Message Begin) MB=1; 表示為訊息的第一筆記錄。ME (Message End) ME=1; 表示為訊息的最後一筆記錄。所以，如果訊息僅含一筆記錄，則該筆紀錄的表頭的 MB=1, ME=1；如果是圖中的多筆紀錄型態，第一筆的紀錄表頭的 MB=1, ME=0，這樣我們知道這是開頭的第一筆，因為ME=0就表示後面還有紀錄；再來看第二筆紀錄的表頭的 MB=ME=0，明顯地說明後面還有紀錄；最後，第三筆紀錄的表頭的 MB=0, 但ME=1，表示已經到了最後一筆紀錄。你有沒有發現，訊息本身並沒有什麼欄位明顯指名訊息裡有多少筆紀錄，所以當循序一筆一筆資料爬進來的同時，一邊解析的同時也要進行統計。再來，看看其他的功能位元： CF (Chunked Message) CF=1; 表示為分段訊息，表示這個標籤內容，僅為一個超長訊息的其中一部分訊息；其他部分則存在其他的標籤中。SR (Short Record) SR=1; 表示為短記錄型式，PAYLOAD_LENGTH僅以單一位元組來定義，表示其後資料內容長度將不超254個位元組。 SR=0; 表示資料內容的長度將以4個位元組來表示。IL (ID Length) IL=1; 表示會有ID長度標示的位元組；反之，IL=0; 表示ID LENGTH與ID均被省略。而最後的3個位元組合成所謂的TNF： TNF (Type Name Format) 在NDEF訊息裡的每筆記錄，都先必須在記錄的表頭宣告其形態的名稱，而這些名稱又分成幾類的名稱格式 (Type Name Format)： - 0x00 Empty Record; 僅有此狀態位元組。 - 0x01 Well_Known Record; (TEXT, URI(http, https, sms, mailto...), SmartPoster, Signature) - 0x02 MIME Media Record; MIME所定義的媒體記錄 - 0x03 Absolute URI Record; 絕對URI記錄 - 0x04 External Record; Domain名稱＋“：”＋類形名稱 - 0x05 Unknown Record; TYPE_LENGTH=0且TYPE被省略。 - 0x06 Unchanged Record; TYPE_LENGTH=0且TYPE被省略。 ]([NDEF基本篇-1]%20by%20Roger%20Luo%20%20%20NFC的手機與NFC標籤之所以可以達到許多網際連接與互動訊息，就是依靠解析存放在TAG記憶體內NDEF訊息區塊的資料，所得到的指示與行動。%20%20%20你大概也知道，現在市面上的智慧型手機，有著不同的作業系統(OS)；就像APPLE的iPhone是%20iOS、Google的手機用Android。而不同廠牌的手機，就算是都以%20Android%20為主，也都還會有一些小小的差異。如果要讓不同廠牌、甚至不同作業系統的%20NFC手機之間，都可以讀取同一個%20NFC標籤，來共享信息的交換的話，就必須制定出一套標準，如同網頁的%20HTML語法。%20%20%20這就是%20NFC協會所制定%20NDEF%20規範的目的：即便是使用不同的NFC的手機，都可以用來讀取%20NFC標籤的資料。而之所以可以完成網際連接與互動訊息的傳遞，就是依靠解析存放在標籤記憶體內%20NDEF%20訊息區塊的資料，所得到的指示與行動。%20基本上，%20NDEF%20訊息的複雜程度和存放的記憶體的容量大小，有著一定的關係。%20這意味著只要有足夠的容量，可以設定不只是網際資源的連接，還可以包含自行定義特殊格式(Proprietary)的資料。當然，這些自行定義的資料，你必須開發特定的App來解讀。%20%20%20在標準的%20NDEF%20訊息區塊內所描述的資源記錄(Record)可以不只一筆(如下圖)，但均需符合%20NFC協會的記錄類別標準(RTD;%20Record%20Type%20Definition)文件裡所定義的規範。%20%20%20%20%20%20%20%20%20%20圖1.%20NDEF訊息的基本格式%20%20%20NDEF的記錄格式%20%20%20在%20NFC協會所定義簡單的資源記錄(Record)中，如：文字記錄%20(RTD_TEXT)、資源定址記錄%20(RTD_URI)或是%20MIME媒體位址記錄%20(Media%20Recoed)，大都只包含單獨的一筆記錄。%20而較複雜的%20智慧型海報記錄%20(RTD_SMART_POSTER)%20與%20數位簽章記錄%20(RTD_SIGNATURE)，則可以包含多筆的記錄來組成。%20%20%20%20這些所謂不同類別的記錄，均以同一種格式，但其內的資料長度可能不同的方式來描述；為了能達到完整描述一連串的資料，均採用表頭(Header)＋資料內容(Payload)的格式來進行；而這裡所謂的表頭，其實是指這筆記錄的類別與型式(Flags%20&%20TNF)；每一筆記錄資料內容的長度，就由表頭這個位元組來定義，並依此決定其後所存在的欄位組成。%20%20%20一筆正常的記錄其資料格式如(圖2)所示：大致包含有此記錄類別名稱的長度(TYPE_LENGTH)、最多有4個位元組的資料內容長度(PAYLOAD_LENGTH30)、資源標識碼的長度(ID_LENGTH)、類別名稱(TYPE_NAME)、資源標識碼(ID)與資料本身的內容(DATA%20PAYLOAD)。%20%20%20%20%20%20%20%20%20%20圖2.%20只含單筆資源紀錄的NDEF訊息格式%20%20%20在%20圖2%20這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/%20%20%20NDEF的靈魂：表頭%20%20%20現在回顧一下，在圖1所顯示是由3筆NDEF紀錄所組成的訊息，我們來看看怎麼由各紀錄的表頭裡的各個功能位元(Bit)來把每筆紀錄串起來。在表頭的前兩個功能位元(Bit7,%20Bit6)，分別為：%20MB%20(Message%20Begin)%20MB=1;%20表示為訊息的第一筆記錄。ME%20(Message%20End)%20ME=1;%20表示為訊息的最後一筆記錄。%20所以，如果訊息僅含一筆記錄，則該筆紀錄的表頭的%20MB=1,%20ME=1；如果是圖中的多筆紀錄型態，第一筆的紀錄表頭的%20MB=1,%20ME=0，這樣我們知道這是開頭的第一筆，因為ME=0就表示後面還有紀錄；再來看第二筆紀錄的表頭的%20MB=ME=0，明顯地說明後面還有紀錄；最後，第三筆紀錄的表頭的%20MB=0,%20但ME=1，表示已經到了最後一筆紀錄。你有沒有發現，訊息本身並沒有什麼欄位明顯指名訊息裡有多少筆紀錄，所以當循序一筆一筆資料爬進來的同時，一邊解析的同時也要進行統計。再來，看看其他的功能位元：%20CF%20(Chunked%20Message)%20CF=1;%20表示為分段訊息，表示這個標籤內容，僅為一個超長訊息的其中一部分訊息；其他部分則存在其他的標籤中。SR%20(Short%20Record)%20SR=1;%20表示為短記錄型式，PAYLOAD_LENGTH僅以單一位元組來定義，表示其後資料內容長度將不超254個位元組。%20SR=0;%20表示資料內容的長度將以4個位元組來表示。IL%20(ID%20Length)%20IL=1;%20表示會有ID長度標示的位元組；反之，IL=0;%20表示ID%20LENGTH與ID均被省略。%20而最後的3個位元組合成所謂的TNF：%20TNF%20(Type%20Name%20Format)%20在NDEF訊息裡的每筆記錄，都先必須在記錄的表頭宣告其形態的名稱，而這些名稱又分成幾類的名稱格式%20(Type%20Name%20Format)：%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x00%20Empty%20Record;%20僅有此狀態位元組。%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x01%20Well_Known%20Record;%20%20(TEXT,%20URI(http,%20https,%20sms,%20mailto...),%20SmartPoster,%20Signature)%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x02%20MIME%20Media%20Record;%20MIME所定義的媒體記錄%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x03%20Absolute%20URI%20Record;%20絕對URI記錄%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x04%20External%20Record;%20Domain名稱＋“：”＋類形名稱%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x05%20Unknown%20Record;%20TYPE_LENGTH=0且TYPE被省略。%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x06%20Unchanged%20Record;%20TYPE_LENGTH=0且TYPE被省略。%20)]([NDEF基本篇-1]%20by%20Roger%20Luo%20%20%20NFC的手機與NFC標籤之所以可以達到許多網際連接與互動訊息，就是依靠解析存放在TAG記憶體內NDEF訊息區塊的資料，所得到的指示與行動。%20%20%20你大概也知道，現在市面上的智慧型手機，有著不同的作業系統(OS)；就像APPLE的iPhone是%20iOS、Google的手機用Android。而不同廠牌的手機，就算是都以%20Android%20為主，也都還會有一些小小的差異。如果要讓不同廠牌、甚至不同作業系統的%20NFC手機之間，都可以讀取同一個%20NFC標籤，來共享信息的交換的話，就必須制定出一套標準，如同網頁的%20HTML語法。%20%20%20這就是%20NFC協會所制定%20NDEF%20規範的目的：即便是使用不同的NFC的手機，都可以用來讀取%20NFC標籤的資料。而之所以可以完成網際連接與互動訊息的傳遞，就是依靠解析存放在標籤記憶體內%20NDEF%20訊息區塊的資料，所得到的指示與行動。%20基本上，%20NDEF%20訊息的複雜程度和存放的記憶體的容量大小，有著一定的關係。%20這意味著只要有足夠的容量，可以設定不只是網際資源的連接，還可以包含自行定義特殊格式(Proprietary)的資料。當然，這些自行定義的資料，你必須開發特定的App來解讀。%20%20%20在標準的%20NDEF%20訊息區塊內所描述的資源記錄(Record)可以不只一筆(如下圖)，但均需符合%20NFC協會的記錄類別標準(RTD;%20Record%20Type%20Definition)文件裡所定義的規範。%20%20%20%20%20%20%20%20%20%20圖1.%20NDEF訊息的基本格式%20%20%20NDEF的記錄格式%20%20%20在%20NFC協會所定義簡單的資源記錄(Record)中，如：文字記錄%20(RTD_TEXT)、資源定址記錄%20(RTD_URI)或是%20MIME媒體位址記錄%20(Media%20Recoed)，大都只包含單獨的一筆記錄。%20而較複雜的%20智慧型海報記錄%20(RTD_SMART_POSTER)%20與%20數位簽章記錄%20(RTD_SIGNATURE)，則可以包含多筆的記錄來組成。%20%20%20%20這些所謂不同類別的記錄，均以同一種格式，但其內的資料長度可能不同的方式來描述；為了能達到完整描述一連串的資料，均採用表頭(Header)＋資料內容(Payload)的格式來進行；而這裡所謂的表頭，其實是指這筆記錄的類別與型式(Flags%20&%20TNF)；每一筆記錄資料內容的長度，就由表頭這個位元組來定義，並依此決定其後所存在的欄位組成。%20%20%20一筆正常的記錄其資料格式如(圖2)所示：大致包含有此記錄類別名稱的長度(TYPE_LENGTH)、最多有4個位元組的資料內容長度(PAYLOAD_LENGTH30)、資源標識碼的長度(ID_LENGTH)、類別名稱(TYPE_NAME)、資源標識碼(ID)與資料本身的內容(DATA%20PAYLOAD)。%20%20%20%20%20%20%20%20%20%20圖2.%20只含單筆資源紀錄的NDEF訊息格式%20%20%20在%20圖2%20這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/%20%20%20NDEF的靈魂：表頭%20%20%20現在回顧一下，在圖1所顯示是由3筆NDEF紀錄所組成的訊息，我們來看看怎麼由各紀錄的表頭裡的各個功能位元(Bit)來把每筆紀錄串起來。在表頭的前兩個功能位元(Bit7,%20Bit6)，分別為：%20MB%20(Message%20Begin)%20MB=1;%20表示為訊息的第一筆記錄。ME%20(Message%20End)%20ME=1;%20表示為訊息的最後一筆記錄。%20所以，如果訊息僅含一筆記錄，則該筆紀錄的表頭的%20MB=1,%20ME=1；如果是圖中的多筆紀錄型態，第一筆的紀錄表頭的%20MB=1,%20ME=0，這樣我們知道這是開頭的第一筆，因為ME=0就表示後面還有紀錄；再來看第二筆紀錄的表頭的%20MB=ME=0，明顯地說明後面還有紀錄；最後，第三筆紀錄的表頭的%20MB=0,%20但ME=1，表示已經到了最後一筆紀錄。你有沒有發現，訊息本身並沒有什麼欄位明顯指名訊息裡有多少筆紀錄，所以當循序一筆一筆資料爬進來的同時，一邊解析的同時也要進行統計。再來，看看其他的功能位元：%20CF%20(Chunked%20Message)%20CF=1;%20表示為分段訊息，表示這個標籤內容，僅為一個超長訊息的其中一部分訊息；其他部分則存在其他的標籤中。SR%20(Short%20Record)%20SR=1;%20表示為短記錄型式，PAYLOAD_LENGTH僅以單一位元組來定義，表示其後資料內容長度將不超254個位元組。%20SR=0;%20表示資料內容的長度將以4個位元組來表示。IL%20(ID%20Length)%20IL=1;%20表示會有ID長度標示的位元組；反之，IL=0;%20表示ID%20LENGTH與ID均被省略。%20而最後的3個位元組合成所謂的TNF：%20TNF%20(Type%20Name%20Format)%20在NDEF訊息裡的每筆記錄，都先必須在記錄的表頭宣告其形態的名稱，而這些名稱又分成幾類的名稱格式%20(Type%20Name%20Format)：%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x00%20Empty%20Record;%20僅有此狀態位元組。%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x01%20Well_Known%20Record;%20%20(TEXT,%20URI(http,%20https,%20sms,%20mailto...),%20SmartPoster,%20Signature)%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x02%20MIME%20Media%20Record;%20MIME所定義的媒體記錄%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x03%20Absolute%20URI%20Record;%20絕對URI記錄%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x04%20External%20Record;%20Domain名稱＋“：”＋類形名稱%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x05%20Unknown%20Record;%20TYPE_LENGTH=0且TYPE被省略。%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x06%20Unchanged%20Record;%20TYPE_LENGTH=0且TYPE被省略。%20)]([NDEF基本篇-1]%20by%20Roger%20Luo%20%20%20NFC的手機與NFC標籤之所以可以達到許多網際連接與互動訊息，就是依靠解析存放在TAG記憶體內NDEF訊息區塊的資料，所得到的指示與行動。%20%20%20你大概也知道，現在市面上的智慧型手機，有著不同的作業系統(OS)；就像APPLE的iPhone是%20iOS、Google的手機用Android。而不同廠牌的手機，就算是都以%20Android%20為主，也都還會有一些小小的差異。如果要讓不同廠牌、甚至不同作業系統的%20NFC手機之間，都可以讀取同一個%20NFC標籤，來共享信息的交換的話，就必須制定出一套標準，如同網頁的%20HTML語法。%20%20%20這就是%20NFC協會所制定%20NDEF%20規範的目的：即便是使用不同的NFC的手機，都可以用來讀取%20NFC標籤的資料。而之所以可以完成網際連接與互動訊息的傳遞，就是依靠解析存放在標籤記憶體內%20NDEF%20訊息區塊的資料，所得到的指示與行動。%20基本上，%20NDEF%20訊息的複雜程度和存放的記憶體的容量大小，有著一定的關係。%20這意味著只要有足夠的容量，可以設定不只是網際資源的連接，還可以包含自行定義特殊格式(Proprietary)的資料。當然，這些自行定義的資料，你必須開發特定的App來解讀。%20%20%20在標準的%20NDEF%20訊息區塊內所描述的資源記錄(Record)可以不只一筆(如下圖)，但均需符合%20NFC協會的記錄類別標準(RTD;%20Record%20Type%20Definition)文件裡所定義的規範。%20%20%20%20%20%20%20%20%20%20圖1.%20NDEF訊息的基本格式%20%20%20NDEF的記錄格式%20%20%20在%20NFC協會所定義簡單的資源記錄(Record)中，如：文字記錄%20(RTD_TEXT)、資源定址記錄%20(RTD_URI)或是%20MIME媒體位址記錄%20(Media%20Recoed)，大都只包含單獨的一筆記錄。%20而較複雜的%20智慧型海報記錄%20(RTD_SMART_POSTER)%20與%20數位簽章記錄%20(RTD_SIGNATURE)，則可以包含多筆的記錄來組成。%20%20%20%20這些所謂不同類別的記錄，均以同一種格式，但其內的資料長度可能不同的方式來描述；為了能達到完整描述一連串的資料，均採用表頭(Header)＋資料內容(Payload)的格式來進行；而這裡所謂的表頭，其實是指這筆記錄的類別與型式(Flags%20&%20TNF)；每一筆記錄資料內容的長度，就由表頭這個位元組來定義，並依此決定其後所存在的欄位組成。%20%20%20一筆正常的記錄其資料格式如(圖2)所示：大致包含有此記錄類別名稱的長度(TYPE_LENGTH)、最多有4個位元組的資料內容長度(PAYLOAD_LENGTH30)、資源標識碼的長度(ID_LENGTH)、類別名稱(TYPE_NAME)、資源標識碼(ID)與資料本身的內容(DATA%20PAYLOAD)。%20%20%20%20%20%20%20%20%20%20圖2.%20只含單筆資源紀錄的NDEF訊息格式%20%20%20在%20圖2%20這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/%20%20%20NDEF的靈魂：表頭%20%20%20現在回顧一下，在圖1所顯示是由3筆NDEF紀錄所組成的訊息，我們來看看怎麼由各紀錄的表頭裡的各個功能位元(Bit)來把每筆紀錄串起來。在表頭的前兩個功能位元(Bit7,%20Bit6)，分別為：%20MB%20(Message%20Begin)%20MB=1;%20表示為訊息的第一筆記錄。ME%20(Message%20End)%20ME=1;%20表示為訊息的最後一筆記錄。%20所以，如果訊息僅含一筆記錄，則該筆紀錄的表頭的%20MB=1,%20ME=1；如果是圖中的多筆紀錄型態，第一筆的紀錄表頭的%20MB=1,%20ME=0，這樣我們知道這是開頭的第一筆，因為ME=0就表示後面還有紀錄；再來看第二筆紀錄的表頭的%20MB=ME=0，明顯地說明後面還有紀錄；最後，第三筆紀錄的表頭的%20MB=0,%20但ME=1，表示已經到了最後一筆紀錄。你有沒有發現，訊息本身並沒有什麼欄位明顯指名訊息裡有多少筆紀錄，所以當循序一筆一筆資料爬進來的同時，一邊解析的同時也要進行統計。再來，看看其他的功能位元：%20CF%20(Chunked%20Message)%20CF=1;%20表示為分段訊息，表示這個標籤內容，僅為一個超長訊息的其中一部分訊息；其他部分則存在其他的標籤中。SR%20(Short%20Record)%20SR=1;%20表示為短記錄型式，PAYLOAD_LENGTH僅以單一位元組來定義，表示其後資料內容長度將不超254個位元組。%20SR=0;%20表示資料內容的長度將以4個位元組來表示。IL%20(ID%20Length)%20IL=1;%20表示會有ID長度標示的位元組；反之，IL=0;%20表示ID%20LENGTH與ID均被省略。%20而最後的3個位元組合成所謂的TNF：%20TNF%20(Type%20Name%20Format)%20在NDEF訊息裡的每筆記錄，都先必須在記錄的表頭宣告其形態的名稱，而這些名稱又分成幾類的名稱格式%20(Type%20Name%20Format)：%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x00%20Empty%20Record;%20僅有此狀態位元組。%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x01%20Well_Known%20Record;%20%20(TEXT,%20URI(http,%20https,%20sms,%20mailto...),%20SmartPoster,%20Signature)%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x02%20MIME%20Media%20Record;%20MIME所定義的媒體記錄%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x03%20Absolute%20URI%20Record;%20絕對URI記錄%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x04%20External%20Record;%20Domain名稱＋“：”＋類形名稱%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x05%20Unknown%20Record;%20TYPE_LENGTH=0且TYPE被省略。%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x06%20Unchanged%20Record;%20TYPE_LENGTH=0且TYPE被省略。%20)]([NDEF基本篇-1]%20by%20Roger%20Luo%20%20%20NFC的手機與NFC標籤之所以可以達到許多網際連接與互動訊息，就是依靠解析存放在TAG記憶體內NDEF訊息區塊的資料，所得到的指示與行動。%20%20%20你大概也知道，現在市面上的智慧型手機，有著不同的作業系統(OS)；就像APPLE的iPhone是%20iOS、Google的手機用Android。而不同廠牌的手機，就算是都以%20Android%20為主，也都還會有一些小小的差異。如果要讓不同廠牌、甚至不同作業系統的%20NFC手機之間，都可以讀取同一個%20NFC標籤，來共享信息的交換的話，就必須制定出一套標準，如同網頁的%20HTML語法。%20%20%20這就是%20NFC協會所制定%20NDEF%20規範的目的：即便是使用不同的NFC的手機，都可以用來讀取%20NFC標籤的資料。而之所以可以完成網際連接與互動訊息的傳遞，就是依靠解析存放在標籤記憶體內%20NDEF%20訊息區塊的資料，所得到的指示與行動。%20基本上，%20NDEF%20訊息的複雜程度和存放的記憶體的容量大小，有著一定的關係。%20這意味著只要有足夠的容量，可以設定不只是網際資源的連接，還可以包含自行定義特殊格式(Proprietary)的資料。當然，這些自行定義的資料，你必須開發特定的App來解讀。%20%20%20在標準的%20NDEF%20訊息區塊內所描述的資源記錄(Record)可以不只一筆(如下圖)，但均需符合%20NFC協會的記錄類別標準(RTD;%20Record%20Type%20Definition)文件裡所定義的規範。%20%20%20%20%20%20%20%20%20%20圖1.%20NDEF訊息的基本格式%20%20%20NDEF的記錄格式%20%20%20在%20NFC協會所定義簡單的資源記錄(Record)中，如：文字記錄%20(RTD_TEXT)、資源定址記錄%20(RTD_URI)或是%20MIME媒體位址記錄%20(Media%20Recoed)，大都只包含單獨的一筆記錄。%20而較複雜的%20智慧型海報記錄%20(RTD_SMART_POSTER)%20與%20數位簽章記錄%20(RTD_SIGNATURE)，則可以包含多筆的記錄來組成。%20%20%20%20這些所謂不同類別的記錄，均以同一種格式，但其內的資料長度可能不同的方式來描述；為了能達到完整描述一連串的資料，均採用表頭(Header)＋資料內容(Payload)的格式來進行；而這裡所謂的表頭，其實是指這筆記錄的類別與型式(Flags%20&%20TNF)；每一筆記錄資料內容的長度，就由表頭這個位元組來定義，並依此決定其後所存在的欄位組成。%20%20%20一筆正常的記錄其資料格式如(圖2)所示：大致包含有此記錄類別名稱的長度(TYPE_LENGTH)、最多有4個位元組的資料內容長度(PAYLOAD_LENGTH30)、資源標識碼的長度(ID_LENGTH)、類別名稱(TYPE_NAME)、資源標識碼(ID)與資料本身的內容(DATA%20PAYLOAD)。%20%20%20%20%20%20%20%20%20%20圖2.%20只含單筆資源紀錄的NDEF訊息格式%20%20%20在%20圖2%20這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/%20%20%20NDEF的靈魂：表頭%20%20%20現在回顧一下，在圖1所顯示是由3筆NDEF紀錄所組成的訊息，我們來看看怎麼由各紀錄的表頭裡的各個功能位元(Bit)來把每筆紀錄串起來。在表頭的前兩個功能位元(Bit7,%20Bit6)，分別為：%20MB%20(Message%20Begin)%20MB=1;%20表示為訊息的第一筆記錄。ME%20(Message%20End)%20ME=1;%20表示為訊息的最後一筆記錄。%20所以，如果訊息僅含一筆記錄，則該筆紀錄的表頭的%20MB=1,%20ME=1；如果是圖中的多筆紀錄型態，第一筆的紀錄表頭的%20MB=1,%20ME=0，這樣我們知道這是開頭的第一筆，因為ME=0就表示後面還有紀錄；再來看第二筆紀錄的表頭的%20MB=ME=0，明顯地說明後面還有紀錄；最後，第三筆紀錄的表頭的%20MB=0,%20但ME=1，表示已經到了最後一筆紀錄。你有沒有發現，訊息本身並沒有什麼欄位明顯指名訊息裡有多少筆紀錄，所以當循序一筆一筆資料爬進來的同時，一邊解析的同時也要進行統計。再來，看看其他的功能位元：%20CF%20(Chunked%20Message)%20CF=1;%20表示為分段訊息，表示這個標籤內容，僅為一個超長訊息的其中一部分訊息；其他部分則存在其他的標籤中。SR%20(Short%20Record)%20SR=1;%20表示為短記錄型式，PAYLOAD_LENGTH僅以單一位元組來定義，表示其後資料內容長度將不超254個位元組。%20SR=0;%20表示資料內容的長度將以4個位元組來表示。IL%20(ID%20Length)%20IL=1;%20表示會有ID長度標示的位元組；反之，IL=0;%20表示ID%20LENGTH與ID均被省略。%20而最後的3個位元組合成所謂的TNF：%20TNF%20(Type%20Name%20Format)%20在NDEF訊息裡的每筆記錄，都先必須在記錄的表頭宣告其形態的名稱，而這些名稱又分成幾類的名稱格式%20(Type%20Name%20Format)：%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x00%20Empty%20Record;%20僅有此狀態位元組。%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x01%20Well_Known%20Record;%20%20(TEXT,%20URI(http,%20https,%20sms,%20mailto...),%20SmartPoster,%20Signature)%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x02%20MIME%20Media%20Record;%20MIME所定義的媒體記錄%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x03%20Absolute%20URI%20Record;%20絕對URI記錄%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x04%20External%20Record;%20Domain名稱＋“：”＋類形名稱%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x05%20Unknown%20Record;%20TYPE_LENGTH=0且TYPE被省略。%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x06%20Unchanged%20Record;%20TYPE_LENGTH=0且TYPE被省略。%20)[\[NDEF基本篇-1\] by Roger Luo

NFC的手機與NFC標籤之所以可以達到許多網際連接與互動訊息，就是依靠解析存放在TAG記憶體內NDEF訊息區塊的資料，所得到的指示與行動。

圖1. NDEF訊息的基本格式

NDEF的記錄格式

圖2. 只含單筆資源紀錄的NDEF訊息格式

在圖2 這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/

NDEF的靈魂：表頭

]([NDEF基本篇-1]%20by%20Roger%20Luo%20%20%20NFC的手機與NFC標籤之所以可以達到許多網際連接與互動訊息，就是依靠解析存放在TAG記憶體內NDEF訊息區塊的資料，所得到的指示與行動。%20%20%20你大概也知道，現在市面上的智慧型手機，有著不同的作業系統(OS)；就像APPLE的iPhone是%20iOS、Google的手機用Android。而不同廠牌的手機，就算是都以%20Android%20為主，也都還會有一些小小的差異。如果要讓不同廠牌、甚至不同作業系統的%20NFC手機之間，都可以讀取同一個%20NFC標籤，來共享信息的交換的話，就必須制定出一套標準，如同網頁的%20HTML語法。%20%20%20這就是%20NFC協會所制定%20NDEF%20規範的目的：即便是使用不同的NFC的手機，都可以用來讀取%20NFC標籤的資料。而之所以可以完成網際連接與互動訊息的傳遞，就是依靠解析存放在標籤記憶體內%20NDEF%20訊息區塊的資料，所得到的指示與行動。%20基本上，%20NDEF%20訊息的複雜程度和存放的記憶體的容量大小，有著一定的關係。%20這意味著只要有足夠的容量，可以設定不只是網際資源的連接，還可以包含自行定義特殊格式(Proprietary)的資料。當然，這些自行定義的資料，你必須開發特定的App來解讀。%20%20%20在標準的%20NDEF%20訊息區塊內所描述的資源記錄(Record)可以不只一筆(如下圖)，但均需符合%20NFC協會的記錄類別標準(RTD;%20Record%20Type%20Definition)文件裡所定義的規範。%20%20%20%20%20%20%20%20%20%20圖1.%20NDEF訊息的基本格式%20%20%20NDEF的記錄格式%20%20%20在%20NFC協會所定義簡單的資源記錄(Record)中，如：文字記錄%20(RTD_TEXT)、資源定址記錄%20(RTD_URI)或是%20MIME媒體位址記錄%20(Media%20Recoed)，大都只包含單獨的一筆記錄。%20而較複雜的%20智慧型海報記錄%20(RTD_SMART_POSTER)%20與%20數位簽章記錄%20(RTD_SIGNATURE)，則可以包含多筆的記錄來組成。%20%20%20%20這些所謂不同類別的記錄，均以同一種格式，但其內的資料長度可能不同的方式來描述；為了能達到完整描述一連串的資料，均採用表頭(Header)＋資料內容(Payload)的格式來進行；而這裡所謂的表頭，其實是指這筆記錄的類別與型式(Flags%20&%20TNF)；每一筆記錄資料內容的長度，就由表頭這個位元組來定義，並依此決定其後所存在的欄位組成。%20%20%20一筆正常的記錄其資料格式如(圖2)所示：大致包含有此記錄類別名稱的長度(TYPE_LENGTH)、最多有4個位元組的資料內容長度(PAYLOAD_LENGTH3~0)、資源標識碼的長度(ID_LENGTH)、類別名稱(TYPE_NAME)、資源標識碼(ID)與資料本身的內容(DATA%20PAYLOAD)。%20%20%20%20%20%20%20%20%20%20圖2.%20只含單筆資源紀錄的NDEF訊息格式%20%20%20在%20圖2%20這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/%20%20%20NDEF的靈魂：表頭%20%20%20現在回顧一下，在圖1所顯示是由3筆NDEF紀錄所組成的訊息，我們來看看怎麼由各紀錄的表頭裡的各個功能位元(Bit)來把每筆紀錄串起來。在表頭的前兩個功能位元(Bit7,%20Bit6)，分別為：%20MB%20(Message%20Begin)%20MB=1;%20表示為訊息的第一筆記錄。ME%20(Message%20End)%20ME=1;%20表示為訊息的最後一筆記錄。%20所以，如果訊息僅含一筆記錄，則該筆紀錄的表頭的%20MB=1,%20ME=1；如果是圖中的多筆紀錄型態，第一筆的紀錄表頭的%20MB=1,%20ME=0，這樣我們知道這是開頭的第一筆，因為ME=0就表示後面還有紀錄；再來看第二筆紀錄的表頭的%20MB=ME=0，明顯地說明後面還有紀錄；最後，第三筆紀錄的表頭的%20MB=0,%20但ME=1，表示已經到了最後一筆紀錄。你有沒有發現，訊息本身並沒有什麼欄位明顯指名訊息裡有多少筆紀錄，所以當循序一筆一筆資料爬進來的同時，一邊解析的同時也要進行統計。再來，看看其他的功能位元：%20CF%20(Chunked%20Message)%20CF=1;%20表示為分段訊息，表示這個標籤內容，僅為一個超長訊息的其中一部分訊息；其他部分則存在其他的標籤中。SR%20(Short%20Record)%20SR=1;%20表示為短記錄型式，PAYLOAD_LENGTH僅以單一位元組來定義，表示其後資料內容長度將不超254個位元組。%20SR=0;%20表示資料內容的長度將以4個位元組來表示。IL%20(ID%20Length)%20IL=1;%20表示會有ID長度標示的位元組；反之，IL=0;%20表示ID%20LENGTH與ID均被省略。%20而最後的3個位元組合成所謂的TNF：%20TNF%20(Type%20Name%20Format)%20在NDEF訊息裡的每筆記錄，都先必須在記錄的表頭宣告其形態的名稱，而這些名稱又分成幾類的名稱格式%20(Type%20Name%20Format)：%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x00%20Empty%20Record;%20僅有此狀態位元組。%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x01%20Well_Known%20Record;%20%20(TEXT,%20URI(http,%20https,%20sms,%20mailto...),%20SmartPoster,%20Signature)%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x02%20MIME%20Media%20Record;%20MIME所定義的媒體記錄%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x03%20Absolute%20URI%20Record;%20絕對URI記錄%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x04%20External%20Record;%20Domain名稱＋“：”＋類形名稱%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x05%20Unknown%20Record;%20TYPE_LENGTH=0且TYPE被省略。%20%20%20%20%20%20%20%20%20%20%20%20%20%20-%200x06%20Unchanged%20Record;%20TYPE_LENGTH=0且TYPE被省略。%20%20%20)

常見的NDEF紀錄，可以不用APP就可以感應讀取

NDEF紀錄的格式

[在 圖2 這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/

[在圖2 這筆紀錄內，標示前往某特定網站的網址連結：https://reactnative.dev/