C#读写NDEF智能海报：字节解析与读卡器实战

简介：这是一份面向C#开发者的NFC NDEF标签读写源码工程，适合需要实现智能海报、网址跳转、WiFi连接、蓝牙配对等近场通信应用的软件工程师。工程围绕NDEF智能海报场景，完整覆盖Forum Type2/Type4/Type5、Ntag2x、15693、MifareClassIc等常见NFC标签类型，并提供写入NDEF纯文本、地图坐标、呼叫电话、电子名片、启动APP应用以及读取标签信息等多种封装接口。压缩包共45个文件，包含12个C#核心代码文件、2个DLL库、4个配置文件及编译生成的EXE/PDB等，压缩后仅1.6MB，便于直接下载、修改与二次编译。工程附带标准Visual Studio解决方案（sln/csproj）与界面资源，可快速定位Form1主窗体与Program入口。已有236人学习浏览，适合正在开发NFC读写器上位机或NDEF标签制作工具的开发者借鉴，可作为标签格式封装、类型适配与界面交互的参考实现。

1. 拿 C# 读写 NDEF 智能海报文本：先把卡里的字节流拆明白

把一张已经写好内容的 NFC 智能海报标签贴在展架上，手机一碰就能弹出网址或小程序——这个场景不陌生，但真到要自己用 C# 写一套读写程序时，很多人第一反应是找现成库，结果发现 .NET 生态里能直接用、又不依赖特定厂商 SDK 的 NDEF 库少得可怜。这篇笔记就是基于一套 C# 读写文本、URI、小程序跳转等 NDEF 智能海报文本的源码，完整走一遍从字节流解析到 PC/SC 读卡器读写的流程。适合三种人：正在做 NFC 标签管理工具的 C# 上位机开发者、需要批量写入海报标签的运营人员、以及被“读卡器读出来是乱码”这种问题折磨过的同学。这里不会只讲怎么调库，而是把 NDEF 记录怎么在字节里组织、C# 怎么写字节解析器、写卡时为什么容易翻车，一次性讲透。

2. NDEF 格式拆解：海报内容在卡里到底长什么样

2.1 记录头：从第一个字节读出 TNF 和长度分布

NDEF（NFC Data Exchange Format）是 NFC Forum 定义的数据封装格式，一张智能海报标签对应的是一整条 NDEF 消息（Message），消息由一条或多条 Record 组成。每条 Record 以记录头（Record Header）开头，C# 解析时的第一步就是把 Header 里那几个 bit 拆出来。

一个 NDEF 记录头固定是 1 个字节，bit 分布如下：

C# 里读这个字节最直接的做法是位运算：

byte header = ndefBytes[offset]; bool mb = (header & 0x80) != 0; bool me = (header & 0x40) != 0; bool cf = (header & 0x20) != 0; bool sr = (header & 0x10) != 0; bool il = (header & 0x08) != 0; byte tnf = (byte)(header & 0x07);

这段代码把记录头的每一位拆开存成独立变量，sr决定 payload 长度字段占 1 字节还是 4 字节，il决定后面是否跟着 ID 字段。拿到这些标记后，才能继续往下一个字段走。很多新手直接跳过 Header 就去读 payload，读出来全是偏移量错乱后的乱码。

2.2 TNF 类型名格式与 C# 解析的对应关系

TNF 是一个 3 bit 的值，它告诉解析器“这条记录的类型名是用什么方式表达的”。常见的 TNF 值有 0（Empty）、1（NFC Forum well-known type）、2（Media-type，比如 MIME）、3（绝对 URI）、4（外部类型）。智能海报里的文本和 URI 记录，TNF 基本都是 1，也就是 well-known type，此时 Type Name 字段存的是 "T" 或 "U" 这样的短类型名。

C# 读取 Type Name 的流程是：跳过 Header 之后，先按typeLength读取类型名。Type Length 是一个字节，紧跟在 Header 后面。SR 标记会影响 payload length 的长度，但不影响 typeLength 的位置。完整读字段顺序是：Header -> Type Length -> ID Length（如果 IL=1）-> Type Name -> ID（如果 IL=1）-> Payload Length -> Payload。

