カテゴリー: 未分類

uriレコードの利用

URI Recordは
URLとURNの総称で
場所であるURL
名前であるURNを一意に識別するためのルールのこと

NFCでやりとりするために
通常のuriより軽量に作られている

また、URI RTDは
NDEF headerへ以下の情報がセットされる必要がある

TNF:0x01(NFC forum well known type)
タイプ:RTD URI Type(“U”[0x55])

payloadについては以下の要素で構成される

識別子コード(identifier code)

1byteで表すURI識別子コード

URIを短くするために、最初のバイトは
URIのプロトコルを表現するために使う

URIをエンコード、またはデコードする場合
以下の識別子コードを使う

0(0x00)
前置きは使わない
完全なURIを指定するときに使う

1(0x01)
http://www.

2(0x02)
https://www.

3(0x03)
http://

4(0x04)
https://

5(0x05)
tel:

6(0x06)
mailto:

7(0x07)
ftp://anonymous:anonymous@

8(0x08)
ftp://ftp.

9(0x09)
ftps://

10(0x0A)
sftp://

11(0x0B)
smb://

12(0x0C)
nfs://

13(0x0D)
ftp://

14(0x0E)
dav://

15(0x0F)
news:

16(0x10)
telnet://

17(0x11)
imap:

18(0x12)
risp://

19(0x13)
urn:

20(0x14)
pop:

21(0x15)
sip:

22(0x16)
sips:

23(0x17)
tftp:

24(0x18)
btspp:

25(0x19)
btl2cap:

26(0x1A)
blgoep://

27(0x1B)
tcpobex://

28(0x1C)
irdaobex://

29(0x1D)
file://

30(0x1E)
urn:epc:id:

31(0x1F)
urn:epc:tag:

32(0x20)
urn:epc:pat:

33(0x21)
urn:epc:raw:

34(0x22)
urn:epc:

35(0x23)
urn:nfc:

36(0x24…0xFF)
RFUこれは将来のための予約
このプロトコルを含むコードは生成してはいけない

Eclipse プロジェクトコピー

Android Projectをeclipse上でコピーして別Projectとして開発する
http://kyokomi-android.doorblog.jp/archives/6835616.html
を参考に
既存のプロジェクトである
SQLDBを
コピーして新しく作る

まずはプロジェクト右クリックでコピー
そして貼り付け
名前は
AutoSQLDB
へ変更

次にプロジェクトを右クリック
Android Tools >
Rename Application Package
でパッケージ名を変更

あとはアプリの名前が同じだとわかりにくいので
res/strings.xml で

<string name="app_name">SQLDB</string>

となっているのを

<string name="app_name">AutoSQLDB</string>

というようにアプリ名を変更すればOK

あとは実機で実行すれば無事に起動しました

TextRTDについて

Text Recordは、自由な構文のテキストを含むことごできるレコード

言語コードを含むことができるため
軽量な多言語対応テキストが作成可能

テキストレコードは
NDEF Message の中に複数含めることができるがこれは、多言語対応のため

このため、複数のテキストレコードがふくまれる場合、
複数表示ではなく
ユーザーが求める言語のいずれかのみ表示する

テキストレコードは
NDEF headerに以下の情報がセットする必要がある

TNF
0x01(NFC forum well known type)

そして、タイプ
RTD Text Type(“T” [0x54])

次に、payloadについて
以下の3つのフィールドで構成される

ステータスバイト
ISO/IANA言語コード
実テキスト

まず、ステータスバイトについて
ステータスバイトは
Text RTD のheaderのような役割をするバイト
このバイトは、以下のように定義されている

ビット数
7
0の場合、このテキストのエンコードがUTF-8であることを示す
1なら、UTF-16になる

6
必ず0をセットする
将来のために予約されているビット

5-0
ISO/IANA言語コードの長さを示す
単位はバイト

次に、ISO/IANA言語コードについて
jpやen-USなど
RFC3066
に則った言語コードが入る

また、ステータスバイトには
この言語コードの長さを
ステータスバイトの下位5ビットに含める必要がある
例えば、
jp なら 0x02
en-USなら 0x05
となる
この言語コードは、RFC3066に従わなくてはならない

次に、実テキストについて
これは、UTF-8、または、UTF-16でエンコーディングされた文字列のこと
このエンコーディングは
ステータスバイトで指定したエンコーディングと同じであること

他にもいくつか仕様で決まっていることがあり

テキストの改行コードはCRLFでなければならない

BOM(Byte Order Mark)は許容すること
BOMによりエラーになってはいけない
BOMが省略された場合、
UTF-16 BE(Big Endian)とする

改行(0x0D,0x0A)と,タブ文字(0x08)
を除いて制御文字(UTF-8でいう0x00-0x1F)は
表示する前に削除するべき

マークアップは埋め込まれてはいけない
マークアップはHTMLのようなコードのこと
この場合、text/xhtmlなどのMIMEタイプレコードを利用する

