おじいちゃんは

どんなNDEFが好き？

やっぱり

Short Record

かな

Short Recordなら

メモリの少ないNFCタグでも

十分対応できます！

FeliCa Lite

MIFARE UL

第１章 Short Recordって？

そもそも、Short Recordってなんなの？

Appendix Shortじゃない方は、いるの？

第２章 絵でわかる！ Short Recordの読み方

実際に Short Record NDEFを読んでみよう

- 1 -

特集 Short Recordの魅力に迫る

Short Recordの NDEFを見る

今回の特集で見ていく、 Short Recordの NDEFレコード構成を Fig.1-1に示す。

この場合、 SRは=1 となる。

b7 b6 b5 b4 b3 b2 b1 b0

MB ME CF SR IL TNF

TYPE LENGTH

PAYLOAD LENGTH

ID LENGTH

TYPE

ID

PAYLOAD

Fig. 1-1 Short Recordの NDEFレコード(SR=1)

これに対して、 Short Recordではない NDEFレコード構成を Fig.1-2に示す。

この場合、 SRは 0 となる。

b7 b6 b5 b4 b3 b2 b1 b0

MB ME CF SR IL TNF

TYPE LENGTH

PAYLOAD LENGTH 3

PAYLOAD LENGTH 2

PAYLOAD LENGTH 1

PAYLOAD LENGTH 0

ID LENGTH

TYPE

ID

PAYLOAD

Fig. 1-2 Short Recordではない NDEFレコード(SR=0)

大きな違いは PAYLOAD LENGTHで、 Short Recordでは 1byte分なのに対し、そうではない場合

は 4byte分確保されている。

すなわち Short Record とは、ペイロード長が 255byteまでの NDEFレコードなのである。

第１章 Short Recordって？

NDEFの Short Recordとはどういったものであろうか。基本を振り返ろう。

NDEF

PAYLOADLENGTHが多いんだね！

普通のNDEFと何が違うのかしら？

- 2 -

最初の 1byteですべてがわかる

NDEFレコードの 1行目には、そのレコードを読むための情報がすべて書かれている。

MB ME CF SR IL TNF

Fig. 2-1 まず 1行目を読み取れ

MB (Message Begin)

この NDEFレコードが、一連の NDEF メッセージの先頭かどうかを示すビット。

先頭であれば 1 、そうでなければ 0 となっている。

「一連の NDEF メッセージ」としたのは、 NDEF レコードのペイロードとして入れ子となった

NDEF メッセージを含む場合があるからである。例えば SmartPoster の場合、全体としては

「 SmartPoster 」の NDEFレコード 1つを含んだ NDEF メッセージが 1つしかない(NDEF メッ

セージは 1 つしか含まない仕様)。しかし SmartPoster の NDEF レコードのペイロードには、

URIや TEXTなどの複数 NDEFレコードを含んだ NDEF メッセージを持つ。

NDEF メッセージ

NDEFレコード SmartPoster(MB=1, ME=1)

NDEF メッセージ

NDEFレコード URI (MB=1)

"http://～"

NDEFレコード TEXT (ME=1)

"○○ blog"

Fig. 2-2 入れ子となった NDEF メッセージ

ME (Message End)

MBの逆で、 NDEF メッセージの末尾であれば 1を、そうでなければ 0 となっている。

第２章 絵でわかる！Short Recordの読み方

NDEF

入れ子だニャ

特集 Short Recordの魅力に迫る

- 3 -

特集 Short Recordの魅力に迫る

CF (Chunk Flag)

chunk of a payloadで「ペイロードの塊」となるが、ここでは分割されたペイロード、という意味。大きな

ペイロードを持つ NDEF メッセージを複数に分割した場合に使う。

分割していないときは、 0 。

ストリーミングのような目的で分割しないこと(NFC タグではできないが、携帯電話同士が NDEF デー

タを交換する場合には、やろうと思えばやれるため)。 HTTP/1.1(RFC2616)のような意味で使うため

に設けているとのこと。

通常の使用であれば、 0 と考えていいだろう。

SR (Short Record)

ここが 1の場合、この NDEFレコードは Short Record ということになる。

NDEF として使えるメモリは、 FeliCa Liteで 208byte(14のユーザブロックのうち、先頭の 1ブロック

は Type 3 Tagの属性情報として使う)、MIFARE Ultralightで 48byte となっていて、 256byte以上

のユーザメモリを持たない NFC タグも多い。

IL (ID LENGTH有無)

ここが 1の場合、 ID LENGTH フィールドが存在する。 0の場合は存在しない。

よく使われる NDEF では、 ID を使わないことが多い。 IL=0 とすることで 1byteの ID LENGTH フィ

ールドを削除でき、 PAYLOAD として使うことができるようになる。

TNF (Type Name Format)

NDEFレコードのタイプが記載されている。

よく使われるのは、 well-known 、media-type 、 URIであろう。 Androidアプリでは external type も

