简介这份基于C#的RFID卡识别与读写工程源码面向具备一定.NET基础、希望理解非接触式识别与串口通信的开发者可用于门禁、物流跟踪、商品防伪等场景的入门实践与二次开发。压缩包共29个文件约66KB以cs源码、sln解决方案、csproj项目配置及resx资源文件为主并含编译生成的exe、pdb与缓存文件完整呈现一个可运行的WinForms示例工程结构。已有4664人学习适合参照其组织方式快速定位核心逻辑。内容围绕SerialPort串口连接、事件驱动接收标签数据、按RFID协议解析标签信息以及读写命令下发展开同时包含异常处理与界面交互示例读者可据此梳理C#与硬件设备通信的基本流程学习将硬件交互封装为独立类库以便替换设备的思路并借助现成工程减少搭建调试环境的时间。1. 把一张卡贴上去C# 程序要做的其实不止读仓库闸机旁边蹲着一台读卡器插上 USB 后设备管理器里多出一个 COM 口——基于 C# 的 RFID 卡识别和读写项目起点基本都是这个画面。它要做的事并不复杂卡贴上去程序拿到卡号判断这张卡有没有权限再把一条记录写回卡里的某个扇区。麻烦从来不在读这个动作本身而在串口帧怎么拼、粘包怎么切、超时怎么退、写卡失败怎么不把卡写废。这套代码适合三类人做门禁、考勤、工位管理这类上位机的新手手上已经有一台串口读卡器但只会点厂商 Demo 的开发者以及想把读卡能力嵌进自己业务系统的熟手。下面按我实际拆过的顺序从选型一路讲到能改。2. 技术选型与工程骨架C# 怎么跟一台读卡器对话2.1 三种接入方式先看清你手上是哪一种C# 跟 RFID 读卡器打交道工程上就三条路选错方向后面全是无用功。第一种是串口指令型。读卡器枚举成 COM 口上位机按厂商手册拼十六进制指令帧发下去读卡器回一帧数据。这是最普遍的一类也是这个项目采用的方案。它的好处是控制粒度细寻卡、读块、写块、改密钥、设置蜂鸣器都由你发指令代价是必须自己处理帧头、长度、校验、粘包和超时。第二种是键盘模拟型HID 免驱。读卡器插上就是键盘卡一贴等于敲了一串数字加回车。开发量几乎为零一个 WinForms 文本框加KeyPress事件就完事。但它只能读卡号写不了卡而且必须让窗口保持焦点做成后台服务会翻车。第三种是PC/SC 接口。如果你的读卡器是标准智能卡读写器可以 P/Invokewinscard.dll走SCardTransmit跟卡直接对话。这种方式不依赖厂商私有协议能操作 ISO14443A 卡的 APDU 指令但调用链长、错误码全是十六进制调试成本高适合对接银行、社保这类标准卡场景。判断方法很简单设备管理器里出现的是 COM 口就走第一条出现 HID 键盘设备走第二条出现智能卡读卡器走第三条。三条路也可以并存我一般会把它们抽象成同一个IRfidReader接口后面第 6 章会写到为什么值得这么做。2.2 分层结构与目录不管最后只写一个窗口还是做成服务我建议一上手就按四层拆后面加一块屏、换一台读卡器都不用动业务代码。RfidDemo/ ├── RfidDemo.sln ├── src/ │ ├── RfidDemo.Protocol/ # 协议层帧结构、编解码、校验 │ │ ├── FrameCodec.cs │ │ ├── FrameParser.cs │ │ └── CommandCode.cs │ ├── RfidDemo.Device/ # 设备层串口收发、超时重试、连接管理 │ │ ├── SerialTransport.cs │ │ ├── RfidReader.cs │ │ └── IRfidReader.cs │ ├── RfidDemo.Core/ # 业务层卡号归一化、扇区读写、去重 │ │ ├── CardService.cs │ │ ├── CardRecord.cs │ │ └── M1Layout.cs │ └── RfidDemo.App/ # 宿主层WinForms / WPF / 控制台 │ ├── MainForm.cs │ └── appsettings.json └── tests/ └── RfidDemo.Tests/ # 用模拟传输层跑协议单测 └── FrameParserTests.cs拆成四层最直接的好处是协议层可以脱离硬件跑单元测试喂一段字节数组就能验证粘包逻辑对不对设备层可以换实现串口换成 PC/SC 只是新增一个类业务层只依赖接口写卡的业务规则跟通信细节无关。2.3 运行环境与依赖项目落在 .NET 6 以上的版本就行桌面端 WinForms 和 WPF 都能跑控制台版本方便调试。有一个坑必须提前说System.IO.Ports.SerialPort在 .NET Framework 里是内置的到了 .NET Core / .NET 5 变成了独立的 NuGet 包不装的话编译直接报找不到类型或命名空间名 SerialPort。项目选择说明运行时.NET 6 / 8WinForms 需要-windows目标框架串口System.IO.PortsNuGet 包.NET Core 之后必须显式引用配置Microsoft.Extensions.Configuration.Json把串口号、波特率、密钥放配置文件日志任一结构化日志库收发原始报文一定要落盘排查全靠它部署单文件发布读卡器常装在工控机上别让现场装运行时起步验证不用写界面先在一个控制台程序里把串口打开、发一条寻卡指令、把回来的原始字节Console.WriteLine(BitConverter.ToString(bytes))打出来。这一步通了后面的业务逻辑都是水到渠成这一步不通先别急着怀疑代码去查波特率和接线。提示买读卡器时一定问厂商要指令手册哪怕只有几页 Word。不同厂商的帧头、命令字、校验算法完全不一样没有手册就只能靠串口助手抓包猜那是最费时间的活。3. 通信层拆解串口帧的拼、发、收、拆3.1 串口打开与参数配置串口参数对不上现象就是能打开、能发、一个字都收不回。常见默认值是 9600、8 数据位、无校验、1 停止位但有些模块出厂就是 115200手册上写着。public sealed class SerialTransport : IDisposable { private readonly SerialPort _port; public SerialTransport(string portName, int baudRate) { _port new SerialPort(portName, baudRate, Parity.None, 8, StopBits.One) { ReadTimeout 200, WriteTimeout 200, // 部分 USB 转串口芯片在上电后第一次写会丢首字节 // 先把 DTR/RTS 拉起来再清一次输入缓冲能规避掉大半 DtrEnable true, RtsEnable true }; _port.Open(); _port.DiscardInBuffer(); _port.DiscardOutBuffer(); } public void Write(byte[] buffer) _port.Write(buffer, 0, buffer.Length); public int Read(byte[] buffer, int offset, int count) _port.Read(buffer, offset, count); public void Dispose() { if (_port.IsOpen) _port.Close(); _port.Dispose(); } }ReadTimeout设成 200 毫秒是为了让读线程不至于永远阻塞配合上层的总超时预算才能算出这一帧到底还等不等。DiscardInBuffer在打开之后立刻调一次很关键某些读卡器上电时会主动吐一串状态字节不清掉的话第一次解析就会撞上一个野帧。3.2 帧结构帧头、长度、命令字、数据、校验下面这套帧格式是这类读卡器最常见的形态你的设备手册如果写的是别的字节序改FrameCodec里的常量就行别改调用方。字段长度说明帧头2 字节固定0xAA 0x55用于在字节流里定位长度1 字节命令字 数据的字节数命令字1 字节0x20 寻卡、0x21 读块、0x22 写块、0x23 认证数据N 字节命令参数或返回结果校验1 字节从长度字段到数据末尾逐字节异或帧尾1 字节固定0x0Dpublic static class FrameCodec { public const byte Head0 0xAA; public const byte Head1 0x55; public const byte Tail 0x0D; public static byte[] Build(byte cmd, byte[] data) { // 长度字段 命令字(1) 数据长度 var len (byte)(data.Length 1); var frame new byte[6 data.Length]; frame[0] Head0; frame[1] Head1; frame[2] len; frame[3] cmd; Buffer.BlockCopy(data, 0, frame, 4, data.Length); frame[4 data.Length] Xor(frame, 2, len 1); // 长度 命令字 数据 frame[5 data.Length] Tail; return frame; } private static byte Xor(byte[] buffer, int offset, int count) { byte sum 0; for (int i 0; i count; i) sum ^ buffer[offset i]; return sum; } }校验从长度字段开始算不含帧头这是多数厂商的约定如果你把帧头也算进去读卡器会一直回校验错误。写完之后拿手册上的示例帧对一遍比如厂商文档里写寻卡返回AA 55 03 20 00 23 0D你就用Build(0x20, Array.Emptybyte())生成字节完全一致才算协议层没问题。3.3 接收缓冲与粘包拆包串口是字节流没有消息边界。你发一条指令回来的可能是半帧也可能连着一帧状态上报和半帧应答。把DataReceived事件里读到的字节直接丢给BitConverter.ToInt32是最常见的翻车点。public sealed class FrameParser { private readonly Listbyte _buffer new(256); public IReadOnlyListbyte[] Feed(byte[] chunk) { _buffer.AddRange(chunk); var frames new Listbyte[](); while (true) { // 1. 找到帧头位置前面的野字节直接丢弃 int head FindHead(); if (head 0) { _buffer.Clear(); break; } if (head 0) _buffer.RemoveRange(0, head); // 2. 长度字段还没到等下一批 if (_buffer.Count 3) break; int len _buffer[2]; int total 5 len; // 头2 长1 len 校验1 尾1 if (_buffer.Count total) break; var frame _buffer.GetRange(0, total).ToArray(); _buffer.RemoveRange(0, total); // 3. 校验不过就丢掉这一帧别让脏数据污染后续解析 if (frame[total - 1] ! FrameCodec.Tail) continue; if (frame[total - 2] ! XorOf(frame, 2, len 1)) continue; frames.Add(frame); } return frames; } private int FindHead() { for (int i 0; i _buffer.Count - 1; i) if (_buffer[i] FrameCodec.Head0 _buffer[i 1] FrameCodec.Head1) return i; return -1; } }这段逻辑的价值在于三点找不到帧头就清空缓冲防止野数据越积越多算出整帧长度后不够就break等下一次Feed这就是半包处理校验失败直接continue而不是break让后面的合法帧还能被解析出来。total 5 len这个公式里len已经包含了命令字所以是 2 字节帧头 1 字节长度字段 len 字节负载 1 字节校验 1 字节帧尾。3.4 三条核心指令寻卡、读块、写块有了编解码和拆包设备层就只剩同步等待这一件事。串口是半双工的同一时刻只能有一个指令在飞所以必须加锁再加一个总超时预算超了就抛出去让上层决定是重试还是报错。public sealed class RfidReader : IRfidReader, IDisposable { private readonly SerialTransport _transport; private readonly FrameParser _parser new(); private readonly object _gate new(); public byte[] Execute(byte cmd, byte[] data, int timeoutMs 500) { var request FrameCodec.Build(cmd, data); lock (_gate) { _transport.Write(request); var deadline Environment.TickCount64 timeoutMs; var pool new Queuebyte[](); while (Environment.TickCount64 deadline) { if (pool.Count 0) { var buffer new byte[256]; int n _transport.Read(buffer, 0, buffer.Length); foreach (var f in _parser.Feed(buffer.Take(n).ToArray())) pool.Enqueue(f); continue; } var frame pool.Dequeue(); if (frame[3] ! cmd) continue; // 不是本次请求的应答丢弃 if (frame[4] 0xFF) throw new RfidException(设备返回失败状态); // 失败码 return frame.Skip(4).Take(frame.Length - 6).ToArray(); } } throw new TimeoutException($指令 0x{cmd:X2} 超时未应答); } }几个参数值得说明。timeoutMs一般寻卡给 300500 毫秒读块给 200 毫秒写块要宽一些给 800 毫秒因为写 EEPROM 比读慢。frame[3] ! cmd这个判断不能省——读卡器可能主动上报卡片离开之类的状态帧你如果把它当成应答参数就对不上了。frame[4] 0xFF是典型的失败状态位具体字节以手册为准但一定要有这条判断不然失败会被当成成功业务层拿到一堆空数组还以为是卡有问题。4. 业务层拆解卡号识别、扇区读写与数据落地4.1 卡号归一化与重复刷卡去重读卡器返回的卡号通常是 4 字节原始数据字节序和展示格式各家不同。有的给的是小端你直接BitConverter.ToString出来跟门禁系统里存的号对不上排半天以为是卡坏了其实只是字节反了。public static class CardIdFormatter { public static string Normalize(byte[] raw) { if (raw is null || raw.Length 0) return string.Empty; // 常见做法读卡器给的是小端翻转后转大写十六进制 // 若你的手册明确写了大端把 Reverse 去掉即可 var bigEndian raw.Reverse().ToArray(); return Convert.ToHexString(bigEndian); // 例如 1A2B3C4D } }归一化一定要在最早的地方做只在Normalize一个函数里决定字节序其他地方一律用字符串卡号。血泪经验是如果散落在三四个地方各自BitConverter等你发现某个报表里的号是反的改起来要翻遍整个项目。去重是第二个必须做的事。人把卡贴在读卡器上不会只贴 0.1 秒寻卡轮询又通常是 200 毫秒一次结果就是同一张卡连续触发十几次开门记录。public sealed class CardDebouncer { private readonly Dictionarystring, long _lastSeen new(); private readonly long _cooldownMs; public CardDebouncer(int cooldownMs 2000) _cooldownMs cooldownMs; public bool ShouldRaise(string cardId) { var now Environment.TickCount64; if (_lastSeen.TryGetValue(cardId, out var last) now - last _cooldownMs) return false; _lastSeen[cardId] now; return true; } }冷却时间按场景调门禁 2 秒足够考勤机可能要 5 秒防止员工反复刷生产线上的工序确认反而要短到 500 毫秒。_lastSeen会随卡数量增长长期跑的服务记得加个定期清理或者换成带过期策略的缓存。4.2 扇区结构与密钥验证M1 卡也就是常说的 S50 卡的存储结构是 16 个扇区、每扇区 4 块、每块 16 字节。每个扇区的第 3 块是控制块存密钥 A6 字节、存取控制位4 字节、密钥 B6 字节不能当数据块用。第 0 扇区的第 0 块是厂商块出厂写死只读存着序列号。位置内容能否写扇区 0 块 0厂商块含卡序列号只读扇区 N 块 02用户数据区各 16 字节可写需认证扇区 N 块 3控制块密钥与权限可写改错锁死读写的顺序永远是先认证、再操作。认证失败读块一定返回错误别跳过这步直接读。public bool Authenticate(byte sector, byte[] keyA) { if (keyA.Length ! 6) throw new ArgumentException(密钥必须 6 字节); if (sector 15) throw new ArgumentOutOfRangeException(nameof(sector)); // 数据域1 字节密钥类型 1 字节扇区号 6 字节密钥 var payload new byte[8]; payload[0] 0x60; // 0x60 用密钥 A 认证0x61 用密钥 B payload[1] sector; Buffer.BlockCopy(keyA, 0, payload, 2, 6); var resp Execute(0x23, payload); return resp.Length 0 resp[0] 0x00; // 0x00 表示认证通过 }出厂默认密钥通常是六个0xFF新卡不改密钥等于谁都能写。我的建议是项目里用配置文件或密钥服务下发密钥别硬编码在代码里同一个扇区千万别拿去做两套业务将来要改控制位时互相牵制。4.3 数据的序列化与写入校验卡上每块只有 16 字节别想着塞 JSON。稳妥做法是定义一个定长结构头部放版本和类型中间放有效载荷最后放校验正好填满一块。public readonly record struct CardRecord(byte Version, byte Type, ushort Value, long Timestamp) { public byte[] ToBlock() { var buffer new byte[16]; buffer[0] 0xA5; // 魔数用于判断这块有没有被写过 buffer[1] Version; buffer[2] Type; BitConverter.TryWriteBytes(buffer.AsSpan(3, 2), Value); BitConverter.TryWriteBytes(buffer.AsSpan(5, 8), Timestamp); buffer[13] Crc8(buffer, 0, 13); // 前 13 字节的校验 // 14、15 留空方便以后扩字段而不破坏旧卡的兼容性 return buffer; } public static bool TryParse(byte[] block, out CardRecord record) { /* 反向解析 */ } }写完之后一定要回读比对这是我踩过最贵的坑写指令返回成功但卡实际没写进去原因是认证过期或者块号算错打到了控制块上。回读比对能挡住 99% 的假成功。public WriteResult WriteAndVerify(byte sector, byte blockIndex, CardRecord record) { if (sector 0) return WriteResult.Rejected(扇区 0 为厂商区禁止写入); if (blockIndex 2) return WriteResult.Rejected(块 3 是控制块写入会锁死卡片); var blockAddr (byte)(sector * 4 blockIndex); var payload record.ToBlock(); if (!Authenticate(sector, _keyProvider.GetKey(sector))) return WriteResult.Failed(认证失败); var writeResp Execute(0x22, new[] { blockAddr }.Concat(payload).ToArray(), 800); if (writeResp.Length 0 || writeResp[0] ! 0x00) return WriteResult.Failed(写块指令返回失败); var readBack Execute(0x21, new[] { blockAddr }); var data readBack.Skip(1).Take(16).ToArray(); return data.SequenceEqual(payload) ? WriteResult.Ok() : WriteResult.Failed(回读内容不一致卡片可能已损坏); }blockAddr sector * 4 blockIndex这个换算写成函数别在调用方手算。控制块的位置判断blockIndex 2直接拒绝也要卡在业务层入口因为写坏控制块会让整个扇区永久读不出来卡就废了。4.4 一次完整读卡的事务编排把上面几块拼起来一次读卡的业务流程是认证 → 读块 → 解析 → 校验魔数和 CRC → 抛给上层。整个过程的异常要收敛成一个结果对象别让TimeoutException直接冒到界面上弹框。public CardResult ReadCard(byte sector) { try { if (!Authenticate(sector, _keyProvider.GetKey(sector))) return CardResult.Fail(认证失败密钥可能不匹配); var resp Execute(0x21, new[] { (byte)(sector * 4) }); var block resp.Skip(1).Take(16).ToArray(); if (!CardRecord.TryParse(block, out var record)) return CardResult.Fail(卡片为空或数据格式不识别); return CardResult.Ok(record); } catch (TimeoutException) { return CardResult.Fail(读卡超时请重新贴卡); } catch (RfidException ex) { return CardResult.Fail(ex.Message); } }这里把异常转成结果对象是因为读卡失败在业务上属于常态而不是异常——卡没贴稳、贴早了、贴的是别的频段的卡都会走到这几条分支。上层拿到CardResult后只管弹提示或者记日志UI 线程完全不用关心串口那一层的细节。5. 避坑与常见问题排查5.1 串口能打开寻卡一直超时现象程序启动后SerialPort.Open()成功Execute发出去没报错但每次都在deadline之后抛超时日志里连一个字节的回包都没有。原因九成是波特率或者接线问题剩下一成是发出去的帧本身就错了。波特率对不上时读卡器收到的是一堆乱码它不会回任何东西帧头或者校验算错读卡器会静默丢弃同样不回应答。解决先拿厂商自带的串口调试工具发同样的指令能通说明是代码问题不通就是硬件或参数问题。代码侧把FrameCodec.Build的结果和手册示例逐字节对一遍重点检查校验是不是从长度字段开始算的。另外确认一下读卡器的供电有些模块 USB 供电不足时能枚举出串口但射频部分不工作换一个带独立供电的 HUB 立刻就正常了。5.2 卡贴上去连续触发十几次现象门禁日志里同一个人在两秒内出现十几条记录去重之后仍然偶发重复。原因寻卡是轮询调用200 毫秒一次一张卡贴 3 秒就是 15 次命中。除了轮询本身还有一种情况是卡片离开事件没有正确判断程序把每次寻卡成功都当成新卡。解决上CardDebouncer按卡号做时间窗去重。同时把状态机补完整寻卡成功且卡号与上一次不同才认为是新卡进入连续多次寻不到卡才认为卡片离开。工控机上还有一个隐蔽原因——两个线程同时调Execute锁加在了SendCommand内部但没覆盖到状态判断于是同一张卡被两个线程各记了一次。5.3 读回来的十六进制字符串少了几位现象卡号明明是 8 位十六进制界面上显示出来只有 6 位或者开头多了几个FF。原因BitConverter.ToString输出的是带连字符的原始字节序长度取决于读卡器返回的字节数。有的读卡器固定回 4 字节有的回 5 字节并在首字节放碰撞位标志有的返回小端你按大端展示就会看着少了。解决在协议层把返回的字节长度截清楚用resp[0]当状态位、resp.Skip(1).Take(4)取卡号再统一走Normalize翻转。别用TrimStart(0)之类的字符串魔法去补长度卡号里本来就可能含 0去掉就废了。5.4 写卡返回成功读回来是空的现象写块指令返回0x00日志显示成功但重新读这一块拿到的全是00或者FF。原因块地址算错打到了别的块或者认证用的是上一个扇区的会话。有些读卡器在切换扇区后认证状态会失效你沿用旧认证去写指令被接受但实际没落盘。还有一种情况是写的是块 3 控制块写进去之后整个扇区权限被改掉后续读全是失败。解决写之前重新认证当前扇区写完立刻回读比对不一致就判失败。业务入口直接把sector 0和blockIndex 2拦掉。如果已经写坏了控制块只能找厂商工具或者支持 PWD 认证的复位流程处理普通用户手上没救所以这条防线一定要在代码里前置。5.5 跑一整天之后串口假死、内存缓慢上涨现象早上开机正常下午开始偶尔超时任务管理器里进程内存一路涨。原因DataReceived事件没退订、SerialPort没释放是典型的内存上涨来源假死多半是 USB 转串口芯片在长时间运行后掉线_port.IsOpen仍然是true但写进去的数据没人收。解决读卡器对象必须实现IDisposable并保证_port.Close()和Dispose()被调用事件订阅在关闭时全部退订。假死检测加一个心跳每 30 秒发一条读版本号的指令连续三次超时就重建整个SerialTransport实例。我在工控机上还习惯加一个看门狗服务进程卡死自动重启比人工去现场拔插 USB 靠谱得多。6. 二次开发把读卡能力接进你自己的系统改造的第一步是把硬件抽象掉。定义IRfidReader接口里面只有Inventory()、ReadBlock()、WriteBlock()、Authenticate()四个方法串口实现、PC/SC 实现、模拟实现都挂在这一个接口下。业务层注入接口配置里换一行就能换硬件测试时换成模拟实现连读卡器都不用插。第二步是补一个模拟实现这是我最推荐的技巧。把第 3 章的FrameParser单独拿了出来喂预先构造好的字节数组进去做单元测试能覆盖粘包、半包、校验失败、野数据这四类情况。没有这一步每次改协议都得抱着读卡器试效率极低。public sealed class FakeRfidReader : IRfidReader { private readonly Dictionarybyte, byte[] _blocks new(); private readonly byte _expectedKey 0xFF; public bool Authenticate(byte sector, byte[] keyA) keyA.All(b b _expectedKey); public byte[] ReadBlock(byte blockAddr) _blocks.TryGetValue(blockAddr, out var v) ? v : new byte[16]; public WriteResult WriteBlock(byte blockAddr, byte[] payload) { if (payload.Length ! 16) return WriteResult.Rejected(块长度必须 16 字节); _blocks[blockAddr] payload; return WriteResult.Ok(); } }第三步是上线前的验证清单我一般会按这张表逐项过一遍再交付验证项方法不通过的典型后果断线重连运行中拔掉读卡器再插回服务卡死不恢复密钥错误故意配错密钥读卡界面无提示用户以为卡坏控制块防护尝试写块 3卡片被锁死报废长时间稳定性连续跑 24 小时下午开始随机超时高频刷卡一秒内连刷 5 张不同卡记录丢失或串号落盘日志查日志能否还原一次失败现场问题无法定位最后这一条尤其重要——把每次收发的原始字节按十六进制落盘出问题时直接拿日志回放。我曾经因为没记原始报文在现场对着一台读卡器耗了整整两天最后发现只是厂商固件里寻卡指令少了一个参数。从那以后我每次接入新设备都强制走一遍先抓包落日志、再写协议层的流程宁可多花半天也不要在客户机房熬夜。希望帮到你。本文还有配套的精品资源点击获取
简介这份基于C#的RFID卡识别与读写工程源码面向具备一定.NET基础、希望理解非接触式识别与串口通信的开发者可用于门禁、物流跟踪、商品防伪等场景的入门实践与二次开发。压缩包共29个文件约66KB以cs源码、sln解决方案、csproj项目配置及resx资源文件为主并含编译生成的exe、pdb与缓存文件完整呈现一个可运行的WinForms示例工程结构。已有4664人学习适合参照其组织方式快速定位核心逻辑。内容围绕SerialPort串口连接、事件驱动接收标签数据、按RFID协议解析标签信息以及读写命令下发展开同时包含异常处理与界面交互示例读者可据此梳理C#与硬件设备通信的基本流程学习将硬件交互封装为独立类库以便替换设备的思路并借助现成工程减少搭建调试环境的时间。1. 把一张卡贴上去C# 程序要做的其实不止读仓库闸机旁边蹲着一台读卡器插上 USB 后设备管理器里多出一个 COM 口——基于 C# 的 RFID 卡识别和读写项目起点基本都是这个画面。它要做的事并不复杂卡贴上去程序拿到卡号判断这张卡有没有权限再把一条记录写回卡里的某个扇区。麻烦从来不在读这个动作本身而在串口帧怎么拼、粘包怎么切、超时怎么退、写卡失败怎么不把卡写废。这套代码适合三类人做门禁、考勤、工位管理这类上位机的新手手上已经有一台串口读卡器但只会点厂商 Demo 的开发者以及想把读卡能力嵌进自己业务系统的熟手。下面按我实际拆过的顺序从选型一路讲到能改。2. 技术选型与工程骨架C# 怎么跟一台读卡器对话2.1 三种接入方式先看清你手上是哪一种C# 跟 RFID 读卡器打交道工程上就三条路选错方向后面全是无用功。第一种是串口指令型。读卡器枚举成 COM 口上位机按厂商手册拼十六进制指令帧发下去读卡器回一帧数据。这是最普遍的一类也是这个项目采用的方案。它的好处是控制粒度细寻卡、读块、写块、改密钥、设置蜂鸣器都由你发指令代价是必须自己处理帧头、长度、校验、粘包和超时。第二种是键盘模拟型HID 免驱。读卡器插上就是键盘卡一贴等于敲了一串数字加回车。开发量几乎为零一个 WinForms 文本框加KeyPress事件就完事。但它只能读卡号写不了卡而且必须让窗口保持焦点做成后台服务会翻车。第三种是PC/SC 接口。如果你的读卡器是标准智能卡读写器可以 P/Invokewinscard.dll走SCardTransmit跟卡直接对话。这种方式不依赖厂商私有协议能操作 ISO14443A 卡的 APDU 指令但调用链长、错误码全是十六进制调试成本高适合对接银行、社保这类标准卡场景。判断方法很简单设备管理器里出现的是 COM 口就走第一条出现 HID 键盘设备走第二条出现智能卡读卡器走第三条。三条路也可以并存我一般会把它们抽象成同一个IRfidReader接口后面第 6 章会写到为什么值得这么做。2.2 分层结构与目录不管最后只写一个窗口还是做成服务我建议一上手就按四层拆后面加一块屏、换一台读卡器都不用动业务代码。RfidDemo/ ├── RfidDemo.sln ├── src/ │ ├── RfidDemo.Protocol/ # 协议层帧结构、编解码、校验 │ │ ├── FrameCodec.cs │ │ ├── FrameParser.cs │ │ └── CommandCode.cs │ ├── RfidDemo.Device/ # 设备层串口收发、超时重试、连接管理 │ │ ├── SerialTransport.cs │ │ ├── RfidReader.cs │ │ └── IRfidReader.cs │ ├── RfidDemo.Core/ # 业务层卡号归一化、扇区读写、去重 │ │ ├── CardService.cs │ │ ├── CardRecord.cs │ │ └── M1Layout.cs │ └── RfidDemo.App/ # 宿主层WinForms / WPF / 控制台 │ ├── MainForm.cs │ └── appsettings.json └── tests/ └── RfidDemo.Tests/ # 用模拟传输层跑协议单测 └── FrameParserTests.cs拆成四层最直接的好处是协议层可以脱离硬件跑单元测试喂一段字节数组就能验证粘包逻辑对不对设备层可以换实现串口换成 PC/SC 只是新增一个类业务层只依赖接口写卡的业务规则跟通信细节无关。2.3 运行环境与依赖项目落在 .NET 6 以上的版本就行桌面端 WinForms 和 WPF 都能跑控制台版本方便调试。有一个坑必须提前说System.IO.Ports.SerialPort在 .NET Framework 里是内置的到了 .NET Core / .NET 5 变成了独立的 NuGet 包不装的话编译直接报找不到类型或命名空间名 SerialPort。项目选择说明运行时.NET 6 / 8WinForms 需要-windows目标框架串口System.IO.PortsNuGet 包.NET Core 之后必须显式引用配置Microsoft.Extensions.Configuration.Json把串口号、波特率、密钥放配置文件日志任一结构化日志库收发原始报文一定要落盘排查全靠它部署单文件发布读卡器常装在工控机上别让现场装运行时起步验证不用写界面先在一个控制台程序里把串口打开、发一条寻卡指令、把回来的原始字节Console.WriteLine(BitConverter.ToString(bytes))打出来。这一步通了后面的业务逻辑都是水到渠成这一步不通先别急着怀疑代码去查波特率和接线。提示买读卡器时一定问厂商要指令手册哪怕只有几页 Word。不同厂商的帧头、命令字、校验算法完全不一样没有手册就只能靠串口助手抓包猜那是最费时间的活。3. 通信层拆解串口帧的拼、发、收、拆3.1 串口打开与参数配置串口参数对不上现象就是能打开、能发、一个字都收不回。常见默认值是 9600、8 数据位、无校验、1 停止位但有些模块出厂就是 115200手册上写着。public sealed class SerialTransport : IDisposable { private readonly SerialPort _port; public SerialTransport(string portName, int baudRate) { _port new SerialPort(portName, baudRate, Parity.None, 8, StopBits.One) { ReadTimeout 200, WriteTimeout 200, // 部分 USB 转串口芯片在上电后第一次写会丢首字节 // 先把 DTR/RTS 拉起来再清一次输入缓冲能规避掉大半 DtrEnable true, RtsEnable true }; _port.Open(); _port.DiscardInBuffer(); _port.DiscardOutBuffer(); } public void Write(byte[] buffer) _port.Write(buffer, 0, buffer.Length); public int Read(byte[] buffer, int offset, int count) _port.Read(buffer, offset, count); public void Dispose() { if (_port.IsOpen) _port.Close(); _port.Dispose(); } }ReadTimeout设成 200 毫秒是为了让读线程不至于永远阻塞配合上层的总超时预算才能算出这一帧到底还等不等。DiscardInBuffer在打开之后立刻调一次很关键某些读卡器上电时会主动吐一串状态字节不清掉的话第一次解析就会撞上一个野帧。3.2 帧结构帧头、长度、命令字、数据、校验下面这套帧格式是这类读卡器最常见的形态你的设备手册如果写的是别的字节序改FrameCodec里的常量就行别改调用方。字段长度说明帧头2 字节固定0xAA 0x55用于在字节流里定位长度1 字节命令字 数据的字节数命令字1 字节0x20 寻卡、0x21 读块、0x22 写块、0x23 认证数据N 字节命令参数或返回结果校验1 字节从长度字段到数据末尾逐字节异或帧尾1 字节固定0x0Dpublic static class FrameCodec { public const byte Head0 0xAA; public const byte Head1 0x55; public const byte Tail 0x0D; public static byte[] Build(byte cmd, byte[] data) { // 长度字段 命令字(1) 数据长度 var len (byte)(data.Length 1); var frame new byte[6 data.Length]; frame[0] Head0; frame[1] Head1; frame[2] len; frame[3] cmd; Buffer.BlockCopy(data, 0, frame, 4, data.Length); frame[4 data.Length] Xor(frame, 2, len 1); // 长度 命令字 数据 frame[5 data.Length] Tail; return frame; } private static byte Xor(byte[] buffer, int offset, int count) { byte sum 0; for (int i 0; i count; i) sum ^ buffer[offset i]; return sum; } }校验从长度字段开始算不含帧头这是多数厂商的约定如果你把帧头也算进去读卡器会一直回校验错误。写完之后拿手册上的示例帧对一遍比如厂商文档里写寻卡返回AA 55 03 20 00 23 0D你就用Build(0x20, Array.Emptybyte())生成字节完全一致才算协议层没问题。3.3 接收缓冲与粘包拆包串口是字节流没有消息边界。你发一条指令回来的可能是半帧也可能连着一帧状态上报和半帧应答。把DataReceived事件里读到的字节直接丢给BitConverter.ToInt32是最常见的翻车点。public sealed class FrameParser { private readonly Listbyte _buffer new(256); public IReadOnlyListbyte[] Feed(byte[] chunk) { _buffer.AddRange(chunk); var frames new Listbyte[](); while (true) { // 1. 找到帧头位置前面的野字节直接丢弃 int head FindHead(); if (head 0) { _buffer.Clear(); break; } if (head 0) _buffer.RemoveRange(0, head); // 2. 长度字段还没到等下一批 if (_buffer.Count 3) break; int len _buffer[2]; int total 5 len; // 头2 长1 len 校验1 尾1 if (_buffer.Count total) break; var frame _buffer.GetRange(0, total).ToArray(); _buffer.RemoveRange(0, total); // 3. 校验不过就丢掉这一帧别让脏数据污染后续解析 if (frame[total - 1] ! FrameCodec.Tail) continue; if (frame[total - 2] ! XorOf(frame, 2, len 1)) continue; frames.Add(frame); } return frames; } private int FindHead() { for (int i 0; i _buffer.Count - 1; i) if (_buffer[i] FrameCodec.Head0 _buffer[i 1] FrameCodec.Head1) return i; return -1; } }这段逻辑的价值在于三点找不到帧头就清空缓冲防止野数据越积越多算出整帧长度后不够就break等下一次Feed这就是半包处理校验失败直接continue而不是break让后面的合法帧还能被解析出来。total 5 len这个公式里len已经包含了命令字所以是 2 字节帧头 1 字节长度字段 len 字节负载 1 字节校验 1 字节帧尾。3.4 三条核心指令寻卡、读块、写块有了编解码和拆包设备层就只剩同步等待这一件事。串口是半双工的同一时刻只能有一个指令在飞所以必须加锁再加一个总超时预算超了就抛出去让上层决定是重试还是报错。public sealed class RfidReader : IRfidReader, IDisposable { private readonly SerialTransport _transport; private readonly FrameParser _parser new(); private readonly object _gate new(); public byte[] Execute(byte cmd, byte[] data, int timeoutMs 500) { var request FrameCodec.Build(cmd, data); lock (_gate) { _transport.Write(request); var deadline Environment.TickCount64 timeoutMs; var pool new Queuebyte[](); while (Environment.TickCount64 deadline) { if (pool.Count 0) { var buffer new byte[256]; int n _transport.Read(buffer, 0, buffer.Length); foreach (var f in _parser.Feed(buffer.Take(n).ToArray())) pool.Enqueue(f); continue; } var frame pool.Dequeue(); if (frame[3] ! cmd) continue; // 不是本次请求的应答丢弃 if (frame[4] 0xFF) throw new RfidException(设备返回失败状态); // 失败码 return frame.Skip(4).Take(frame.Length - 6).ToArray(); } } throw new TimeoutException($指令 0x{cmd:X2} 超时未应答); } }几个参数值得说明。timeoutMs一般寻卡给 300500 毫秒读块给 200 毫秒写块要宽一些给 800 毫秒因为写 EEPROM 比读慢。frame[3] ! cmd这个判断不能省——读卡器可能主动上报卡片离开之类的状态帧你如果把它当成应答参数就对不上了。frame[4] 0xFF是典型的失败状态位具体字节以手册为准但一定要有这条判断不然失败会被当成成功业务层拿到一堆空数组还以为是卡有问题。4. 业务层拆解卡号识别、扇区读写与数据落地4.1 卡号归一化与重复刷卡去重读卡器返回的卡号通常是 4 字节原始数据字节序和展示格式各家不同。有的给的是小端你直接BitConverter.ToString出来跟门禁系统里存的号对不上排半天以为是卡坏了其实只是字节反了。public static class CardIdFormatter { public static string Normalize(byte[] raw) { if (raw is null || raw.Length 0) return string.Empty; // 常见做法读卡器给的是小端翻转后转大写十六进制 // 若你的手册明确写了大端把 Reverse 去掉即可 var bigEndian raw.Reverse().ToArray(); return Convert.ToHexString(bigEndian); // 例如 1A2B3C4D } }归一化一定要在最早的地方做只在Normalize一个函数里决定字节序其他地方一律用字符串卡号。血泪经验是如果散落在三四个地方各自BitConverter等你发现某个报表里的号是反的改起来要翻遍整个项目。去重是第二个必须做的事。人把卡贴在读卡器上不会只贴 0.1 秒寻卡轮询又通常是 200 毫秒一次结果就是同一张卡连续触发十几次开门记录。public sealed class CardDebouncer { private readonly Dictionarystring, long _lastSeen new(); private readonly long _cooldownMs; public CardDebouncer(int cooldownMs 2000) _cooldownMs cooldownMs; public bool ShouldRaise(string cardId) { var now Environment.TickCount64; if (_lastSeen.TryGetValue(cardId, out var last) now - last _cooldownMs) return false; _lastSeen[cardId] now; return true; } }冷却时间按场景调门禁 2 秒足够考勤机可能要 5 秒防止员工反复刷生产线上的工序确认反而要短到 500 毫秒。_lastSeen会随卡数量增长长期跑的服务记得加个定期清理或者换成带过期策略的缓存。4.2 扇区结构与密钥验证M1 卡也就是常说的 S50 卡的存储结构是 16 个扇区、每扇区 4 块、每块 16 字节。每个扇区的第 3 块是控制块存密钥 A6 字节、存取控制位4 字节、密钥 B6 字节不能当数据块用。第 0 扇区的第 0 块是厂商块出厂写死只读存着序列号。位置内容能否写扇区 0 块 0厂商块含卡序列号只读扇区 N 块 02用户数据区各 16 字节可写需认证扇区 N 块 3控制块密钥与权限可写改错锁死读写的顺序永远是先认证、再操作。认证失败读块一定返回错误别跳过这步直接读。public bool Authenticate(byte sector, byte[] keyA) { if (keyA.Length ! 6) throw new ArgumentException(密钥必须 6 字节); if (sector 15) throw new ArgumentOutOfRangeException(nameof(sector)); // 数据域1 字节密钥类型 1 字节扇区号 6 字节密钥 var payload new byte[8]; payload[0] 0x60; // 0x60 用密钥 A 认证0x61 用密钥 B payload[1] sector; Buffer.BlockCopy(keyA, 0, payload, 2, 6); var resp Execute(0x23, payload); return resp.Length 0 resp[0] 0x00; // 0x00 表示认证通过 }出厂默认密钥通常是六个0xFF新卡不改密钥等于谁都能写。我的建议是项目里用配置文件或密钥服务下发密钥别硬编码在代码里同一个扇区千万别拿去做两套业务将来要改控制位时互相牵制。4.3 数据的序列化与写入校验卡上每块只有 16 字节别想着塞 JSON。稳妥做法是定义一个定长结构头部放版本和类型中间放有效载荷最后放校验正好填满一块。public readonly record struct CardRecord(byte Version, byte Type, ushort Value, long Timestamp) { public byte[] ToBlock() { var buffer new byte[16]; buffer[0] 0xA5; // 魔数用于判断这块有没有被写过 buffer[1] Version; buffer[2] Type; BitConverter.TryWriteBytes(buffer.AsSpan(3, 2), Value); BitConverter.TryWriteBytes(buffer.AsSpan(5, 8), Timestamp); buffer[13] Crc8(buffer, 0, 13); // 前 13 字节的校验 // 14、15 留空方便以后扩字段而不破坏旧卡的兼容性 return buffer; } public static bool TryParse(byte[] block, out CardRecord record) { /* 反向解析 */ } }写完之后一定要回读比对这是我踩过最贵的坑写指令返回成功但卡实际没写进去原因是认证过期或者块号算错打到了控制块上。回读比对能挡住 99% 的假成功。public WriteResult WriteAndVerify(byte sector, byte blockIndex, CardRecord record) { if (sector 0) return WriteResult.Rejected(扇区 0 为厂商区禁止写入); if (blockIndex 2) return WriteResult.Rejected(块 3 是控制块写入会锁死卡片); var blockAddr (byte)(sector * 4 blockIndex); var payload record.ToBlock(); if (!Authenticate(sector, _keyProvider.GetKey(sector))) return WriteResult.Failed(认证失败); var writeResp Execute(0x22, new[] { blockAddr }.Concat(payload).ToArray(), 800); if (writeResp.Length 0 || writeResp[0] ! 0x00) return WriteResult.Failed(写块指令返回失败); var readBack Execute(0x21, new[] { blockAddr }); var data readBack.Skip(1).Take(16).ToArray(); return data.SequenceEqual(payload) ? WriteResult.Ok() : WriteResult.Failed(回读内容不一致卡片可能已损坏); }blockAddr sector * 4 blockIndex这个换算写成函数别在调用方手算。控制块的位置判断blockIndex 2直接拒绝也要卡在业务层入口因为写坏控制块会让整个扇区永久读不出来卡就废了。4.4 一次完整读卡的事务编排把上面几块拼起来一次读卡的业务流程是认证 → 读块 → 解析 → 校验魔数和 CRC → 抛给上层。整个过程的异常要收敛成一个结果对象别让TimeoutException直接冒到界面上弹框。public CardResult ReadCard(byte sector) { try { if (!Authenticate(sector, _keyProvider.GetKey(sector))) return CardResult.Fail(认证失败密钥可能不匹配); var resp Execute(0x21, new[] { (byte)(sector * 4) }); var block resp.Skip(1).Take(16).ToArray(); if (!CardRecord.TryParse(block, out var record)) return CardResult.Fail(卡片为空或数据格式不识别); return CardResult.Ok(record); } catch (TimeoutException) { return CardResult.Fail(读卡超时请重新贴卡); } catch (RfidException ex) { return CardResult.Fail(ex.Message); } }这里把异常转成结果对象是因为读卡失败在业务上属于常态而不是异常——卡没贴稳、贴早了、贴的是别的频段的卡都会走到这几条分支。上层拿到CardResult后只管弹提示或者记日志UI 线程完全不用关心串口那一层的细节。5. 避坑与常见问题排查5.1 串口能打开寻卡一直超时现象程序启动后SerialPort.Open()成功Execute发出去没报错但每次都在deadline之后抛超时日志里连一个字节的回包都没有。原因九成是波特率或者接线问题剩下一成是发出去的帧本身就错了。波特率对不上时读卡器收到的是一堆乱码它不会回任何东西帧头或者校验算错读卡器会静默丢弃同样不回应答。解决先拿厂商自带的串口调试工具发同样的指令能通说明是代码问题不通就是硬件或参数问题。代码侧把FrameCodec.Build的结果和手册示例逐字节对一遍重点检查校验是不是从长度字段开始算的。另外确认一下读卡器的供电有些模块 USB 供电不足时能枚举出串口但射频部分不工作换一个带独立供电的 HUB 立刻就正常了。5.2 卡贴上去连续触发十几次现象门禁日志里同一个人在两秒内出现十几条记录去重之后仍然偶发重复。原因寻卡是轮询调用200 毫秒一次一张卡贴 3 秒就是 15 次命中。除了轮询本身还有一种情况是卡片离开事件没有正确判断程序把每次寻卡成功都当成新卡。解决上CardDebouncer按卡号做时间窗去重。同时把状态机补完整寻卡成功且卡号与上一次不同才认为是新卡进入连续多次寻不到卡才认为卡片离开。工控机上还有一个隐蔽原因——两个线程同时调Execute锁加在了SendCommand内部但没覆盖到状态判断于是同一张卡被两个线程各记了一次。5.3 读回来的十六进制字符串少了几位现象卡号明明是 8 位十六进制界面上显示出来只有 6 位或者开头多了几个FF。原因BitConverter.ToString输出的是带连字符的原始字节序长度取决于读卡器返回的字节数。有的读卡器固定回 4 字节有的回 5 字节并在首字节放碰撞位标志有的返回小端你按大端展示就会看着少了。解决在协议层把返回的字节长度截清楚用resp[0]当状态位、resp.Skip(1).Take(4)取卡号再统一走Normalize翻转。别用TrimStart(0)之类的字符串魔法去补长度卡号里本来就可能含 0去掉就废了。5.4 写卡返回成功读回来是空的现象写块指令返回0x00日志显示成功但重新读这一块拿到的全是00或者FF。原因块地址算错打到了别的块或者认证用的是上一个扇区的会话。有些读卡器在切换扇区后认证状态会失效你沿用旧认证去写指令被接受但实际没落盘。还有一种情况是写的是块 3 控制块写进去之后整个扇区权限被改掉后续读全是失败。解决写之前重新认证当前扇区写完立刻回读比对不一致就判失败。业务入口直接把sector 0和blockIndex 2拦掉。如果已经写坏了控制块只能找厂商工具或者支持 PWD 认证的复位流程处理普通用户手上没救所以这条防线一定要在代码里前置。5.5 跑一整天之后串口假死、内存缓慢上涨现象早上开机正常下午开始偶尔超时任务管理器里进程内存一路涨。原因DataReceived事件没退订、SerialPort没释放是典型的内存上涨来源假死多半是 USB 转串口芯片在长时间运行后掉线_port.IsOpen仍然是true但写进去的数据没人收。解决读卡器对象必须实现IDisposable并保证_port.Close()和Dispose()被调用事件订阅在关闭时全部退订。假死检测加一个心跳每 30 秒发一条读版本号的指令连续三次超时就重建整个SerialTransport实例。我在工控机上还习惯加一个看门狗服务进程卡死自动重启比人工去现场拔插 USB 靠谱得多。6. 二次开发把读卡能力接进你自己的系统改造的第一步是把硬件抽象掉。定义IRfidReader接口里面只有Inventory()、ReadBlock()、WriteBlock()、Authenticate()四个方法串口实现、PC/SC 实现、模拟实现都挂在这一个接口下。业务层注入接口配置里换一行就能换硬件测试时换成模拟实现连读卡器都不用插。第二步是补一个模拟实现这是我最推荐的技巧。把第 3 章的FrameParser单独拿了出来喂预先构造好的字节数组进去做单元测试能覆盖粘包、半包、校验失败、野数据这四类情况。没有这一步每次改协议都得抱着读卡器试效率极低。public sealed class FakeRfidReader : IRfidReader { private readonly Dictionarybyte, byte[] _blocks new(); private readonly byte _expectedKey 0xFF; public bool Authenticate(byte sector, byte[] keyA) keyA.All(b b _expectedKey); public byte[] ReadBlock(byte blockAddr) _blocks.TryGetValue(blockAddr, out var v) ? v : new byte[16]; public WriteResult WriteBlock(byte blockAddr, byte[] payload) { if (payload.Length ! 16) return WriteResult.Rejected(块长度必须 16 字节); _blocks[blockAddr] payload; return WriteResult.Ok(); } }第三步是上线前的验证清单我一般会按这张表逐项过一遍再交付验证项方法不通过的典型后果断线重连运行中拔掉读卡器再插回服务卡死不恢复密钥错误故意配错密钥读卡界面无提示用户以为卡坏控制块防护尝试写块 3卡片被锁死报废长时间稳定性连续跑 24 小时下午开始随机超时高频刷卡一秒内连刷 5 张不同卡记录丢失或串号落盘日志查日志能否还原一次失败现场问题无法定位最后这一条尤其重要——把每次收发的原始字节按十六进制落盘出问题时直接拿日志回放。我曾经因为没记原始报文在现场对着一台读卡器耗了整整两天最后发现只是厂商固件里寻卡指令少了一个参数。从那以后我每次接入新设备都强制走一遍先抓包落日志、再写协议层的流程宁可多花半天也不要在客户机房熬夜。希望帮到你。本文还有配套的精品资源点击获取