テキストレコードは
MIME-Typeで表すところの
text/plain
format-fixed
と等しくなるよう配慮することが必要

RFC2119キーワードについて

MUST
しなければならない

SHALL
する事になる

SHOULD
する必要がある

MAY
してもよい
これらは、仕様で記述されている事柄に対するキーワード

実装しなくてよい
実装しないとだめ
の解釈を少なくするためキーワード化し
要請の程度を定義したのが
RFC2119になる

NFC forum仕様のように
様々な技術仕様は、このRFC2119で定義された語句を多く利用している

わかりにくいなら検索エンジンで探すと
日本語訳もでてくる

NFC Forumの仕様

NFC Forumの仕様は
http://www.nfc-forum.org/specs/spec_list
からダウンロード可能

NDEF関連ドキュメントは5つ

NFC data exchanged format (NDEF) technical specification
NFC forum準拠のデバイスやタグのための一般的なデータフォーマットであるNDEFの仕様
これが公式な仕様になる

NFC Record type Definition(RTD) Technical Specification
レコード定義(RTD)の技術仕様
NDEFに基づいた標準的なレコード定義を組み立てるときのルールが書かれている

NFC Text Record Type Definition Technical Specification
複数言語に対応したテキストを作成するためのRTD技術仕様

NFC URI Record Type Definition Technical Specification
URI作成のためのRTD技術仕様

NFC Smart Poster RTD Technical Specification
スマートポスター作成のためのRTD技術仕様
スマートポスターは、payloadへ
NDEF Messageが入るようになっているため
複数のRTD技術仕様の例が含まれている

内容は英語で
バイナリーのレイアウトとして図が書かれていたり
例が書かれている

NDEF Recordのバイト列構成

MB
Message Begin(1 bit)
現在のレコードが、NDEF Messageの始まりであることを示す
NDEF messageの最初になるNDEF recordには
必ずこのbit に 1 をセットする

ME
Message End(1 bit)
現在のレコードが、NDEF Messageの終わりであることを示す
NDEF Messageの最後になる NDEF recordには必ずこのbitへ1をセットする

CF
Chuck Flag(1 bit)
このフラグが立っているレコードは
分割されたレコードの最初か、中間であることを示す

SR
Short Record(1 bit)
容量を節約するためのフラグ
これに1をセットすると
PAYLOAD_LENGTHが通常は4byte必要なところを
1byteにすることができる
ただし、PAYLOADが255byte以下であること

IL
ID_LENGTH field is present(1 bit)
ID_LENGTHレコードがあるかどうかを表す
IDが必要ないなら、このレコードへ0をセットする
と、
NDEFの容量が節約できる
IDを指定した場合、
ID_LENGTHとIDは省略すること

TNF
Type Name Format(3 bit)
このレコードが持つTYPE ID PAYLOADに
どのような種類のデータが入っているか決定する

TYPE_LENGTH
タイプの長さをバイト単位で表す

PAYLOAD_LENGTH
payloadの長さをバイト単位で表す

ID_LENGTH
IDの長さをバイト単位で表す

TYPE
タイプを表す

ID
IDを表す

PAYLOAD
payloadを表す

このように、詳細なNDEF recordの構成を見ると
TNF
タイプ
ID
payload
以外のほとんどのフィールドは、
レコードの長さに関するもの

Androidは、この部分を自動的に計算してくれるため
バイト列から自分でNDEF recordを作ることなく扱うことができる

自分でNDEF recordをバイト列から作成することも可能だけど面倒

NDEFは、通信フォーマットとして定義されているので
原理的にデータをバイト列にしたり
それを元に戻したりできる

Androidでは、NdefMessageクラスは
コンストラクタにバイト列 byte[] を指定することができるので
これを使って自分で複数のNDEF recordを作成できる

NDEF Recordでクラスはなく
NdefMessageクラスを使うのは

NdefRecordクラス単位だと

headerにある
MB
ME
の扱いができないので、この部分の情報を失うから

Androidでは、NdefMessageのコンストラクタを利用して
1つまたは、複数のNdefRecordインスタンスを格納したときに
初めてNdefRecordの順序が決定し
各NdefRecordのMB ME のビットが決まる

そのため、NdefRecord単体のインスタンスをバイト列から生成する場合も
NdefMessageのコンストラクタを利用する

NDEF構成データメモ

ID(payload ID)について

このフィールドは
アプリがpayloadを識別するときに使う
あまり利用することはない

また、このフィールドは任意のoption扱いになる
これも可変長なので
レコード内には長さを示す
ID_LENGTHを含める必要がある

payloadについて

データ本体になる
TNFやpayload typeにより
どのような内容が入っているかが定義される

このフィールドも可変長なので
レコード内には長さを示す
PAYLOAD_LENGTH
を含める必要がある

AndroidのNDEFレコードクラスは
TNF
type
ID
payload
の4つを指定すると
残りのフィールドは自動的に補ってくれる

payload type メモ

このフィールドは、recordのpayloadがどのような情報か示す

