NDEFのやりたいことは、前回でなんとなくわかったと思う。
XMLのようなツリー構造になっているわけではなく、シーケンシャルにNDEFレコードが複数集まったもの、それがNDEFメッセージのようだ。
NDEFレコードのことを細かく見ていっても面白くないので、気になるところだけ見る。
2.4.2 Payload Type
１番目のレコードが持つ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のビットが立っていて、このレコード１つしかないことになっている。
しかし、そのペイロード部分に複数のレコードを含むというメタ構造というのかしら、そういう構造になっている。
スマートポスターはNFC Forumのドキュメントとして別途存在するように、けっこう重要なwell-known typeらしい。
とまあ、こんな感じであった。
実物が得やすいし、NFC Forumのドキュメントにはサンプルもあるので、実装はそこまで難しくないように思う。
気をつけるのは、NDEFメッセージが始まるまでは各Tagによって異なるということかな。
Type2とType3では、それぞれ定義が別だった。
「NFC Forum Device Requirements」によると、NDEFメッセージのパーサは積まないといかんようなので、早めに簡単なものを実装したいものである。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。