使用されるようである。

ここまで解析できると、それ以降のデータが解析できるようになる。

もう少しだよ

- 4 -

特集 Short Recordの魅力に迫る

LENGTHを把握する

ここまでで、この NDEFレコードについて以下の情報がわかっている。

NDEF メッセージの先頭かどうか・

NDEF メッセージの末尾かどうか・

複数に分割されているかどうか(今回は分割無ししか考えない)・

Short Recordかどうか(今回は Short Recordの場合)・

ID LENGTHがあるかどうか・

NDEF レコードタイプは何か・

TYPE LENGTH

PAYLOAD LENGTH

ID LENGTH (IL=1 の場合)

Fig. 2-3 LENGTHが 3つ

LENGTH フィールドが続くが、注意するのは以下の２点である。

LENGTHは 0の場合もある・

ID LENGTHは IL=1の場合しか存在しない・

IL=0の場合は、 ID LENGTH フィールドも ID フィールドも存在しない。

それだけでなく、例えば TYPE LENGTHが 0の場合には、 TYPE フィールドも

存在しないようになる。

極端な場合、 TNF=Emptyでは、 TYPE LENGTH=0 、 PAYLOAD LENGTH=0 、 IL=0のため、全

部で 3byte しかないことになる。

各フィールドを読む

ここまでで、残りを読むための情報がわかっている。

TYPE LENGTHはいくつか(フィールドが存在するか)・

PAYLOAD LENGTHはいくつか(フィールドが存在するか)・

ID LENGTHはいくつか(フィールドが存在するか)・

TYPE, PAYLOAD, IDは、 LENGTHが 0かどうかで読むかどうかを決めるようにしておくとよいだろ

う(IL=1 としておきながら、 ID LENGTHが 0 という可能性もあるので)。

これで読み込み完了である。

あとは TNFや TYPEによってペイロードを解析することになる。

LENGTHが0だとフィールドが隠れるぞ

読めなかった子はいねぇがぁぁ！

- 5 -

今回の特集では、 NDEFの Short Recordについて見ていった。

実際に市販されている NFC カードを見た際、メモリ容量が 256byte以上あるものはほとんどない。少

なくともそれらのカードについては、 Short Recordではない NDEF メッセージというのはメモリの無駄

でしかない。少しでも多くの情報を載せたいのであれば、 SR=1 、 IL=0 としてペイロードの容量を稼ぐ

べきであろう。これだけで 4byte多くなるのだ。

では、 Short ではない NDEF レコードが必要となるのはどういう場合だろう

か？ もちろん 256byte 未満の NFC カードであっても Short ではない

NDEF レコードを使うことは可能であるが、ここでは必要性だけを考えること

にする。

まず、ペイロードが 256byte以上存在する、ということになる。

もちろんそれは、 NFC カードが 256byte以上の容量を持つということでもある。

よく使う NDEF のレコードタイプでは、それほど大きなデータを必要とすることが少ないのではないだ

ろうか。

URI は長くなりがちではあるが、そもそもそういう長い URI を NDEF にするような運用はそれほどな

いのではなかろうか。

私は、今のところ NFC カードは「高価な」扱いだと思っているので、ちょっと検索した URIを入れるより

も、「うちのブログです」のような URIを入れることの方が多いのではなかろうか。

市販で入手しやすい大きな容量の NFCカードが、 FeliCa Liteや MIFARE UltraLight C くらいで、そ

れらの容量が 256byteを超えていないことを考えると、今のところではあるが Short Record よりも大

きなデータがまだ必要になっていない、ということではないかと考えている。

とはいえ、フロッピーディスクだってハードディスクだって、小さな容量からどん

どんと大容量化が進んでいった。 NFC もその道をたどらないとは限らない。

まだ NFC も一般用途として広まりだしてから歴史が浅いので、どういう方向に

進んでいくかわからない。

現在の状況だけですべてを判断するのは危険だ。

NFCを愛する我々としては、どのような進化になったとしても見守っていきたいところである。

Appendix Shortじゃない方は、いるの？

少しでも稼ごう

特集 Short Recordの魅力に迫る

- 6 -

風邪を引いています・・・。

そのせいかわかりませんが、勢いで作ってしまいました。

「１月号」って書いたけど、２月はありません。

普段、絵を探すのが面倒なので自分で描いていたのですが、今回は

「一太郎」というソフトを使って書いていて、そこにイラストがあったの

で使いました。

学校でよく使われるためか、子供の絵が多かったです。

まあ、殺伐とした内容が薄められれば幸いです。

あと、似ても似つかないのですが、目次の部分は CQ 出版の Interface 誌(2013 年 3 月号)を参考に

しながら作っています。何気なく見ているページだったのですが、いざ作ろうとするとどうしていいかわ

からなかったのでした。配置、フォント、色・・・、見やすくするというのは難しいと思いました。

2013/01/27 1:27

編集後記

特集 Short Recordの魅力に迫る