recordを処理するアプリは
この値をチェックして
どのようにデータ処理すればよいか知ることができる

この値は、TNFによりどのような値が入るかが変わる

代表的なのは
0x01(NFC forum well known type)
と
0x02(media type)

まず、TNFが
0x01(NFC forum well known type)の場合

この場合、payloadは NFC forum RTDで定義されている値を入れる

値は以下のようになる

0x61,0x63(“ac”)
RTD Alternative Carrie type
NdefRecordクラスの定数は
RTD_ALTERNATIVE_CARRIER

0x48,0x63(“Hc”)
RTD Handover Carrier type
NdefRecordの定数は
RTD_HANDOVER_CARRIER

0x48,0x72(“Hr”)
RTD Handover Request type
NdefRecordの定数は
RTD_HANDOVER_RECORD

0x48,0x73(“Hs”)
RTD Handover Select type
NdefRecordの定数は
RTD_HANDOVER_SELECT

0x53,0x70(“Sp”)
RTD Smart Poster type
NdefRecordの定数は
RTD_SMART_POSTER

0x54(“T”)
RTD Text type
NdefRecordの定数は
RTD_TEXT

0x55(“U”)
RTD URI type
NdefRecordの定数は
RTD_URI

次に、TNFが0x02(media-type)を示す場合
ここには、MIME-type(RFC2046)を指定する
たとえば、PNG形式のアイコンの場合
image/png
となる
JSONデータの場合なら
application/json
となる

この形式に対応するデータは
payloadへ入れる

また、このフィールドは可変長なので
レコード内には長さを示す
TYPE_LENGTH
を含める必要がある

TNF メモ

0x00(Empty)
recordに対応したtype payloadがない
これを使った場合、record内のTYPE_LENGTH
つまりタイプの長さ

そして
PAYLOAD_LENGTH これは、payloadの長さ
これらはゼロで
それに対応する値の　
type
id
payload
は省略する

このTNFは、アプリでpayloadがなくなったときや
NDEF messageの終わりであると判断されたときに使う

0x03(absolute-URI)
RFC3986で定義されている絶対URIに沿う値がtypeにふくまれること表す

URIは、0x01(NFC forum well known type)
にも定義されているため
これはあまり使わない

0x04(NFC forum external type)
NFC forum RTD仕様に定義されている外部タイプ名に沿う値がtypeに含まれることを表す
こちらは、RFC2141で定義されているURNへ準拠したもので
名前を一意に識別するときに使う

0x05(unknown)
payloadが不明であることを表すときに使うTNF
これは、MIMEとして定義されている
application/octet-stream
と類似している
これを使うときには
record内のTYPE_LENGTHは0
typeは省略すること

0x06(UnChanged)
NDEF messageを複数に分割するときに使うTNF
これが指定されたrecordは
分割されたpayloadの中間で利用しないといけない

また、これは、いくつかの他のrecordのなかでも使えない
これを使うときには
record内のTYPE_LENGTHは0
typeは省略すること

0x07(Reserved)
今後のために予約されているTNF
まだ使われていない

TNF(Type Name Format)について

TNFは、NDEFがどのような種類かを表す値で、3 bit で表す
このTNFは、以下のように定義されている

0x00
空
定数はTNF_EMPTY

0x01
NFC forumで定められている既知のタイプ
定数はTNF_WELL_KNOWN

0x02
RFC2046で定義されたメディアタイプ
定数はTNF_MIME_MEDIA

0x03
RFC3986で定義された絶対URI
定数は、TNF_ABSOLUTE_URI

0x04
NFC forum外部タイプ
定数は、TNF_EXTERNAL_TYPE

0x05
不明
定数は、TNF_UNKNOWN

0x06
変更なし
定数は、TNF_UNCHANGED

0x07
予約済み
定数はない

NFC Recordの定数は
AndroidのNfcRecordクラスであらかじめ定義されている定数

TNFを使うときには、この定数を利用する

例えば、TNF_WELL_KNOWNなら
NdefRecord.TNF_WELL_KNOWN
とすることで、この値へアクセスできる

特に重要なのは、0x01 0x02の値

まず、0x01
NFC forum well known type
について
これは、NFC Forum RTD仕様に定義されているRTD type name formatに沿う値がtypeに含まれることを表す

次に、0x02
media type について
これは、RFC2046により定義されているmedia typeに沿う値がtypeに含まれることを表す

RFC、つまり
Request For Comments
これは、さまざまな技術仕様が定められている仕様書のこと

これらの中に media typeの定義がされていて
media typeのTNFを使うには
これらの仕様に則ったPayloadでないとだめ

media typeは、例えば
PNG画像ならimage/png

連絡先データなら
text/x-vcard

また、NFC Forum RTD(Record Type Definition)は
NFC Forumが定義した仕様で
TNFが 0x01 もしくは 0x04 のときには
この仕様に沿った NDEF recordにする必要がある

NDEF recordを作る場合、多くの場合は
0x01 0x02のいずれかを使うことになる