int offset = startIndex; byte tnf = (byte)(ndefBytes[offset] & 0x07); bool sr = (ndefBytes[offset] & 0x10) != 0; bool il = (ndefBytes[offset] & 0x08) != 0; int typeLength = ndefBytes[offset + 1]; int idLength = il ? ndefBytes[offset + 2] : 0; int payloadLength = sr ? ndefBytes[offset + 2 + (il ? 1 : 0)] : BitConverter.ToInt32(ndefBytes, offset + 2 + (il ? 1 : 0));

这里的关键点是payloadLength的读取位置会受il影响，不能写死偏移量。实际项目里我见过多个解析器在这块把 ID Length 字段漏掉，导致整条消息的字节偏移错位，读出来的 payload 长度和真实数据对不上。解析前建议先把整条消息的字节数组用Debug.Assert校验长度，再走解析逻辑。

2.3 Smart Poster 记录：一条消息里塞进多条子记录

智能海报（Smart Poster）本身是一个 NFC Forum 定义的 well-known type "Sp"。一条 SP 记录内部可以包含若干条子记录，常见的有标题文本（type "T"）、URI（type "U"）、推荐动作（type "act"，值是 0x01 表示 Do Action）。外层 SP 记录会出现在标签的 CC（Capability Container）之后的数据区开头。

C# 解析 Smart Poster 时不能只解析到第一层记录就停，必须递归解析嵌套结构。我的做法是写一个ParseNdefMessage方法，返回一个List<NdefRecordInfo>，然后在判断出当前记录 type 为 "Sp" 时，把 payload 部分再次当作一条 NDEF 消息传入解析函数，递归调用。

public List<NdefRecordInfo> ParseNdefMessage(byte[] payload) { var records = new List<NdefRecordInfo>(); int offset = 0; while (offset < payload.Length) { int start = offset; byte header = payload[offset]; bool mb = (header & 0x80) != 0; bool me = (header & 0x40) != 0; bool sr = (header & 0x10) != 0; bool il = (header & 0x08) != 0; byte tnf = (byte)(header & 0x07); offset++; int typeLength = payload[offset++]; int idLength = il ? payload[offset++] : 0; string typeName = Encoding.ASCII.GetString(payload, offset, typeLength); offset += typeLength; offset += idLength; int payloadLength = sr ? payload[offset++] : BitConverter.ToInt32(payload, offset); offset += sr ? 0 : 4; byte[] content = new byte[payloadLength]; Array.Copy(payload, offset, content, 0, payloadLength); offset += payloadLength; records.Add(new NdefRecordInfo { TNF = tnf, TypeName = typeName, MB = mb, ME = me, Payload = content }); } return records; }

这段代码的核心是一个 while 循环按记录头的元数据逐条切分字节。Array.Copy之前已经把offset精确移到了 payload 起始位置，所以切出来的content是干净的数据。特别说明一下sr为 false 时，payloadLength占 4 字节（大端序），有的移植代码直接用BitConverter.ToInt32会拿到反序的结果，因为 C# 默认是小端序，需要先做Array.Reverse。这是 C# 写 NDEF 解析最容易踩的坑。

3. 用 PC/SC 读卡器读海报：从 APDU 到完整 NDEF 报文

3.1 C# 连接读卡器：SCard 上下文的建立与卡连接

要读 NDEF 标签，C# 端通常走 PC/SC 接口。常见读卡器是 ACR122U 这类 CCID 设备，Windows 会把它识别为智能卡读卡器。C# 里通过SCardEstablishContext建立资源管理器上下文，再列出可用读卡器，之后用SCardConnect连接卡。

IntPtr hContext; int ret = SCardEstablishContext(2, IntPtr.Zero, IntPtr.Zero, out hContext); if (ret != 0) throw new Exception("SCardEstablishContext 失败: " + ret); uint pcchReaders = 0; ret = SCardListReaders(hContext, null, null, ref pcchReaders); byte[] readersBuf = new byte[pcchReaders]; ret = SCardListReaders(hContext, null, readersBuf, ref pcchReaders); string readers = Encoding.ASCII.GetString(readersBuf).TrimEnd('\0'); string readerName = readers.Split('\0')[0]; IntPtr hCard; ret = SCardConnect(hContext, readerName, 0, 3, out hCard);

