android NFC学习笔记(二)

一:解析NDEF
据文档说这是google参考nfc论坛而提出和支持的格式。也就是说nfc的格式和标准肯定有很多,google只不过比较支持其中的这一种NDEF。

ndef格式,就是数据被包裹在一个NdefMessage里,而同时一个NdefMessage里面又可以包含多个NdefRecord.当然你也应该还记得,nfc的tag里面是可以不包含Ndef数据的,他也可以包含android.nfc.tech所定义的多种标签。Google推荐开发人员使用ndef格式的数据来处理android相关的nfc格式数据。

当一个android设备检测到nfc标签包含ndef格式的数据的时候,他就会尝试的去解析数据中的MIME type或者是URI。为了做这个事情,他需要解析NdefMessage中的第一个NdefRecord。第一个NdefRecord中的结构一般如下:

3-bit TNF (Type Name Format)

如何解释variable length type的数据。并依据不同的解析,来确定发送什么样的intent。如果这里定义的是TNF_WELL_KNOWN则还要参考variable length type来进一步确定。如果是网络地址URL则直接去调用浏览器程序了。

Variable length type

进一步定义record的类型。具体的请参看android文档。不过话在这里多说一句,TNF和TYPE这两个参数非常的重要,直接决定了你NDEF格式的命中程度。定义的越规范,越清楚,同时在androidmanifest文件中写的越正确,就越好,否则系统就会被你发TECH_ACTION

比如:构造的时候写

new NdefRecord(
NdefRecord.TNF_WELL_KNOWN ,
NdefRecord.RTD_TEXT,
new byte[0],
data.getBytes(Charset.forName("UTF-8")));

androidmanifest文件中写
<intent-filter>
<action android:name="android.nfc.action.NDEF_DISCOVERED"/>
<category android:name="android.intent.category.DEFAULT"/>
<data android:mimeType="text/plain"/>
</intent-filter>

这一对就可以正确的过滤一个text/plain格式的ndef

Variable length ID
不经常使用.....是用来唯一标示一个record的。

Variable length payload
actual这个才是真正的数据区域。读写操作一般应该主要是对这个区域的操作。一个NdefMessage可以有多个NdefRecord所以不要假设所有的数据都仅仅存储在第一个NdefRecord中。

已经知道了Ndef的格式了,那么解析带有Ndef数据的Intent也就简单很多了。底下这个解析的方法,通常放在onResume或者onNewIntent中。

private boolean readFromTag(Intent in){
    Parcelable[] rawArray = in.getParcelableArrayExtra(NfcAdapter.EXTRA_NDEF_MESSAGES);
    //如果你不止一个的话,那么你要遍历了。
    NdefMessage mNdefMsg = (NdefMessage)rawArray[0];
    //如果你不止一个record,那么你也要遍历出来所有的record
    NdefRecord mNdefRecord = mNdefMsg.getRecords()[0];
    try {
        if(mNdefRecord != null){
            readResult = new String(mNdefRecord.getPayload(),"UTF-8");
            readJson = new JSONObject(readResult);
            return true;
        }
    } catch (JSONException e) {
        e.printStackTrace();
    } catch (UnsupportedEncodingException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    };
    return false;
}

二:解析其他tech标签

现在你已经会解析ndef标签了,但是你也应该知道,大多数nfc标签其实并不是ndef格式的。比如你的公交卡,各个城市的公交卡会支持什么格式,并不一定。所以你还要会解析各种tech格式的nfc数据。
如果你还记得我们再tech-list中定义了多少种格式,你就应该知道我们如果要全部解析的话,应该要解析多少种不同的nfc格式了。底下这段代码可以显示出你所扫描的nfc卡到底支持哪几种格式。

    Tag tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
    String[] temp = tag.getTechList();
    for(String s :temp){
      Log.i("xxx","s = "+s);
    }

这是一段最常用的(我个人理解啊)的nfc解析代码,主要是解析MifareClassic格式。貌似大多数nfc标签都会支持这种格式。先普及下关于他的简单常识:不知道各个格式的数据是怎么构成的,你压根就没法解析。

一般来说,给予MifareClassic的射频卡,一般内存大小有3种:
1K: 16个分区(sector),每个分区4个块(block),每个块(block) 16个byte数据
2K: 32个分区,每个分区4个块(block),每个块(block) 16个byte数据
4K:64个分区,每个分区4个块(block),每个块(block) 16个byte数据

对于所有基于MifareClassic的卡来说,每个区最后一个块(block)叫Trailer,16个byte,主要来存放读写该区的key,可以有A,B两个KEY,每个key长6byte,默认的key一般是FF 或 0,最后一个块的内存结构如下:
Block 0 Data 16bytes
Block 1 Data 16 bytes
Block 2 Data 16 bytes
Block 3 Trailer 16 bytes

Trailer:
Key A: 6 bytes
Access Conditions: 4 bytes
Key B: 6 bytes

所以在写卡的内存的时候,一般不能写每个sector的最后一个block,除非你有要修改KEY和访问权限的需求。如果KEY A 被你不小心修改掉了,而你不知道修改成什么,那与之对应的那个sector你就没有办法访问了。因为在MifareClassic中,如果你要读取数据,那么必须要有这个数据地址所在的sector的权限,这个权限就是这个sector的trailer的KEY A或KEY B。

这就是解析MifareClassic的代码了

private void readTechPayloadMC(Tag tag){
    MifareClassic mc = MifareClassic.get(tag);//通过intent拿到EXTRA_TAG并转化成MirareClassic格式。
    int bCount = 0 ;
    int bIndex = 0 ;
    try {
        mc.connect();
        int sectorCount = mc.getSectorCount();//获得sector总数
        Log.i("liyufei3","sectorCount = "+sectorCount);
        for(int i =0;i<sectorCount;i++){
            //尝试去获得每个sector的认证,只有认证通过才能访问
            auth = mc.authenticateSectorWithKeyA(i, MifareClassic.KEY_DEFAULT);
            if(auth){
                //这句其实不是必须的,因为每个sector中本来就只有4个block
                bCount = mc.getBlockCountInSector(i);
               
                //我们可以得到每一个sector中的第一个block的编号
                bIndex = mc.sectorToBlock(i);
                for(int j =0;j<bCount;j++){
                    //循环四次拿出一个sector中所有的block
                    //每次循环bIndex会去++,然后可以得出每一个block的数据。
                    //这些数据是字节码,所以你还有一个翻译的工作要做。
                    byte[] data = mc.readBlock(bIndex);           
                    String s = readByteArray(data);
                    bIndex++;
                }
            }else{
                Log.i("xxx","   auth = false !!!  in sectorCount = "+i);
            }
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
}
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 160,108评论 4 364
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,699评论 1 296
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 109,812评论 0 244
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,236评论 0 213
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,583评论 3 288
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,739评论 1 222
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,957评论 2 315
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,704评论 0 204
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,447评论 1 246
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,643评论 2 249
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,133评论 1 261
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,486评论 3 256
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,151评论 3 238
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,108评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,889评论 0 197
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,782评论 2 277
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,681评论 2 272

推荐阅读更多精彩内容