尧图建网站 尧图建网站 YAOTU WEB BUILD 免费咨询
ARTICLE DETAIL

资讯详情

深耕网站建设与建站编程的一线实战洞察。

NFC技术实战指南:从协议原理到开发应用全解析

NFC技术实战指南:从协议原理到开发应用全解析 1. 2022 NFC上海研讨会这份资料到底讲了什么上个月整理资料柜的时候我翻出了2022年NFC上海研讨会的全套笔记和现场录屏顺手把里面的技术要点、Demo演示和答疑环节重新过了一遍。说实话这套资料放在今天依然不过时——NFC这个技术方向这几年没有翻天覆地的变化反而因为物联网设备爆发、车联网和数字车钥匙落地当年研讨会上埋下的很多伏笔现在才真正兑现。这份资料最值钱的地方是它不只有PPT还有现场演示的完整代码片段、天线调试的实测数据、标签读写异常时的处理方案以及会后答疑环节里厂商工程师亲口说的那些“文档里不会写”的细节。我身边做嵌入式、做App开发、做硬件产品的朋友几乎都从我这里拷过这份资料的某一章节。所以才想着干脆整理成一篇文章把资料里我认为最有价值的几个方向拎出来结合我自己做过的项目实践重新讲一遍。这篇文章适合这几种人看正准备用NFC做产品原型但不知道从哪下手的硬件工程师想在App里集成NFC读写能力但搞不清协议差异的移动端开发想做NFC创意项目比如标签音乐墙、智能名片的DIY玩家以及纯粹想搞懂“手机碰一碰”背后原理的好奇派。我会把协议、标签、开发、天线、安全、创意玩法逐个拆开尽量用实操经验和踩坑记录来讲而不是念协议文档。2. NFC协议族14443A与15693的区别一次说清2.1 两个高频协议到底差在哪研讨会上被问得最多的一个技术问题就是ISO 14443A和ISO 15693这两套协议到底有什么区别、什么时候该用哪一套。这俩都属于13.56MHz频段的RFID协议但设计目标完全不同经常有人混着用然后踩坑。ISO 14443A是近距耦合协议通信距离通常在10厘米以内典型场景就是手机支付、公交卡、门禁卡。它的工作方式是主动式或被动式卡片靠近读头后通过负载调制进行高速通信最高速率可以达到848kbps甚至更高。因为距离近、耦合紧14443A的抗干扰能力和安全性都更有保障所以金融级别的应用基本只看14443A。ISO 15693则是远距耦合协议通信距离能做到1米左右典型场景是图书馆盘点、资产追踪、药品追溯这类“需要在较大范围内批量读卡”的场合。它的通信速率比14443A低但优势在于读取距离远、标签天线尺寸可以做得更大、抗遮挡能力更强。如果你要做仓库货架上的批量盘点拿14443A的标签一张张去贴近读效率会非常低15693才是对口方案。2.2 使用场景下的协议选型逻辑研讨会现场有人问了一个很实际的问题如果我做一个消费级的智能产品标签应该选哪个协议这要分开看。如果你做的是手机交互类产品比如NFC音乐墙、智能名片、碰一碰配置Wi-Fi那必须用14443A因为手机的NFC读卡器几乎只支持14443A有些手机也兼容15693但在Android上支持并不统一你没法指望用户手里的手机都能读15693标签。我自己的经验是凡是跟手机碰一碰相关的直接锁死14443A别给自己找麻烦。反过来如果你做的是资产盘点、仓库管理、图书借阅这类B端场景读头是专用设备那15693就是更优解。一台手持读卡器隔着四五十厘米就能刷一堆标签盘点速度提升非常明显。市场上NXP的I.CODE SLIX就是15693的典型标签芯片我做过一个工具库盘点项目用的就是这套方案效果确实比14443A贴脸读卡舒服太多。我还专门整理了一张对比表方便大家做选型时直接参考对比维度ISO 14443AISO 15693典型通信距离0~10cm0~100cm通信速率最高848kbps约26kbps典型应用手机支付、门禁、交通卡图书馆、资产盘点、仓储手机兼容性兼容性好仅有部分手机支持标签成本相对较低相对略高批量读取能力弱需逐个贴近强可批量快速盘点典型芯片NXP NTAG21x系列NXP I.CODE系列注意这里说的“距离”是理论空场距离。实际产品里天线尺寸、外壳材质、金属环境都会大幅影响读卡距离后面讲天线设计的时候我会详细展开。2.3 资料里提到的类型标签需要补一个Type概念研讨会资料里反复出现了“NTAG215”“NTAG213”“Type 2”这些词很多新人会被绕晕。我简单梳理一下NFC Forum把NFC标签分成了Type 1到Type 5五类手机NFC功能主要兼容Type 1、2、3、4其中Type 2标签就是基于ISO 14443A的NTAG系列这也是消费级项目里用得最多的标签类型。Type 2标签的特点是存储容量小通常几十字节到几百字节、成本低、读写速度快足够存放URL、文本、Wi-Fi配置信息、名片VCard等数据。NTAG213容量是144字节NTAG215容量是504字节NTAG216容量是888字节。如果你只是放一个音乐链接或者一段文本NTAG213就够用如果你想存更多结构化数据或者做一个包含多张图片的小型交互卡片建议上NTAG215甚至NTAG216。研讨会资料里那张标签类型总表非常实用我在这里直接复述一个简化版标签类型协议基础典型容量常见芯片常用场景Type 114443A96字节Topaz简单URLType 214443A144~888字节NTAG213/215/216名片、URL、小程序跳转Type 3Felica可变Sony Felica交通卡、电子钱包Type 414443A/14443B4KB以上DESFire、P71门禁、安全支付Type 515693可变I.CODE SLIX资产追踪、盘点所以别再纠结“NFC标签就是NTAG215”了——NTAG215只是Type 2标签里最常用的一款它因为容量适中、手机兼容性极好成了项目开发者的默认选择。3. 标签内存拆解Page0到Page3、UID和那一堆十六进制数据3.1 Page0到Page3到底存了什么研讨会资料里出现了这么一组热词“nfc page0: 0x00, page1:0x10, page2:0x20, page3:0x30”。这其实就是NTAG系列标签内存的前四页。很多人第一次读标签用解码工具看到一堆十六进制数据完全不知道什么意思。这里我把这块彻底讲明白。NTAG标签的内存按页管理每页4个字节。以NTAG213为例整个用户可用区域从Page0开始一直到Page39其中前几页是出厂固化区域和配置区域。Page0存储的是UID的前3个字节Page1的前4个字节是UID的后续部分加BCC0校验码Page2存UID的剩余部分加BCC1Page3是厂商配置信息包含内部字节、容量信息、应用类型ID和锁定配置。这一串“0x00、0x10、0x20、0x30”不是固定值而是某个具体标签的存储内容的示例不同厂家、不同批次都会有差异。用解码工具读这类标签时新手往往会盯着UID看以为UID就是标签包含的全部数据。其实UID只是标签的“身份证号”出厂时已经固化不能更改一次性锁定区域除外。你真正要读写的业务数据是从Page4开始往后的用户数据区。也就是说Page0到Page3只是“标签信息区”Page4开始才是“可写的数据区”。我把NTAG213的内存分配再梳理一下页范围功能说明Page0~Page2UID与校验码出厂固化只读Page3厂商配置与锁定配置出厂配置通常只读Page4~Page39用户数据区可读可写NDEF数据放在这里Page40~Page43配置与功能区含密码、镜像功能等配置3.2 NDEF数据为什么这样分配研讨会资料里花了不少篇幅讲NDEFNFC Data Exchange Format我当时也花了一番功夫才完全理解。简单说NDEF是一种标准化的数据封装格式手机读到NDEF格式的数据后会自动根据内部的记录类型执行相应动作。比如记录类型是URI手机就跳转浏览器记录类型是Text手机就显示文本记录类型是VCard手机就打开联系人保存界面。NDEF在Type 2标签里的存储方式是从用户数据区的第一个页开始。用十六进制阅读工具看通常先看到TLVTag-Length-Value结构第一个是Tag标记0x03表示NDEF消息开始、接着是Length表示消息长度、然后是实际的NDEF消息内容、最后以0xFE结束标记收尾。这个格式看起来很原始但正因为简洁标签ROM空间利用率非常高效。我自己动手写一个NDEF URI记录时只需要把完整的十六进制数据按格式填充进标签然后用手机NFC功能一碰就能识别。比如一个“https://example.com”的NDEF URI记录在NTAG213里的二进制内容通常是以“03 12 D1 01 0B 55 03 65 78 61 6D 70 6C 65 2E 63 6F 6D FE”开头的形式。其中D1表示NDEF消息头部01表示URI记录55表示URI前缀是https://后面跟的ASCII码就是URL末尾的字符串。这一段建议有过一次手写经验后就交给工具库去生成不然太容易出错。3.3 解码工具是我用最多的一个调试装备研讨会上有人展示了一款NFC解码工具可以实时读标签的内存页面、解析NDEF内容、还能通过UID过滤防碰撞。说实话这种工具对于开发阶段来说就是“照妖镜”标签对不对、数据写入没写入、格式错在哪一眼就能看出来。我平时用的解码工具分两类一类是手机App比如NFC TagInfo、NFC Tools Pro适合现场快速看一个标签的完整信息包括协议类型、UID、NDEF内容、内存转储另一类是PC端的专业软件配合ACR122U这类USB读卡器使用适合批量读写和调试。写标签内存时PC端工具比手机端更稳定因为它能按页精确写入不会出现手机端几毫秒的时序导致写不完整。实操心得手机App读NDEF标签时如果显示的“发现NDEF消息”一栏为空先别急着怀疑标签坏了先看内存页是不是全0xFF。新标签出厂时用户区是空的十六进制全是FF需要先写入NDEF数据才能被系统识别。这属于最典型的低级问题。4. 应用开发实操Java原生、H5、ESP32三种路径4.1 JavaH5用Web技术也能调NFC研讨会现场有一个演示让我印象很深它展示的是一套基于Java原生H5的混合方案用来实现NFC标签的读写。这个方向在开发社区里讨论度很高因为很多团队已经有成熟的H5页面不想为了一个NFC功能单独开发原生App于是希望通过WebView桥接调用原生NFC能力。实现思路其实不复杂。Android原生侧用NfcAdapter的enableReaderMode或enableForegroundDispatch来捕获NFC Tag读取到Tag对象后解析NDEF消息再把解析结果通过WebView的JavaScriptInterface注入到H5页面。反过来H5页面发起写标签请求时也是通过JS Bridge调用原生Java代码打开NFC写模式把H5传来的数据写入标签。这里有一点必须提醒Android的NFC标签调度不是页面打开就自动生效的。你需要在Activity的onNewIntent里接收Tag Intent如果App在后台运行还得用前台调度机制把NFC事件优先交给当前Activity。研讨会资料里那个Demo特意把意图过滤器Intent Filter和前台调度的代码单独列了出来就是因为这块极其容易出错一个没配好手机一碰标签就直接弹出系统自带的NFC提示而不是进入你的App。4.2 ESP32扩展NFC通信从模块选型到接线写码另一个讨论度非常高的方向是用ESP32开发板扩展NFC通信能力。ESP32本身没有NFC但可以通过外接PN532或RC522模块来实现。研讨会资料里对PN532的讲解比较详细因为PN532支持I2C、SPI和UART三种接口既能当读卡器用也能模拟成卡功能更全适配性更高。我实际做的一个项目里用的是ESP32 PN532I2C模式。连接方式很简单PN532的SDA接ESP32的GPIO21SCL接GPIO22IRQ接GPIO4RSTO接GPIO5VCC接3.3VGND接GND。上电后在Arduino IDE里安装Adafruit_PN532库初始化NFC模块后读一张NTAG215的UID只需几行代码#include Wire.h #include Adafruit_PN532.h #define PN532_IRQ (4) #define PN532_RESET (5) Adafruit_PN532 nfc(PN532_IRQ, PN532_RESET); void setup(void) { Serial.begin(115200); nfc.begin(); nfc.SAMConfig(); Serial.println(等待NFC标签...); } void loop(void) { uint8_t success; uint8_t uid[] { 0, 0, 0, 0, 0, 0, 0 }; uint8_t uidLength; success nfc.readPassiveTargetID(PN532_MIFARE_ISO14443A, uid, uidLength); if (success) { Serial.print(读取到UID: ); for (uint8_t i 0; i uidLength; i) { Serial.print(uid[i], HEX); Serial.print( ); } Serial.println(); delay(1000); } }用这段代码做演示时会场有人问了几个问题我把容易踩的坑一起列在这里ESP32的3.3V供电能力有限PN532在发射功率较大时可能出现电压跌落导致读卡不稳定。最好在VCC和GND之间加一个100uF的电解电容或者用单独稳压模块供电。IRQ引脚是输入信号建议接上拉电阻到3.3V避免悬空时读取到噪声。读卡循环里加delay(1000)是为了降低CPU占用在实际项目里建议用中断方式驱动IRQ效率更高。4.3 Reader设备解码程序的几个关键点研讨会资料里有一份“nfc reader智能解码程序”的源码片段讲的是如何用读卡器批量识别不同协议的标签并自动解析。这个程序的核心逻辑其实不复杂但有几个关键点会影响识别成功率。首先是轮询策略。读卡器需要轮流发起14443A、14443B、15693等不同协议的寻卡请求检测到有卡响应后才能继续后续操作。这个轮询不能无限循环要有超时机制否则读头会一直占用射频资源其他设备无法在同一频段工作。其次是防碰撞Anti-collision。当多张卡同时进入读卡器场区时读头要通过UID的比特级仲裁选出唯一一张卡进行通信。不同的防碰撞算法对UID长度、帧同步都有限制初学者最容易忽略的是漏了处理“部分响应”的情况即标签只回复了半个UID读卡器就报错退出。最后是APDU命令封装。对于Type 4标签比如DESFire读卡器需要按照ISO 7816-4格式封装APDU指令通过SELECT、READ、WRITE等命令操作文件系统。这个过程比直接读NTAG的内存页复杂得多因为你要先过安全认证再选择应用然后才能定位到具体文件。研讨会资料建议的做法是先熟悉APDU的响应状态码比如0x9000表示成功0x6300表示认证失败这样调试时能快速定位。5. 硬件选型与天线设计从芯片对比到匹配调试5.1 常见NFC芯片/模块怎么选研讨会资料里最受硬件工程师欢迎的是一张NFC芯片/模块对比表。很多人在选型时纠结于RC522、PN532、NTAGxx之间怎么搭配我在这里把核心维度整理出来芯片/模块支持协议接口典型用途RC52214443ASPI/I2C/UART低成本读卡器常用于门禁、开发板扩展PN53214443A/B、15693、FelicaSPI/I2C/UART全能型读卡/模拟卡开发板标配PN715014443A/BI2C/NCI嵌入式设备内置NFC控制器性能强NTAG213/215/21614443AType 2NFC接口标签端芯片用于制作各种NFC标签如果你的产品只需要读卡RC522性价比最高最便宜的大概几块钱一片但它的驱动能力和协议支持都比较弱读卡距离也短。PN532贵一些但功能全能读能写还能模拟卡我一般做原型开发首选它。如果产品已经进入量产阶段建议用PN7150这类NCI接口的NFC控制器通过I2C与主控通信兼容性和稳定性都更符合量产需求。这里要注意一个概念RC522和PN532是“读卡器芯片”不是“标签芯片”。很多DIY玩家会把它们搞混买一个RC522模块回去以为可以当NFC标签贴在墙上让手机碰。这是不行的——读卡器芯片和标签芯片虽然都在13.56MHz频段但工作模式完全相反RC522只能主动发卡去读别的标签没法被手机当作标签来读。5.2 天线设计匹配的关键指标NFC天线设计是硬件工程师最容易吃亏的地方。研讨会资料里有一段关于天线匹配的分享讲得很实在NFC天线本质上是一个线圈电感等效电路画出来就是L串联一个R再加上并联的寄生电容C。要让天线工作在13.56MHz通常需要并联一个外接电容把谐振频率调到13.56MHz附近。这个调谐过程不是看电路理论就算得准的必须靠矢量网络分析仪实测。我自己调试一块NFC天线的经验是先绕制一个尺寸合适的线圈比如40mm×40mm三圈用网络分析仪看S11参数在13.56MHz处要看到明显的谐振凹陷否则就调整并联电容值。电容太小谐振频率偏高电容太大谐振频率偏低。然后还要关注Q值Q值太高会减少带宽、导致读卡器兼容性差Q值太低又会降低阅读距离。一般来说NFC天线的Q值控制在20到35之间比较合适。资料里还提了一个非常实用的小细节天线不要铺地。在PCB设计时天线区域正下方是不能有完整覆铜地的否则会严重抵消天线电感导致读卡距离直接缩水一半以上。很多第一次做NFC产品的工程师画PCB时习惯性地整板铺地结果NFC功能怎么调都调试不好最后发现是天线下方铺地的问题。注意如果产品外壳是金属材质或者设备内部有电池NFC天线旁边存在金属物体时会因涡流效应导致天线性能急剧下降。这种情况下要么把天线远离金属要么在NFC天线和金属面之间增加铁氧体隔磁片。研讨会现场有人用一块0.2mm厚度的铁氧体片贴在天线背面效果立竿见影。6. NFC安全攻防视角中继攻击与防御思路6.1 中继攻击的原理和研讨会现场讨论NFC安全相关的内容在研讨会现场讨论得非常热烈。其中一个让很多人竖着耳朵听的议题就是NFC中继攻击NFC Relay Attack。它的原理其实不复杂正常场景下手机/读卡器必须贴近卡片才能完成通信距离被限制在几厘米。但攻击者可以在读卡器旁放一个“中继设备A”在真正的卡片旁放一个“中继设备B”两个中继设备之间通过无线网络、蓝牙或者其他长距离通道通信。这样用户手里的卡明明没有移动但远端的读卡器却以为卡已经靠近了从而实现远程盗刷。从射频角度说NFC读卡器和中继设备A之间的通信仍然是13.56MHz近场通信中继设备A把从读卡器收到的射频信号解调成数字信号再通过远程链路传给中继设备B中继设备B再把这串数据调制回复给真正的卡片。整套链路对读卡器和卡片来说和直接贴近通信没有区别因为协议层无法区分物理距离。这就是中继攻击难以被单一手段防住的原因。研讨会资料里明确指出了这一点中继攻击不是破解了NFC的加密算法而是绕过了物理距离限制属于“中间人”思想的物理版。这也是为什么单纯依赖通信加密无法100%防住中继攻击——加密保护的是数据保密性而不是通信实体的物理位置可信性。6.2 实际防御手段针对中继攻击实际可行的防御手段主要分三层。第一层是应用层加双向认证。读卡器和卡片之间通过动态密钥进行双向认证即便中继设备能把数据来回转发它也不能伪造新的认证数据。动态密钥每次会话都不同能有效防止重放攻击。这在Type 4标签比如DESFire上实现得比较好Type 2标签由于自身算力太弱很难做到动态双向认证。第二层是距离限制机制。比如通过测量信号往返时间Round Trip Time来判断通信双方是否真的在物理近距离内。因为中继链路会引入额外的传播延迟即使延迟只有几百纳秒在精密测量下也会暴露。更进一步的方案还有通过额外的超宽带UWB测距来确认卡片与读卡器的相对位置比如数字车钥匙方案就是这样做的因为UWB测距精度可以达到厘米级比单纯靠NFC场强判断可信得多。第三层是产品交互层面的防护。比如移动支付场景强制要求用户解锁屏幕才能交易门禁系统要求刷卡的同时输入PIN码或验证生物识别车载系统要求手机同时具备安全芯片的能力。这些都是利用多因素认证来削弱中继攻击的实际价值。实操心得如果读者正在做需要一定安全级别的NFC产品我建议无论是DIY还是量产都不要只用NTAG213/215这类Type 2标签做身份凭据。它们的UID可被克隆某些厂牌甚至能用模拟芯片写同款UID认证机制也有限。至少要用DESFire EV2这类支持3DES/AES加密的Type 4标签别拿“碰一碰”的便利性去换本不该牺牲的安全性。7. 创意玩法拆解用NFC 215芯片打造一面音乐墙7.1 整体方案与物料清单研讨会创意分享环节最热闹的当属“用NFC 215芯片DIY音乐墙”的案例——通过酷我/酷狗这类音乐App的歌曲快捷链接把音乐播放动作变成一次手机碰一碰的体验。现场演示的视频虽然只有十几秒但背后的技术点其实很有层次。这里先说明一下原理手机碰NFC标签时系统读取到标签里的NDEF URI记录然后根据URI的协议跳转。如果你是直接存一个https链接手机只会打开浏览器但如果你想唤起某个音乐App并且自动播放指定的歌曲就需要在标签里写入一条带有该App私有scheme的URL比如“kwmusic://”或“kugou://”之类的形式。手机识别到这类scheme后会唤起对应的App并解析后面的参数自动拉起歌曲播放。这个玩法做成项目的物料清单其实很便宜NTAG215贴纸标签或圆形NFC芯片标签单价大概1-3元容量选504字节正好够放一个较长的URL加一些文本备注。一台支持NFC的Android手机iPhone对私有scheme的限制比较多体验不如Android稳定。一个带背景音乐App的系统比如Android系统即可。装饰用的卡片外壳可以用厚卡纸、亚克力板或者木质贴片。7.2 从标签写入到上墙的完整流程第一步准备音乐链接。打开音乐App找到你想用的那首歌在分享菜单里选择“复制链接”得到带有歌曲ID的分享URL。然后需要把这个链接转成App的私有scheme格式。不同App的规则不一样通常网上可以搜到对应的scheme规则也可以通过抓包分析得到。这一步的细节依赖具体App版本我建议直接以“把链接转成App可识别的scheme”为搜索关键词用现成的规则比自己在App里试错快得多。第二步生成NDEF消息。这一步我推荐用NFC Tools Pro因为它能可视化地组合NDEF记录。你只需要新建一条“URI”记录把最终得到的scheme链接填进去保存后可以预览内存页面。如果你的链接比较长NTAG213的144字节空间可能不够用这就是为什么要选NTAG215504字节的原因。第三步写入标签。用PN532模块配合PC端软件写入或者直接在手机上用NFC Tools Pro写入。写入前先确认标签是全新的或者内存已被清空否则直接覆盖容易留下残留数据。写入后建议用解码工具再读一遍确认NDEF消息格式正确内存末尾的0xFE结束标记没有被截断。第四步把标签贴在卡片或墙上用手机碰一下测试效果。如果发现手机没有唤起App先排查这几点标签里的URI是不是正确scheme格式App有没有允许scheme唤起手机系统是不是把NFC触碰默认交给了其他App7.3 音乐墙的扩展思路研讨会结束后我在自己的项目里对音乐墙做了一些扩展这里也分享给大家参考。一个方向是做“播放场景切换”。我在同一面墙上贴了多张标签每张标签对应不同功能比如“早晨咖啡音乐”“深夜助眠”“运动快节奏”碰一下对应的标签就自动切换播放列表。实现方式其实只是多写几张标签每张标签的scheme链接指向不同歌单成本极低但互动体验非常新鲜。另一个方向是做“访客留言墙”。在标签里写入NDEF文本记录来访朋友用手机碰一下就能在系统弹出框里看到你留下的欢迎语或故事。NTAG215的空间足够塞下大概500个汉字用来承载一段短文本绰绰有余这比粘贴一张二维码更隐蔽、更有仪式感。还有一个和ESP32结合的方向我觉得潜力更大用ESP32PN532在墙面背后做一个“标签触碰记录器”每当有人碰标签时记录UID和触碰时间上传到本地服务器做数据统计。这样音乐墙就从单向交互变成了一个带行为数据的装置很适合门店做用户动线分析或者做互动展览的访客画像。8. 会后的一些记录与复盘翻完这套2022 NFC上海研讨会的资料我最大的收获其实不是哪段代码或者哪个协议表格而是整个行业对NFC的定位正在悄悄变化它不再只是读卡器设备上的一个外设而是更适合做“轻交互”的入口。手机碰一碰、碰一下连Wi-Fi、碰一下唤起App、碰一下完成巡检打卡——这些交互不需要装App、不需要扫码、不怕贴膜遮挡在很多场景里比二维码更顺手。资料里那些看似零散的现场Demo拼在一起其实是一条完整的技术链路从协议选型、标签内存设计到应用开发、天线调试再到安全防护和创意玩法。单独看某一章节也许会觉得自己用不上但当你需要一个完整的NFC产品方案时这套资料的参考价值就显现出来了。我自己实际操作中最大的体会是NFC项目最容易翻车的地方往往不是上层逻辑而是最底层的“通信距离”和“数据格式”这两个环节。距离不够产品体验瞬间崩塌数据格式不对标签看起来是写了但手机就是识别不了。所以入场之前先把阅读范围从“搞懂NDEF”扩展到“把协议、标签、天线、App这几层链路打通”会省下大量排查时间。最后再分享一个小技巧做NFC项目时手边一定要常备一张空白NTAG215和一台带解码功能的手机。遇到任何“标签识别不了”“数据读不出来”的玄学问题先把空白标签写一段最简单的https链接用手机碰一下。如果空白标签能唤起浏览器说明你的读卡链路和标签都是好的问题出在你的数据内容上如果空白标签也不行那就要回头查天线和模块了。这个二分法排查流程我实测下来非常省心。
返回列表