4、NFC协议栈：NFC-A、NFC-B、NFC-F、NFC-V的区别与选择，LLCP、NDEF、SNEP协议简介
好，咱们进入NFC协议栈的核心地带。说实话，很多刚入行的工程师容易把NFC想得太简单——不就是碰一下读个卡吗？其实底下那套协议栈，比你想象的要复杂得多。我当年第一次调NFC驱动时，就被这四种Type搞得晕头转向。今天咱们就把它们掰开揉碎了讲清楚。
4.1 四种NFC射频技术：A/B/F/V，到底有啥区别？
NFC的物理层通信，说白了就是定义了「卡」和「读卡器」之间怎么握手、怎么传数据。ISO/IEC 18092和ISO/IEC 21481这两个标准，把NFC分成了四种Type：NFC-A、NFC-B、NFC-F、NFC-V。嗯，这里要注意，它们不是互斥的，很多NFC芯片同时支持好几种。
| 技术类型 | 基础标准 | 调制方式 | 波特率 | 典型应用 |
|---|---|---|---|---|
| NFC-A | ISO/IEC 14443 Type A | ASK 100%调制 | 106 kbps | MIFARE Classic、门禁卡 |
| NFC-B | ISO/IEC 14443 Type B | ASK 10%调制 | 106 kbps | 身份证、护照、公交卡 |
| NFC-F | JIS X 6319-4 (FeliCa) | ASK 10%调制 | 212 / 424 kbps | 日本交通卡、索尼FeliCa |
| NFC-V | ISO/IEC 15693 | ASK 10%或100%调制 | 26.48 kbps | 物流标签、图书馆管理 |
你可能会问：「为什么搞这么多标准？」其实原因很简单——历史遗留问题。NFC-A和NFC-B都是从非接触式智能卡标准演变来的，NFC-F是日本FeliCa的底子，NFC-V则是针对远距离（1米左右）的标签应用。我在项目中遇到过最头疼的情况：一台车载中控要同时兼容这三种卡，结果发现不同厂家的NFC芯片对Type B的防冲突算法实现有差异，调了整整两周。
4.2 怎么选？我的经验之谈
选哪种Type，其实取决于你的应用场景。我个人习惯这样判断：
- 做门禁或支付：首选NFC-A。MIFARE生态太成熟了，芯片便宜，资料也多。但要注意，MIFARE Classic的加密已经被破解了，别用在安全要求高的场景。
- 做身份证读取：必须支持NFC-B。中国的二代身份证、护照都走Type B协议。我记得有一次客户要求车载系统能读取身份证信息，结果发现NFC芯片的Type B接收灵敏度不够，换了天线才搞定。
- 做高速数据传输：考虑NFC-F。FeliCa的通信速率能到424 kbps，比A和B快不少。日本的车载支付系统很多用这个。
- 做远距离标签：选NFC-V。它的读取距离可以到1米左右，适合停车场入口、物流扫描。不过速率慢，不适合大数据量。
核心建议：如果你的产品要面向全球市场，最好选同时支持NFC-A、NFC-B、NFC-F的三模芯片。别问我为什么——我曾经只做了A和B，结果日本客户说用不了FeliCa，直接丢单了。
4.3 上层协议：LLCP、NDEF、SNEP
射频层搞定了，接下来就是数据怎么组织、怎么交换。NFC论坛定义了三层关键协议，我按从底到顶的顺序给你捋一遍。
4.3.1 LLCP（Logical Link Control Protocol）
LLCP是NFC设备之间的「连接管理器」。它负责建立逻辑链路、管理数据包的分段和重组、提供可靠传输。说白了，就是让两个NFC设备能像TCP一样互相发数据。
LLCP有两种模式：
- 无连接模式：类似UDP，发完不管，适合小数据量。
- 面向连接模式：类似TCP，有确认和重传，适合传输文件。
我在调试车载蓝牙与NFC配对时，就用了LLCP的面向连接模式来传输配对密钥。嗯，这里要注意：LLCP的最大数据包长度是128字节，超过就要分段。我第一次没注意这个限制，传大文件时直接丢包了。
4.3.2 NDEF（NFC Data Exchange Format）
NDEF是NFC世界里最常用的数据格式。它定义了一种轻量级的消息结构，可以封装文本、URL、MIME类型等数据。你手机碰一下NFC标签弹出网页，背后就是NDEF在干活。
一个NDEF消息由多个Record组成，每个Record包含：
- Header：类型、长度、是否最后一条等标志
- Type：数据类型，比如"U"表示URI，"T"表示文本
- Payload：实际数据
// 一个简单的NDEF消息示例（写URI到标签）
NDEF消息：
Record 1:
TNF = 0x01 (NFC Forum well-known type)
Type = "U" (URI)
Payload = "https://www.example.com"避坑指南：我曾经在项目中用NDEF写了一个长URL，结果标签容量不够。NDEF的Payload最大取决于标签类型，MIFARE Ultralight只有64字节，别超了。
4.3.3 SNEP（Simple NDEF Exchange Protocol）
SNEP是建立在LLCP之上的应用层协议。它让两个NFC设备可以互相推送NDEF消息。比如你用手机碰一下车载屏幕，把导航地址传过去，背后就是SNEP在干活。
SNEP的工作流程很简单：
- 客户端发送一个PUT请求，里面包含NDEF消息。
- 服务器收到后，返回一个响应（成功或失败）。
- 如果消息太大，SNEP会利用LLCP的分段机制自动分包。
SNEP的默认最大消息大小是1024字节。如果你要传更大的数据，需要在LLCP层协商更大的MIU（最大信息单元）。我建议一般不要超过4096字节，否则传输时间太长，用户可能等不及就把手机拿开了。
4.4 协议栈的完整调用链路
咱们把整个流程串起来，你就能看清全貌了：
应用层（你的App）
↓ SNEP（推送NDEF消息）
↓ NDEF（格式化数据）
↓ LLCP（建立逻辑链路）
↓ 射频层（NFC-A/B/F/V，物理通信）
↓ 天线（电磁耦合）举个例子：你用手机碰车载NFC标签，读取车辆信息。底层走的是NFC-A（因为标签是MIFARE），数据用NDEF封装成文本格式，LLCP负责把数据分段传过来，最后应用层解析显示。整个过程不到100毫秒，但背后每一层都在干活。
重要提醒：在车载环境下，NFC天线会受到金属和电磁干扰。我建议你在设计时预留天线调谐空间，并且一定要做实车测试。我曾经在实验室调得好好的，装到车上就死活读不到卡，最后发现是仪表盘的金属框架影响了天线Q值。
好了，这一章的内容就到这儿。下一章咱们会深入LLCP的细节，包括连接建立、数据交换和错误处理。到时候我会分享一个实际的车载NFC配对案例，保证干货满满。