2012/03/07

NDEFの資料を読もう (2)

NDEFのやりたいことは、前回でなんとなくわかったと思う。
XMLのようなツリー構造になっているわけではなく、シーケンシャルにNDEFレコードが複数集まったもの、それがNDEFメッセージのようだ。

 

NDEFレコードのことを細かく見ていっても面白くないので、気になるところだけ見る。


2.4.2 Payload Type

 

1番目のレコードが持つPayload Typeは、そのレコードのPayload Typeというだけでなく、NDEFメッセージ全体のPayload Typeでもある(SHOULD)。

この節は、説明が長い・・・。
まあ、必要になったら読めばよかろう。
とにかく、well-knownなもの以外も設定できるのだよ、と。


ここまでの知識で、手元にあるNDEFのデータを読んでみた。
touchanoteのタグ(Mifare UltralightC)と、SonyのNDEF writerで作った人からもらったタグ(FeliCa Lite)。

どっちも、URLを含んでいるのだが、表現方法が異なる。

 

touchanoteの場合、Type2の定義に従ったカードのヘッダ部分に続いてNDEFメッセージが始まっている。
いきなり、well-knownの「U」、すなわちURIになっている。

 

NDEF writerもらったタグの場合、Type3の定義に従ったカードのヘッダ部分に続いてNDEFメッセージが始まっている。
これは、well-knownの「Sp」、すなわちスマートポスターになっている。
SpのレコードにはMBとMEのビットが立っていて、このレコード1つしかないことになっている。
しかし、そのペイロード部分に複数のレコードを含むというメタ構造というのかしら、そういう構造になっている。

スマートポスターはNFC Forumのドキュメントとして別途存在するように、けっこう重要なwell-known typeらしい。


とまあ、こんな感じであった。

実物が得やすいし、NFC Forumのドキュメントにはサンプルもあるので、実装はそこまで難しくないように思う。

 

気をつけるのは、NDEFメッセージが始まるまでは各Tagによって異なるということかな。
Type2とType3では、それぞれ定義が別だった。
「NFC Forum Device Requirements」によると、NDEFメッセージのパーサは積まないといかんようなので、早めに簡単なものを実装したいものである。

0 件のコメント:

コメントを投稿

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。