なんとなく作りましたが、最終号です。

2. おじいちゃんは
どんなNDEFが好き？
やっぱり
Short Record
かな
FeliCa Lite Short Recordなら
メモリの少ないNFCタグでも
MIFARE UL
十分対応できます！
第１章 Short Recordって？
そもそも、Short Record ってなんなの？
第２章 絵でわかる！ Short Recordの読み方
実際に Short Record NDEF を読んでみよう
Appendix Shortじゃない方は、いるの？

3. 特集 Short Record の魅力に迫る
第１章 Short Recordって？
NDEF NDEF の 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
普通のNDEFと
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 となる。
PAYLOAD b7 b6 b5 b4 b3 b2 b1 b0
LENGTHが
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 レコードなのである。
-1-

4. 特集 Short Record の魅力に迫る
第２章 絵でわかる！
NDEF
Short Recordの読み方
最初の 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 となっている。
-2-

5. 特集 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 も
使用されるようである。
ここまで解析できると、それ以降のデータが解析できるようになる。
もう少しだよ
-3-

6. 特集 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が0だと
フィールドが隠れるぞ
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 によってペイロードを解析することになる。
読めなかった子は
いねぇがぁぁ！
-4-

7. 特集 Short Record の魅力に迫る
Appendix Shortじゃない方は、いるの？
今回の特集では、 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 を愛する我々としては、どのような進化になったとしても見守っていきたいところである。
-5-

8. 特集 Short Record の魅力に迫る
編集後記
風邪を引いています・・・。
そのせいかわかりませんが、勢いで作ってしまいました。
「１月号」って書いたけど、２月はありません。
普段、絵を探すのが面倒なので自分で描いていたのですが、今回は
「一太郎」というソフトを使って書いていて、そこにイラストがあったの
で使いました。
学校でよく使われるためか、子供の絵が多かったです。
まあ、殺伐とした内容が薄められれば幸いです。
あと、似ても似つかないのですが、目次の部分は CQ 出版の Interface 誌(2013 年 3 月号)を参考に
しながら作っています。何気なく見ているページだったのですが、いざ作ろうとするとどうしていいかわ
からなかったのでした。配置、フォント、色・・・、見やすくするというのは難しいと思いました。
2013/01/27 1:27
-6-