这里第一个参数2表示 SCARD_SCOPE_USER，第三个参数是共享模式，3是 SCARD_SHARE_SHARED。SCardConnect成功之后拿到hCard句柄，后续所有 APDU 交换都走这个句柄。注意SCardListReaders第一次调用传 null 是为了获取缓冲区大小，第二次才真正填充数据，这两个调用不能合并，否则缓冲区不够会报 0x80100008。

3.2 发送 READ BINARY 读取 NDEF 数据区

连接成功之后，要读取标签里的 NDEF 报文。NFC Tag 通常用 Type 2 Tag 或 Type 4 Tag 规范。Type 4 Tag 的数据访问服务是 NDEF Tag Application，通过 SELECT 指令选中，然后用 READ BINARY 按块读取。Type 2 Tag 则直接用 READ 指令读块。下面是 ACR122U 配合 Type 4 Tag 的读取流程：

byte[] selectApdu = { 0x00, 0xA4, 0x04, 0x00, 0x07, 0xD2, 0x76, 0x00, 0x00, 0x85, 0x01, 0x01, 0x00 }; byte[] resp = Transmit(hCard, selectApdu); // 预期返回 0x9000 byte[] readApdu = { 0x00, 0xB0, 0x00, 0x00, 0x10 }; resp = Transmit(hCard, readApdu);

Transmit方法内部封装了SCardTransmit，APDU 的组成是 CLA=0x00，INS=0xB0（READ BINARY），P1/P2 表示起始块位置，最后那个 0x10 是读取长度。真正实现中不能只读一次，要循环读取直到拿到完整 NDEF 报文，每次读完后判断响应中是否包含结束标记（多为 0xFE），否则继续读取下一块并拼接。

List<byte> ndefBytes = new List<byte>(); int block = 0; while (true) { byte[] apdu = { 0x00, 0xB0, (byte)(block >> 8), (byte)(block & 0xFF), 0x10 }; byte[] resp = Transmit(hCard, apdu); if (!IsSuccess(resp)) break; byte[] data = resp.Take(resp.Length - 2).ToArray(); ndefBytes.AddRange(data); if (data.Contains(0xFE)) { ndefBytes.Remove(0xFE); break; } block += 0x10; }

这段循环代码的关键是每次都从上次结束的位置继续读，block递增步长是 0x10（16 字节），与 Type 4 Tag 的块尺寸保持一致。读取过程中遇到 0xFE 要移除，因为它是 NDEF 消息的结束标记，不是有效业务数据。IsSuccess判断的是响应尾部两个字节是否为 0x90 0x00，如果返回 0x6A82，说明已经读到标签末尾之外了。

3.3 解析结果验证：把字节流还原成可读文本

拿到完整 NDEF 字节流之后，用第 2 章的ParseNdefMessage方法解析。这里有个经验：不要把 CC 文件头里的头部信息当成 NDEF 消息的一部分。CC（Capability Container）里保存的是标签容量和读写属性，Type 4 Tag 的 CC 从偏移 0x00 开始，NDEF 报文实际在 0x0000 之后的 NL（NDEF Length）字段开始。很多 C# 新手直接把ReadBinary全部返回值丢给解析器，结果把 CC 的长度字节也当成记录头解析，第一层就错位。

var records = ParseNdefMessage(ndefBytes.ToArray()); foreach (var rec in records) { if (rec.TypeName == "Sp") { var innerRecords = ParseNdefMessage(rec.Payload); foreach (var inner in innerRecords) { if (inner.TypeName == "T") { string lang = Encoding.ASCII.GetString(inner.Payload, 0, 2); string text = DecodeTextPayload(inner.Payload); Console.WriteLine($"[文本] {lang}: {text}"); } else if (inner.TypeName == "U") { string url = DecodeUriPayload(inner.Payload); Console.WriteLine($"[URI] {url}"); } } } }

DecodeTextPayload那一步要处理文本编码标记：payload 第一个字节高三位是编码格式，0 表示 UTF-8，1 表示 UTF-16；低五位是语言码长度。这个位置的常见问题是直接把 payload 从头按 UTF-8 解码，如果遇到 UTF-16 编码的记录，中文内容会变成夹杂空字节的乱码。文本解码在后面的避坑章节还会展开。

