深入解析NDEF协议：NFC数据交互的核心规范与应用实践

1. 从“碰一碰”说起：为什么需要NDEF协议？

你可能已经习惯了用手机“碰一碰”来开门禁、刷公交卡，或者和朋友分享一张网页。这种便捷的背后，是近场通信（NFC）技术在默默工作。但你想过没有，当你的手机靠近一个NFC标签或另一台手机时，它们之间到底在“聊”什么？聊天的内容又是以什么格式组织的？

这里就引出了我们今天的主角：NDEF协议。你可以把它想象成NFC世界里的“通用语言”或“标准信封”。如果没有它，就像两个人一个说中文一个说法语，或者写信没有统一的信封格式和邮编规则，信息根本无法有效传递。

我刚开始接触NFC开发时，也踩过不少坑。比如，我写了一个App想读取标签里的网址，结果发现读出来的是一堆乱码；又比如，我想让手机碰一下就能自动连接Wi-Fi，却发现不同品牌的手机反应不一样。后来我才明白，问题都出在对NDEF协议的理解不透彻上。NDEF（NFC Data Exchange Format），即NFC数据交换格式，正是由NFC论坛制定的一套核心规范，它定义了数据该如何打包、如何标识、如何被解析。

简单来说，NDEF协议解决了三个核心问题：

1. 数据怎么装：把文本、网址、电话号码等不同类型的数据，打包成一个标准化的“包裹”。
2. 包裹怎么送：这个“包裹”可以在手机和标签之间、手机和手机之间可靠地传递。
3. 收到怎么认：接收方拿到“包裹”后，能立刻知道里面装的是什么（是文本还是网址），以及该如何处理它。

对于开发者而言，无论是想开发一个读取智能海报信息的应用，还是实现类似“碰一碰传文件”的Android Beam功能，亦或是为智能硬件添加简单的配置入口，深入理解NDEF协议都是绕不开的第一步。接下来，我们就一起拆解这个“标准信封”，看看它里面到底藏着哪些奥秘。

2. 拆解NDEF的“标准信封”：消息与记录的结构

如果把一次完整的NFC数据交互看作寄一封信，那么NDEF消息（NdefMessage） 就是这封信本身，而NDEF记录（NdefRecord） 则是信纸里包含的一个个具体段落。一条NDEF消息必须包含一条或多条NDEF记录，它们按照顺序排列，共同承载着要传递的信息。

2.1 NDEF消息的宏观视图

从结构上看，一条NDEF消息非常简单，就是一系列NDEF记录的线性集合：

[NDEF记录1] -> [NDEF记录2] -> … -> [NDEF记录N]

这种设计非常灵活。例如，一个智能海报的NDEF消息可能包含三条记录：第一条是一个文本记录，描述海报内容；第二条是一张缩略图记录；第三条是一个URI记录，链接到详细页面。当手机读取时，可以按顺序处理这些记录。

2.2 NDEF记录的微观解剖

每条NDEF记录才是真正存放数据的地方，它的结构稍微复杂一些，但我们可以把它想象成一个标准化的数据集装箱，里面分成了几个固定的区域。一个NDEF记录的完整布局如下：

这个结构看起来有点抽象，我们重点看一下最开头的那个“记录状态字节”，它里面的几个标志位决定了记录的很多关键行为：

• MB（Message Begin，消息开始）：必须为1，表示这是整个NDEF消息的第一条记录。
• ME（Message End，消息结束）：必须为1，表示这是整个NDEF消息的最后一条记录。
• CF（Chunk Flag，分块标志）：如果一条记录的数据量太大，可以分成多个“块”来传输。CF=1表示这是一个分块记录的中间块，CF=0表示不是分块或是分块的开始/结束块。在实际应用中，分块并不常用。
• SR（Short Record，短记录）：这是一个非常实用的优化。当SR=1时，后面的“负载长度”字段只占1个字节，这意味着单条记录的负载不能超过255字节。对于大多数存放网址、简短文本的场景，这完全够用，并且能节省存储空间。如果负载很大（比如一张图片），则需要设置SR=0，使用4字节的长度字段。
• IL（ID Length Present，ID长度存在）：如果IL=1，表示本记录包含“ID长度”和“ID”字段；如果IL=0，则这两个字段都不存在。大多数简单应用里，我们不需要为记录指定ID，所以IL常设为0。
• TNF（Type Name Format，类型名称格式）：这是一个3位的字段，但它极其重要！它定义了如何解释后面的“类型”字段。我们下一章会详细展开。

我刚开始手动构造NDEF记录时，就曾忘记设置MB和ME标志，导致手机完全无法识别这条消息。也曾经因为想当然地把一个长URL塞进SR=1的记录里，导致数据被截断。理解这些标志位，是正确生成和解析NDEF数据的基础。

3. 核心中的