4. 写入海报：文本、URI 与小程序跳转的三种录法

4.1 构造文本记录与 URI 记录的 payload

写卡本质上是对 NDEF 消息做反向组装。文本记录的 payload 结构是：状态字节（编码格式 + 语言码长度）+ 语言码（如 "zh"）+ 实际文本内容。URI 记录的 payload 则是：协议标识符字节（URI Identifier Code）+ 去掉前缀的 URL 内容。协议标识符的值在 NFC Forum 的 URI Record Type Definition 里有定义，比如 0x01 表示http://www.，0x02 表示https://，0x03 表示http://，0x04 表示https://www.。

C# 构造记录的核心代码如下：

public byte[] BuildTextRecord(string text, string langCode = "zh", bool isUtf8 = true) { byte langLen = (byte)langCode.Length; byte header = (byte)((isUtf8 ? 0 : 1 << 7) | langLen); byte[] langBytes = Encoding.ASCII.GetBytes(langCode); byte[] textBytes = isUtf8 ? Encoding.UTF8.GetBytes(text) : Encoding.Unicode.GetBytes(text); using var ms = new MemoryStream(); ms.WriteByte(header); ms.Write(langBytes, 0, langBytes.Length); ms.Write(textBytes, 0, textBytes.Length); return ms.ToArray(); } public byte[] BuildUriRecord(string url) { byte idCode = 0x00; string body = url; if (url.StartsWith("https://www.")) { idCode = 0x04; body = url.Substring(12); } else if (url.StartsWith("http://www.")) { idCode = 0x03; body = url.Substring(11); } else if (url.StartsWith("https://")) { idCode = 0x02; body = url.Substring(8); } else if (url.StartsWith("http://")) { idCode = 0x01; body = url.Substring(7); } using var ms = new MemoryStream(); ms.WriteByte(idCode); byte[] bodyBytes = Encoding.UTF8.GetBytes(body); ms.Write(bodyBytes, 0, bodyBytes.Length); return ms.ToArray(); }

构造 URI 记录时有一个容易忽略的点：URI Identifier Code 的作用是压缩长度，让标签有限的空间能存更多内容。如果你传入的 URL 已经带了https://前缀，就不要再多加一层前缀，否则会出现双前缀。我一般会在构造前统一把所有 URL 转成小写再判断前缀，避免大小写不一致导致前缀识别失败。

4.2 小程序跳转：AAR 记录与 androidapp:// 前缀的取舍

智能海报里“小程序跳转”在 C# 源码中一般有两种实现路径。第一种是直接在 URI 记录里写入微信小程序生成的链接（形如https://wxaurl.cn/...），手机碰一碰后浏览器打开该链接，微信再根据链接规则唤起小程序。第二种是写入 Android Application Record（AAR），type 是 NFC Forum 外部类型，TNF=4，Type Name 是android.com:pkg，payload 是包名。

写 AAR 记录的核心代码如下：

public byte[] BuildAarRecord(string packageName) { byte[] type = Encoding.UTF8.GetBytes("android.com:pkg"); byte[] payload = Encoding.UTF8.GetBytes(packageName); using var ms = new MemoryStream(); ms.WriteByte(0x04); // TNF = External Type ms.WriteByte((byte)type.Length); ms.WriteByte(0x00); // ID Length = 0 ms.Write(type, 0, type.Length); ms.Write(payload, 0, payload.Length); return ms.ToArray(); }

但这里要说清楚：AAR 的作用是强制 Android 手机打开指定 App，它并不是微信小程序的标准唤起方式。小程序跳转的场景里，最常见做法还是把微信提供的小程序链接直接写成 URI 记录，因为 AAR 的语义是“打开某个原生应用”，如果手机没装对应 App，行为反而失控。C# 源码里把 AAR 和 URI 都作为可选项，我的建议是：单存小程序链接用 URI，如果要实现“打开 App 且 App 内直达小程序”则同时写两条记录，一条 URI 带链接、一条 AAR 带包名，并把 URI 记录放在前面。

4.3 UPDATE BINARY 回写：处理写错后的后悔药

写卡操作比读卡多一个风险：写入失败可能把原有内容抹掉一半。所以回写前一定要先把原始字节保留到内存，写失败时能恢复。回写 Type 4 Tag 的 NDEF 区时，先更新 NL 字段（NDEF 消息长度），再写 NDEF 报文内容，最后更新 CC 里的写保护位。顺序不能乱，否则设备读到一半的长度字段是旧的。

public bool WriteNdef(IntPtr hCard, byte[] ndefMessage) { byte[] nlen = BitConverter.GetBytes(ndefMessage.Length); if (BitConverter.IsLittleEndian) Array.Reverse(nlen); byte[] updateNlen = new byte[5] { 0x00, 0xD6, 0x00, 0x00, (byte)nlen[3] }; byte[] resp = Transmit(hCard, updateNlen); if (!IsSuccess(resp)) return false; int offset = 0; while (offset < ndefMessage.Length) { int chunkSize = Math.Min(0x10, ndefMessage.Length - offset); byte[] apdu = new byte[5 + chunkSize]; apdu[0] = 0x00; apdu[1] = 0xD6; apdu[2] = (byte)(offset >> 8); apdu[3] = (byte)(offset & 0xFF); apdu[4] = (byte)chunkSize; Array.Copy(ndefMessage, offset, apdu, 5, chunkSize); resp = Transmit(hCard, apdu); if (!IsSuccess(resp)) { // 写失败，尝试用读回的数据恢复 return false; } offset += chunkSize; } return true; }

0x00 0xD6是 UPDATE BINARY 指令，后面跟起始地址和长度。回写时一次写一块，块大小 0x10 是标准安全值，不要为了减少指令次数改成一次写 0xFF，很多 Type 4 Tag 实现不支持跨块连续写。写失败的表现通常是返回 0x6581（写入失败），此时不要反复重试同一条指令，先读取当前块内容对比判断是硬件问题还是地址越界。

5. NDEF 读写避坑清单：编码、长度与响应状态码

5.1 中文文本读出来乱码

现象：用手机 App 能正常显示中文，但自己写的 C# 程序读出来是一串乱码，或者只有第一个字正常、后面全是问号。

原因：文本记录的状态字节里，bit 7 表示编码，1 表示 UTF-16，0 表示 UTF-8。很多写卡工具默认写入 UTF-8，但部分旧工具会写 UTF-16。另外语言码是双字节，如果解析时把语言码长度读错或直接把状态字节当成语言码的一部分，文本整体偏移一个字节，中文全部错位。

解决：解析时先读取 payload[0] 的高三位判断编码，再取低五位作语言码长度。然后从 payload[1 + langLen] 开始解码文本。如果读出来的首字符是空字符或\0，立刻检查是不是把编码位当成了语言码的一部分。我后来在解析入口统一打了日志，每次解析都输出 payload 前 8 个字节的 HEX，肉眼比对数据重装现场，效率比盲改快很多。

5.2 URI 记录解析出来双前缀

现象：读出来 URL 是http://https://example.com或者https://http://example.com。

原因：写卡时构造 payload 没有用 URI Identifier Code 压缩前缀，把完整 URL 写进了 body 区域，同时又把 idCode 写成了 0x01 或 0x02。读取端会把 idCode 映射成前缀拼在 body 前面，于是出现双前缀。0x00 表示不使用任何前缀，body 必须包含完整协议头。

解决：构造 URI 记录时，检测到 URL 前缀后要把前缀从 body 里摘除再写入。摘除逻辑要放在 StartsWith 判断之后、实际写入之前，并且必须同步把 idCode 改成对应值。建议写完之后立刻调用DecodeUriPayload做一次回读自检，字符串比对不一致就抛异常。

5.3 写卡成功后手机碰标签毫无反应

现象：电脑端 C# 程序报告写入成功，用 NFC 手机去碰标签，手机没有弹出任何内容，甚至提示“不支持此标签”。

原因：写入时只写了 NDEF 报文，没有同步更新 NL（NDEF Length）字段。Type 4 Tag 的数据结构是：CC 区 -> NL（2 字节消息长度）-> NDEF 报文。部分手机读取时会先读 NL 再按长度读报文，如果 NL 还是旧值，读到一半就截断或者直接判定数据无效。

解决：每次写完报文后强制重写 NL 为当前报文长度。这步不能省。代码里我把它放在WriteNdef的末尾，用独立 APDU 完成更新。如果写完 NL 后仍然无效，检查 CC 文件的写保护字节是否被置为只读，个别标签出厂时 NDEF 区写保护是开启的，需要用厂商工具先解锁。

5.4 NDEF 区容量值与实际可写长度不一致

现象：标签标称 1KB，CC 文件里也写着 1KB，但写到约一半时返回写入失败，读回内容发现后半段全是 0。

原因：CC 文件里的容量值是标签可寻址空间，不一定是 NDEF 应用可写区。Type 4 Tag 有多个文件（文件标识 0x0000 是 CC，0x0001 是 NDEF），实际可写长度由文件控制信息决定，不是 CC 里的总容量。有的厂商标签把 NDEF 文件大小设置为 512 字节，尽管 CC 声称有 1024。

解决：写卡前先读取文件控制信息 TLV 里 NDEF 文件的长度字段，按这个值做写入长度上限校验。C# 程序里要有一个GetMaxNdefSize方法，专门解析 TLV，避免在运行时因为越界写导致响应码异常。

5.5 状态码 0x6A82 与 0x6700 的区分

现象：读取时一切正常，写入时返回 0x6A82（文件未找到）或 0x6700（长度错误），换一张卡又正常。

原因：0x6A82 通常是因为 SELECT 指令选错了文件标识，比如读取用 0x0001，写入时不小心选了 0x0002。0x6700 常见于 UPDATE BINARY 的 Le 字段与块大小不匹配，或者 P1/P2 地址加上长度后超出文件边界。

解决：把 APDU 指令封装成带前后断言的方法，统一检查响应码。0x6A82 就要回查 SELECT 流程；0x6700 就要检查块大小计算是否溢出。有一个血泪经验：ACR122U 在 Windows 上通过 PC/SC 发送 APDU 时，响应码是 2 字节，如果代码里resp.Length - 2拿不到数据部分，问题多半出在SCardTransmit的SendPci协议参数上，不是指令本身的问题。

6. 用安卓手机验证写卡结果：一份 1 分钟的验收流程

写卡和解析都完成之后，一定要做一次真机验证。C# 工具写了十几个读卡逻辑，最后真正暴露问题的往往是 NFC 手机而不是读卡器。我的习惯是在写完标签后马上用自己的安卓手机碰一下，不看 C# 程序的返回，纯看手机系统表现。具体验证分三步：先打开手机的设置里“NFC 标签读取”选项，默认不勾选时部分手机会弹“是否读取标签”的确认框，这会干扰判断；然后用系统自带的 NFC 标签读取功能扫一遍，确认文本和 URI 能正常显示；最后用微信扫小程序码链接，确认跳转正常。

这三步对应三类故障：系统能读出文本但 C# 程序读不出来，说明问题在解析层；两端都读不出来，问题在写入层；文本 URI 都正常只有小程序跳转异常，问题在小程序链接本身——注意微信的小程序链接有些带时效性，写入标签前需要先确认链接是否已过期。整个验证流程不会超过一分钟，但能过滤掉 80% 的写卡翻车现场。

如果验证发现 C# 程序读出来的内容和手机读出来的内容不一致，不要急着改代码。先把标签内容用 C# dump 成 HEX 字符串，再用手机端任意一个 NFC 读取 App 也 dump 一份，逐字节对比。两份数据一致说明标签物理写入没问题，差异在解析逻辑；不一致则问题在写入流程。这种方法比对着代码猜快得多，是解决“为何 C# 读和安卓读结果不同”这类玄学问题的捷径。

从那以后，我每次写完 NDEF 读写工具，都会强制在发布前走一遍“写入 -> C# 回读 -> 安卓真机读 -> 字节级对比”的完整链路，任何一个环节不一致就不放行。这个习惯救过我很多次，尤其是批量生产海报标签的时候，第一批写错了能当场拦住，不用等到贴上展架才发现。希望帮到你。

本文还有配套的精品资源，点击获取