简介这份压缩包面向希望用 C# 完成 RFID 卡识别与读写实践的开发者聚焦串口通信、事件驱动、协议解析、标签读写与异常处理等关键环节适合作为门禁、物流跟踪、商品防伪等场景的入门示例与课程练习参考。包内共 29 个文件以 6 个 cs 源码文件为核心配合 sln、csproj 等工程配置以及 exe、pdb、resources、resx 等编译与界面资源整体约 66KB体积轻巧便于快速打开、编译和调试。资源以小型桌面工程形态呈现便于对照代码理解从连接设备到处理返回数据的完整链路。已有 4664 人学习说明该主题具备一定关注度。读者可据此了解 C# 与 RFID 阅读器交互的基本结构观察数据接收、解析和读写命令组织方式并借鉴错误处理与界面展示思路也可将硬件交互部分抽离为类库为后续替换设备或扩展业务保留空间。1. 需求先落地为什么RFID卡识别和读写要单独做成一个C#桌面程序某实验室的门禁与耗材领用改造最初买了一套成品一体机卡能刷、门能开但卡号只存在厂商后台里导出的字段固定想按工号绑定、想记录领用明细、想把读写日志接进自己的数据库全被卡住。最后决定自己用 C# 写一个 RFID 卡识别与读写工具既能读卡号做人员绑定也能对 M1 卡做扇区级读写把数据落在自己可控的库里。这套方案适合正在做相关毕设、课程设计的学生也适合需要快速搭一套读写验证工具交付现场的从业者。它不追求做成商用门禁平台追求的是链路清晰、每一条指令都能在代码里找到出处、出问题时能定位到是硬件、协议还是业务层。2. 硬件与协议选型三类卡片、三种链路怎么对上号选型这一步翻车的人最多因为不少人拿到一张卡就开始写代码写到一半才发现这张卡根本不能被写。RFID 项目里读和读写是两种完全不同的需求卡型和读写器的能力必须先在纸面上对齐。2.1 先分清卡型M1、CPU 卡、ID 卡的差异决定功能边界常见的三类卡能力差别很大。卡类型工作频率存储结构能否写典型用途ID 卡EM4100 类125 kHz出厂固化只读序列号不能写考勤打卡、简单门禁M1 卡Mifare Classic 1K/4K13.56 MHz16 扇区 × 4 块 × 16 字节可读写需密钥认证一卡通、储值、领用记录CPU 卡ISO14443A/B13.56 MHz内部 COS 文件系统可写走 APDU 指令金融、社保、高安全场景M1 1K 卡的结构必须记牢后面所有读写代码都是围绕这张表写的区域块号内容第 0 扇区 第 0 块块 0厂商块存 UID、BCC、SAK、ATQA只读第 0 扇区 第 1~2 块块 1、2数据块可读写第 0 扇区 第 3 块块 3控制块KeyA(6) 访问位(4) KeyB(6)第 1~15 扇区每扇区 4 块前 3 块数据第 4 块仍是控制块判断手上是什么卡通常的做法是先发寻卡指令看返回的卡类型字段读不到类型字段的读写器就用 UID 长度辅助判断——4 字节 UID 大概率是 M17 或 10 字节更可能是 CPU 卡。这个判断不是绝对可靠的所以程序里不要把卡型写死留成可配置项。ID 卡最容易被误判因为它压根不响应 13.56 MHz 的寻卡命令表现为读写器一直没反应很多人第一反应是驱动坏了其实是频率不对。提示项目立项时先拿三张实物卡——一张 ID、一张 M1、一张 CPU——挨个测一遍。这一步花二十分钟能省后面两天。2.2 三种通信链路的取舍串口、USB HID、以太网读写器和上位机之间的链路主流就三种。串口RS232 / RS485 / USB 转串口是最通用的选择。指令集是透传的厂商手册写什么就发什么调试的时候拿串口助手就能看到原始字节出问题能一层层剥。代价是你要自己处理粘包、半包、超时重发这部分代码后面第 4 章会完整给出来。RS485 还能一条总线上挂多台读写器用设备地址区分适合多点位部署。USB HID 的最大优势是免驱插上就出一个键盘口卡一贴卡号直接当成键盘输入打进焦点窗口。缺点是它基本只能拿到厂商封装好的卡号扇区级读写做不了而且焦点窗口一丢就收不到数据。只做读卡号的场景用它最省事要做块读写就别选了。以太网TCP Client/Server适合读写器分散、距离远、或者要走现有网络的场合。多一道网络层就多一层要处理的东西心跳保活、断线重连、粘包。它的粘包处理和串口是同一套思路只是底层换成了 Socket。链路开发量能否做块读写多点组网现场调试难度串口中能RS485 可以低串口助手可直读USB HID低一般不能不方便中看不到原始字节以太网中高能方便中需要抓包这个项目的实际选型是串口为主。理由是读写指令需要可视、可复现答辩或者交付时能当场拿串口助手对着日志复现一帧数据说服力比什么都强。2.3 开发环境与依赖.NET 版本、串口库与数据存储框架选 .NET Framework 4.7.2 还是 .NET 6/8取决于部署环境。实验室里还有一批 Windows 7 的老机器那就老老实实 4.7.2新机器一律 .NET 8 WinForms 或 WPF。两个版本的代码 95% 是一样的差别主要在System.IO.Ports的引用方式——.NET Core 之后串口被拆成独立的 NuGet 包需要显式安装。依赖清单控制得很克制越少越好部署!-- 项目文件里的关键 PackageReference -- PackageReference IncludeSystem.IO.Ports Version8.0.0 / PackageReference IncludeMicrosoft.Data.Sqlite Version8.0.0 / PackageReference IncludeNLog Version5.2.8 /串口用官方System.IO.Ports而不用第三方封装是为了降低部署时的 DLL 依赖数据库用 SQLite 而不是装一整套 SQL Server是因为这个场景的数据量在十万级以内SQLite 单文件拷走就能备份答辩现场也不用担心数据库服务没起来。日志用 NLog 按天切分读写指令的原始十六进制尽量都记下来——现场排查时这些字节就是唯一的黑匣子。UI 不引第三方控件库用原生 DataGridView 加 BindingSource 就够。少一个依赖就少一个在别人电脑上跑不起来的理由。3. 总体架构设计四层结构与四个核心模块的职责划分分层的目的是让换一台读写器这件事只影响一个文件而不是把整个工程翻一遍。这个项目按四层切每层职责单一。3.1 四层职责表现层、业务层、设备通信层、数据层表现层只做三件事展示、收集输入、把结果画出来。它不碰串口对象不拼字节数组也不写 SQL。界面上的连接设备读卡写入按钮点击后一律调业务层的方法拿到结果对象再渲染。业务层是整条链路的中枢负责编排收到一帧数据后判断是寻卡响应还是读块响应决定下一步发认证还是发读块读到的字节怎么解析成卡号解析完要不要落库、要不要去重。它依赖设备通信层的接口和数据层的仓储接口但不依赖它们的具体实现。设备通信层封装了串口、帧编解码、超时重试、设备状态对外只暴露发一条命令等一个响应这样的语义。这一层是整个项目最容易出 Bug 的地方也是唯一一个需要跟着读写器型号改的地方。数据层负责 SQLite 的建表、插入、查询和事务。它只管数据不关心数据是从串口来的还是从文件导入的。四层之间的数据流是单向的界面 → 业务 → 通信/数据 → 返回结果对象 → 界面。中间没有反向回调穿透除了卡片到达这个事件。3.2 卡片与指令的抽象把厂商差异关进一个类不同厂商的读写器指令字不一样、校验算法不一样、响应格式也不一样。如果把这些散落在业务代码里换一台设备就是灾难。标准的做法是定义一个接口把所有厂商相关的细节关进实现类。/// summary读写器统一抽象业务层只认这个接口/summary public interface ICardReader : IDisposable { string DeviceName { get; } bool IsOpen { get; } bool Open(); void Close(); /// summary寻卡并返回卡片信息未寻到返回 null/summary CardInfo RequestCard(int timeoutMs 500); /// summary对指定扇区做密钥认证/summary bool AuthSector(byte sector, byte[] key, bool useKeyA); /// summary读一个数据块返回 16 字节失败返回 null/summary byte[] ReadBlock(byte blockAddr, int timeoutMs 500); /// summary写一个数据块内部必须拦截控制块/summary bool WriteBlock(byte blockAddr, byte[] data16); event EventHandlerCardEventArgs CardArrived; } /// summary卡片信息模型UID 统一用大写十六进制字符串/summary public class CardInfo { public string Uid { get; set; } // 例A1B2C3D4 public string CardType { get; set; } // M1 / CPU / ID public int UidLength { get; set; } // 字节数用于卡型辅助判断 public DateTime FirstSeen { get; set; } } public class CardEventArgs : EventArgs { public CardInfo Card { get; set; } }把SerialPortCardReader作为ICardReader的一个实现业务层用构造注入拿接口。这样以后接以太网读写器只需要再写一个TcpCardReader业务层一行不改。这套抽象在答辩时也是个加分项——面试官或者老师最爱问的就是你这套代码换设备怎么办。CardInfo.Uid用字符串而不是字节数组是因为卡号最终要入库、要显示、要跟工号绑定字符串在整个链路里最省心。转成字符串时统一ToString(X2)拼成大写避免大小写混用导致查库查不到。3.3 线程模型DataReceived 不能干重活SerialPort.DataReceived事件是在一个后台线程池线程上触发的这个线程很宝贵。如果在里面做数据库写入、弹窗、或者任何超过几十毫秒的事情串口接收缓冲区就会溢出表现为偶发丢帧而且是那种一天出一次、复现不了的类型。正确的做法是把DataReceived里的工作量压到最小读字节、丢进缓冲区、拼帧、把完整帧塞进队列然后立刻返回。所有解析、落库、界面更新都在另一个消费线程上做。// 生产者串口线程只负责收字节和拼帧 private readonly BlockingCollectionbyte[] _frameQueue new(new ConcurrentQueuebyte[](), 256); private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { var sp (SerialPort)sender; int n sp.BytesToRead; if (n 0) return; var tmp new byte[n]; sp.Read(tmp, 0, n); lock (_rxBuffer) _rxBuffer.AddRange(tmp); // 接收缓冲处理粘包 ExtractFrames(); // 只做拼帧不做业务 } // 消费者独立后台线程串行处理每一帧 private void ConsumeLoop(CancellationToken token) { foreach (var frame in _frameQueue.GetConsumingEnumerable(token)) { try { _dispatcher.Handle(frame); // 业务层根据命令字分发 } catch (Exception ex) { _logger.Error(ex, 帧处理异常: {0}, BitConverter.ToString(frame)); } } }BlockingCollection的容量设成 256是为了防止消费线程卡住时内存无限增长。投递时用TryAdd而不是Add队列满了就记一条日志丢帧宁可丢也不能让串口线程阻塞——串口线程一旦阻塞后面的帧会全部积压在驱动缓冲区里等消费线程恢复时一次性涌进来时间戳全乱。界面更新这一侧消费者线程不能直接改控件属性必须回到 UI 线程// 消费线程里更新界面必须回到 UI 线程 private void OnCardHandled(CardInfo card) { if (this.IsHandleCreated !this.IsDisposed) this.BeginInvoke(new Action(() RenderCard(card))); }用BeginInvoke而不是Invoke是因为Invoke会同步等待 UI 线程处理完才返回如果 UI 线程此刻正忙比如在弹一个模态框消费线程就会挂住队列跟着积压。BeginInvoke是异步投递投完就走。4. 核心链路实现组帧、寻卡、认证读写到落库的完整代码路径这一章把整条链路拆成四段每段给关键代码和参数说明。不同型号读写器的指令字和校验算法不一样这里给的是一种很常见的自定义帧格式接具体设备时按手册替换命令字和校验算法即可骨架是不变的。4.1 帧的组装与校验长度域、命令字与CRC自定义帧格式是55 AA | LEN | CMD | DATA... | CRC_H CRC_L。55 AA是帧头用于在一串字节里定位帧的起点LEN是长度域等于命令字 1 字节 数据域 N 字节 校验 2 字节接收方靠它判断这一帧有多长CMD是命令字后面的数据域长度由命令字决定最后两字节是 CRC16-CCITT初始值 0xFFFF多项式 0x1021。public static class FrameCodec { public const byte Head0 0x55; public const byte Head1 0xAA; /// summary组帧帧头 长度 命令字 数据 CRC16/summary public static byte[] Build(byte cmd, params byte[] data) { int dataLen data?.Length ?? 0; var frame new byte[4 dataLen 2]; frame[0] Head0; frame[1] Head1; frame[2] (byte)(dataLen 3); // 命令字1 数据N 校验2 frame[3] cmd; if (dataLen 0) Buffer.BlockCopy(data, 0, frame, 4, dataLen); // 校验范围从长度域开始算到数据域末尾 ushort crc Crc16(frame, 2, dataLen 2); frame[4 dataLen] (byte)(crc 8); frame[5 dataLen] (byte)(crc 0xFF); return frame; } /// summaryCRC16-CCITT初值 0xFFFF多项式 0x1021/summary public static ushort Crc16(byte[] buf, int offset, int len) { ushort crc 0xFFFF; for (int i offset; i offset len; i) { crc ^ (ushort)(buf[i] 8); for (int b 0; b 8; b) crc (crc 0x8000) ! 0 ? (ushort)((crc 1) ^ 0x1021) : (ushort)(crc 1); } return crc; } }长度域写成dataLen 3而不是dataLen 2是因为它自己不算自己但命令字和两个校验字节都要算进去。这个长度域到底含不含自己的问题是组帧时最典型的错误来源一旦算错接收方永远等不到完整帧。参数说明里之所以强调 CRC 的起点是offset 2是因为帧头两个字节不参与校验从长度域开始才算。接收侧必须处理粘包和半包。做法是维护一个_rxBuffer每次收到新字节就追加然后循环从缓冲区头部找帧头找不到就清空找到但长度不够就等待下一次数据长度够且校验通过就取出这一帧剩下的字节留着继续找。private void ExtractFrames() { while (true) { int idx -1; // 1. 在缓冲区里找帧头 55 AA for (int i 0; i _rxBuffer.Count - 1; i) if (_rxBuffer[i] 0x55 _rxBuffer[i 1] 0xAA) { idx i; break; } if (idx 0) { _rxBuffer.Clear(); return; } // 全是垃圾数据丢掉 if (idx 0) _rxBuffer.RemoveRange(0, idx); // 帧头之前的字节丢掉 if (_rxBuffer.Count 4) return; // 连长度域都没收全 int len _rxBuffer[2]; int total 2 1 len; // 帧头2 长度1 长度域覆盖的内容 if (_rxBuffer.Count total) return; // 半包等下一次 DataReceived var frame _rxBuffer.GetRange(0, total).ToArray(); _rxBuffer.RemoveRange(0, total); // 2. 校验不通过直接丢不抛异常 ushort crc FrameCodec.Crc16(frame, 2, len); if (frame[total - 2] ! (byte)(crc 8) || frame[total - 1] ! (byte)(crc 0xFF)) continue; // 3. 投递给消费线程投不进去也不能阻塞串口线程 if (!_frameQueue.TryAdd(frame)) _logger.Warn(帧队列已满丢弃一帧: {0}, BitConverter.ToString(frame)); } }_rxBuffer的清理逻辑很关键找不到帧头就直接清空说明之前收到的全是不完整的干扰字节留着只会让缓冲区越来越脏。校验失败的帧用continue而不是return因为后面可能还有合法帧在缓冲区里丢一个继续找下一个。4.2 寻卡流程从寻卡命令到拿到 UID寻卡在读写器这一层通常是一步完成的——读写器内部已经做完了防冲突和选卡上位机发一条寻卡命令返回的就是 4 字节 UID 加卡类型。真正的请求-响应时序是发命令 → 等响应 → 超时就重发重发三次还不响应就报故障。/// summary寻卡命令字 0x10数据域为空响应首字节 0x00 表示成功/summary public CardInfo RequestCard(int timeoutMs 500) { var resp SendAndWait(0x10, Array.Emptybyte(), timeoutMs, retry: 3); if (resp null || resp.Length 6 || resp[0] ! 0x00) return null; // 响应格式状态(1) 卡类型(1) UID长度(1) UID(n) byte cardType resp[1]; int uidLen resp[2]; if (resp.Length 3 uidLen) return null; var uid new byte[uidLen]; Buffer.BlockCopy(resp, 3, uid, 0, uidLen); return new CardInfo { Uid BitConverter.ToString(uid).Replace(-, ), // 转成 A1B2C3D4 CardType cardType 0x01 ? M1 : (cardType 0x02 ? CPU : ID), UidLength uidLen, FirstSeen DateTime.Now }; } /// summary发送并等待特定命令字的响应带超时和重试/summary private byte[] SendAndWait(byte cmd, byte[] data, int timeoutMs, int retry 1) { for (int attempt 1; attempt retry; attempt) { var frame FrameCodec.Build(cmd, data); lock (_writeLock) _port.Write(frame, 0, frame.Length); // 写必须串行 var sw Stopwatch.StartNew(); while (sw.ElapsedMilliseconds timeoutMs) { if (_responseSlot.TryTake(out var resp, 50) resp[3] cmd) return resp.Skip(4).ToArray(); // 去掉帧头和命令字 } } _logger.Warn(命令 0x{0:X2} 重试 {1} 次仍未响应, cmd, retry); return null; }几个参数值得解释。timeoutMs给 500 毫秒是因为寻卡本身应该在 100 毫秒内完成超时设长了只会让界面卡顿。retry 3是现场经验值——现场电磁环境复杂的时候单次寻卡失败很正常重试三次能把成功率拉到可接受范围但重试次数再多就会拖慢交互节奏。_writeLock是必须的因为串口写操作不是线程安全的多线程同时写会导致帧字节交错发出去的就是一坨垃圾。_responseSlot是一个单槽的BlockingCollection由消费线程在分发时把响应投进去SendAndWait在这里取。用单槽而不是队列是为了防止历史响应堆积导致后续命令错配——每次发命令前先清空这一槽保证拿到的肯定是这次命令的响应。4.3 密钥认证与块读写扇区结构必须记牢M1 卡读数据前必须先认证。认证的对象是整个扇区不是单个块认证通过后这个扇区下的四个块都解锁了可以直接读。默认密钥是六个 0xFF实际部署时肯定要改。/// summary密钥认证命令字 0x20数据域 扇区号(1) 密钥类型(1) 密钥(6)/summary public bool AuthSector(byte sector, byte[] key, bool useKeyA true) { if (key null || key.Length ! 6) throw new ArgumentException(M1 密钥必须 6 字节); var payload new byte[8]; payload[0] sector; payload[1] (byte)(useKeyA ? 0x60 : 0x61); // 0x60 认证 KeyA0x61 认证 KeyB Buffer.BlockCopy(key, 0, payload, 2, 6); var resp SendAndWait(0x20, payload, 800); return resp ! null resp[0] 0x00; } /// summary读块命令字 0x21数据域 块地址(1)响应 状态(1) 16字节/summary public byte[] ReadBlock(byte blockAddr, int timeoutMs 500) { var resp SendAndWait(0x21, new[] { blockAddr }, timeoutMs); if (resp null || resp.Length 17 || resp[0] ! 0x00) return null; var data new byte[16]; Buffer.BlockCopy(resp, 1, data, 0, 16); return data; } /// summary写块命令字 0x22数据域 块地址(1) 16字节数据/summary public bool WriteBlock(byte blockAddr, byte[] data16) { if (data16 null || data16.Length ! 16) throw new ArgumentException(块数据必须正好 16 字节); if (IsProtectedBlock(blockAddr)) throw new InvalidOperationException($块 {blockAddr} 是厂商块或控制块禁止写入); var payload new byte[17]; payload[0] blockAddr; Buffer.BlockCopy(data16, 0, payload, 1, 16); var resp SendAndWait(0x22, payload, 1500); // 写操作超时给宽一点 return resp ! null resp[0] 0x00; } /// summary1K 卡每扇区 4 块块号 % 4 3 是控制块块 0 是厂商块/summary private static bool IsProtectedBlock(byte blockAddr) blockAddr 0 || (blockAddr % 4) 3;WriteBlock里那行IsProtectedBlock判断是整个项目里最不能省的一行代码原因在第 5 章展开。这里的逻辑是块 0厂商块绝对只读写它会直接失败甚至损坏卡片每扇区最后一块块号 % 4 3是控制块写错访问位会把整个扇区锁死而且是不可逆的。AuthSector里的 0x60/0x61 不是随意的数字是 ISO14443 里 KeyA 和 KeyB 的认证指令码很多读写器直接透传这个值所以这里保留原值最不容易出错。实际读一整个扇区的数据是把认证加四次读块串起来/// summary读取整个扇区的三个数据块返回 48 字节/summary public byte[] ReadSector(int sector, byte[] key) { if (sector 0 || sector 15) throw new ArgumentOutOfRangeException(nameof(sector)); if (!AuthSector((byte)sector, key)) return null; // 认证失败就停别硬读 var result new byte[48]; for (int i 0; i 3; i) // 只读前 3 块跳过控制块 { int blockAddr sector * 4 i; var block ReadBlock((byte)blockAddr); if (block null) return null; Buffer.BlockCopy(block, 0, result, i * 16, 16); } return result; }循环只跑三次是因为第 4 块是控制块读它返回的密钥和访问位信息在业务上没有意义还容易让人误以为可以拿来存数据。4.4 数据落库与去重两张表撑起整个业务数据结构不复杂两张表就够。一张存人员与卡的绑定关系一张存刷卡流水。SQLite 建表语句如下-- 人员与卡绑定表 CREATE TABLE CardHolder ( HolderId INTEGER PRIMARY KEY AUTOINCREMENT, Uid TEXT NOT NULL UNIQUE, -- 卡 UID大写十六进制 HolderName TEXT NOT NULL, DeptCode TEXT, CardType TEXT, -- M1 / CPU / ID Status INTEGER NOT NULL DEFAULT 1, -- 1 正常0 挂失 CreateTime TEXT NOT NULL DEFAULT (datetime(now,localtime)) ); -- 刷卡流水表 CREATE TABLE SwipeLog ( LogId INTEGER PRIMARY KEY AUTOINCREMENT, Uid TEXT NOT NULL, DeviceNo TEXT NOT NULL, -- 读写器编号多点位时区分 SwipeTime TEXT NOT NULL, -- yyyy-MM-dd HH:mm:ss Direction INTEGER, -- 0 进1 出 RawHex TEXT, -- 原始块十六进制排查用 UNIQUE (Uid, DeviceNo, SwipeTime) -- 同卡同机同秒只留一条 );Uid上的UNIQUE约束和流水表的复合唯一索引是防重复入库的第一道防线。但如果只靠数据库约束重复插入会抛异常程序里到处都是 try-catch 很难看所以业务层还要再做一层内存去抖private readonly Dictionarystring, DateTime _lastSwipe new(); private readonly object _lastSwipeLock new(); /// summary同一张卡 2 秒内重复读到视为同一次刷卡/summary private bool IsDuplicate(string uid, string deviceNo, int windowMs 2000) { string key uid | deviceNo; lock (_lastSwipeLock) { if (_lastSwipe.TryGetValue(key, out var last) (DateTime.Now - last).TotalMilliseconds windowMs) return true; _lastSwipe[key] DateTime.Now; return false; } }2 秒这个窗口是根据现场调的卡片放在读写器感应区上不动读写器会连续上报间隔通常在 200 到 500 毫秒人正常刷一下就走两次真实刷卡间隔不会小于 2 秒。窗口设太小挡不住重复上报设太大又会把正常的连续两次刷卡合并掉。这个值做成了参数不同项目可以现场标定。RawHex字段存原始块数据BitConverter.ToString的结果平时没人看但一旦出现卡读出来了但数据不对的问题它就是唯一的证据。多存 32 个字符的成本换来的是排查时不用再跑一趟现场。5. 避坑与排查现场最容易翻车的五个点下面五条都是从实际调试里攒出来的按出现频率从高到低排。5.1 现象能读到卡号但读块一直返回失败原因几乎总是卡型不匹配或者密钥不对。读到卡号说明寻卡链路是通的问题出在后面的认证上。三种可能一是这张卡根本不是 M1是 CPU 卡不响应 M1 的认证指令二是密钥被改过还在用默认的六个 0xFF三是认证的扇区选错了比如数据在第 2 扇区代码去认证第 1 扇区。解决顺序是先把卡的 UID 长度和卡类型字段打到日志里确认是不是 M1再用密钥逐个扇区试认证把能通过的扇区号和密钥类型记下来做一张卡片画像表最后才是读块。密钥这块建议做成界面上的可配置项不要写死在代码里现场改密钥的概率比想象中高得多。5.2 现象串口Open()成功但一帧数据都收不到Open()成功只说明端口被占用了不代表数据能通。最常见的是 TX/RX 接反其次是波特率对不上第三是 USB 转串口线用的是劣质芯片驱动装上了但收发不稳。排查的标准动作是先关掉自己的程序打开串口助手用同样的波特率发一条寻卡命令看有没有字节回来。这一步能立刻把问题切成两半——串口助手也没数据那是硬件或接线的问题串口助手有数据那是自己代码的问题多半是没订阅DataReceived或者ReadTimeout设得太短。提示现场一定带一根 USB 转串口线和一台装着串口助手的笔记本这是我个人认为性价比最高的一项准备。5.3 现象程序跑两三个小时后卡死必须重启这类问题几乎都是线程阻塞。前面说过DataReceived里不能做重活现实里最常见的写法是在事件里直接while循环等响应、或者直接调数据库插入跑一会儿串口接收缓冲区就满了然后整个界面卡住。另一个隐蔽的原因是跨线程更新界面用了Invoke而不是BeginInvoke。UI 线程在等其他事情时Invoke会一直等消费线程挂着队列越积越满最后TryAdd全部失败看起来就是程序不动了。解决方向是彻底改成生产者-消费者模型并且给队列设上限、给每个命令设超时。再补一条串口对象在Close()之前必须先退订事件再Dispose否则可能出现Close()卡住不动的情况。5.4 现象写卡之后这张卡彻底废了读也读不出来这个最严重因为它不可逆。原因是写到了控制块或者写到了厂商块。M1 卡的访问位一旦被写成不规则的值整个扇区就锁死只能报废。防这个问题的做法就一条代码层面加硬拦截WriteBlock里先判断块地址blockAddr 0或blockAddr % 4 3一律抛异常不给任何绕过的口子。别指望操作人员不会输错块号块号是手输的就一定会错。另外写操作要幂等设计先把原始 16 字节读出来改需要改的字节再整体写回不要写半截。写之前把原始数据打印到日志里万一真出事至少知道之前是什么。5.5 现象一张卡刷一次流水表里出现七八条记录读卡器天线的感应区有一定范围卡放上去不动读写器会以几十毫秒的间隔反复上报同一张卡。如果没有去抖每一次上报都入库就变成一堆重复记录。解法是第 4.4 节里的双层防护内存里用Uid|DeviceNo做键记时间戳2 秒内不重复处理数据库层面再用UNIQUE (Uid, DeviceNo, SwipeTime)兜底。两层缺一不可——内存那层挡住 99% 的重复数据库那层防止程序重启后内存状态丢失导致的重复。还有一个小细节去抖的键里必须带设备号。如果是多点位部署同一个人从 A 门走到 B 门两次刷卡间隔可能真的不到 2 秒不带设备号就会把 B 门那次合法记录吞掉。6. 验收与答辩用一张检查表把整条链路验到位交付前我会拿这张表走一遍每一项都要有可复现的操作和明确的判定标准不接受应该没问题。验收项判定标准验证方法串口连接与断开连续开关 20 次不抛异常、不残留句柄点连接/断开按钮循环任务管理器看进程寻卡成功率同一张卡连续寻卡 100 次成功 ≥ 99 次写个小循环脚本自动跑读块正确性读出的数据与写入的一致逐字节比对先写已知数据再读回比对认证失败处理错误密钥返回失败程序不崩、界面提示明确故意用错密钥跑一遍写块保护写块 0 和控制块时被拦截卡片仍可正常读在界面上手输块号 3 试写去抖效果卡片压在感应区 10 秒流水表只增 1 条压住不动数数据库行数长时间稳定性连续运行 4 小时无内存增长、无卡死挂着跑定时读一下进程内存断电恢复拔掉读写器再插回程序能自动重连拔插串口线观察答辩演示的流程建议控制在 5 分钟以内先插上读写器界面上点连接状态栏变绿贴一张 M1 卡屏幕显示 UID 和卡型切到读写页选扇区 1读一次把那 48 字节的十六进制显示出来改其中 4 个字节写回去再读一次证明写入生效最后贴一张 ID 卡界面明确提示当前卡型为 ID 卡不支持扇区读写——这个失败演示往往比成功演示更能说明你对卡型的理解。老师或者评委常问的三个问题提前准备好答案为什么不用成品 SDK——因为要自己控制指令时序和异常处理成品 SDK 出错时是黑匣子M1 卡的安全性够不够——不够密钥可以被暴力破解所以它只适合做内部管理不适合做金融换一台读写器要改多少代码——只改ICardReader的一个实现类业务层零改动。有个血泪教训我一直记着早期版本我把WriteBlock里的块地址保护写成了块号大于 63 就拦截结果有人在界面上输了个 3一次就把测试卡的扇区 0 写死了赔了一张卡不说那批测试数据全没了。从那以后我每次写涉及硬件写操作的代码都强制走一遍先在代码里拦、再在界面里二次确认、最后在日志里留原始数据这三步一步都不省。希望这套结构能帮到你少走一点弯路。本文还有配套的精品资源点击获取
简介这份压缩包面向希望用 C# 完成 RFID 卡识别与读写实践的开发者聚焦串口通信、事件驱动、协议解析、标签读写与异常处理等关键环节适合作为门禁、物流跟踪、商品防伪等场景的入门示例与课程练习参考。包内共 29 个文件以 6 个 cs 源码文件为核心配合 sln、csproj 等工程配置以及 exe、pdb、resources、resx 等编译与界面资源整体约 66KB体积轻巧便于快速打开、编译和调试。资源以小型桌面工程形态呈现便于对照代码理解从连接设备到处理返回数据的完整链路。已有 4664 人学习说明该主题具备一定关注度。读者可据此了解 C# 与 RFID 阅读器交互的基本结构观察数据接收、解析和读写命令组织方式并借鉴错误处理与界面展示思路也可将硬件交互部分抽离为类库为后续替换设备或扩展业务保留空间。1. 需求先落地为什么RFID卡识别和读写要单独做成一个C#桌面程序某实验室的门禁与耗材领用改造最初买了一套成品一体机卡能刷、门能开但卡号只存在厂商后台里导出的字段固定想按工号绑定、想记录领用明细、想把读写日志接进自己的数据库全被卡住。最后决定自己用 C# 写一个 RFID 卡识别与读写工具既能读卡号做人员绑定也能对 M1 卡做扇区级读写把数据落在自己可控的库里。这套方案适合正在做相关毕设、课程设计的学生也适合需要快速搭一套读写验证工具交付现场的从业者。它不追求做成商用门禁平台追求的是链路清晰、每一条指令都能在代码里找到出处、出问题时能定位到是硬件、协议还是业务层。2. 硬件与协议选型三类卡片、三种链路怎么对上号选型这一步翻车的人最多因为不少人拿到一张卡就开始写代码写到一半才发现这张卡根本不能被写。RFID 项目里读和读写是两种完全不同的需求卡型和读写器的能力必须先在纸面上对齐。2.1 先分清卡型M1、CPU 卡、ID 卡的差异决定功能边界常见的三类卡能力差别很大。卡类型工作频率存储结构能否写典型用途ID 卡EM4100 类125 kHz出厂固化只读序列号不能写考勤打卡、简单门禁M1 卡Mifare Classic 1K/4K13.56 MHz16 扇区 × 4 块 × 16 字节可读写需密钥认证一卡通、储值、领用记录CPU 卡ISO14443A/B13.56 MHz内部 COS 文件系统可写走 APDU 指令金融、社保、高安全场景M1 1K 卡的结构必须记牢后面所有读写代码都是围绕这张表写的区域块号内容第 0 扇区 第 0 块块 0厂商块存 UID、BCC、SAK、ATQA只读第 0 扇区 第 1~2 块块 1、2数据块可读写第 0 扇区 第 3 块块 3控制块KeyA(6) 访问位(4) KeyB(6)第 1~15 扇区每扇区 4 块前 3 块数据第 4 块仍是控制块判断手上是什么卡通常的做法是先发寻卡指令看返回的卡类型字段读不到类型字段的读写器就用 UID 长度辅助判断——4 字节 UID 大概率是 M17 或 10 字节更可能是 CPU 卡。这个判断不是绝对可靠的所以程序里不要把卡型写死留成可配置项。ID 卡最容易被误判因为它压根不响应 13.56 MHz 的寻卡命令表现为读写器一直没反应很多人第一反应是驱动坏了其实是频率不对。提示项目立项时先拿三张实物卡——一张 ID、一张 M1、一张 CPU——挨个测一遍。这一步花二十分钟能省后面两天。2.2 三种通信链路的取舍串口、USB HID、以太网读写器和上位机之间的链路主流就三种。串口RS232 / RS485 / USB 转串口是最通用的选择。指令集是透传的厂商手册写什么就发什么调试的时候拿串口助手就能看到原始字节出问题能一层层剥。代价是你要自己处理粘包、半包、超时重发这部分代码后面第 4 章会完整给出来。RS485 还能一条总线上挂多台读写器用设备地址区分适合多点位部署。USB HID 的最大优势是免驱插上就出一个键盘口卡一贴卡号直接当成键盘输入打进焦点窗口。缺点是它基本只能拿到厂商封装好的卡号扇区级读写做不了而且焦点窗口一丢就收不到数据。只做读卡号的场景用它最省事要做块读写就别选了。以太网TCP Client/Server适合读写器分散、距离远、或者要走现有网络的场合。多一道网络层就多一层要处理的东西心跳保活、断线重连、粘包。它的粘包处理和串口是同一套思路只是底层换成了 Socket。链路开发量能否做块读写多点组网现场调试难度串口中能RS485 可以低串口助手可直读USB HID低一般不能不方便中看不到原始字节以太网中高能方便中需要抓包这个项目的实际选型是串口为主。理由是读写指令需要可视、可复现答辩或者交付时能当场拿串口助手对着日志复现一帧数据说服力比什么都强。2.3 开发环境与依赖.NET 版本、串口库与数据存储框架选 .NET Framework 4.7.2 还是 .NET 6/8取决于部署环境。实验室里还有一批 Windows 7 的老机器那就老老实实 4.7.2新机器一律 .NET 8 WinForms 或 WPF。两个版本的代码 95% 是一样的差别主要在System.IO.Ports的引用方式——.NET Core 之后串口被拆成独立的 NuGet 包需要显式安装。依赖清单控制得很克制越少越好部署!-- 项目文件里的关键 PackageReference -- PackageReference IncludeSystem.IO.Ports Version8.0.0 / PackageReference IncludeMicrosoft.Data.Sqlite Version8.0.0 / PackageReference IncludeNLog Version5.2.8 /串口用官方System.IO.Ports而不用第三方封装是为了降低部署时的 DLL 依赖数据库用 SQLite 而不是装一整套 SQL Server是因为这个场景的数据量在十万级以内SQLite 单文件拷走就能备份答辩现场也不用担心数据库服务没起来。日志用 NLog 按天切分读写指令的原始十六进制尽量都记下来——现场排查时这些字节就是唯一的黑匣子。UI 不引第三方控件库用原生 DataGridView 加 BindingSource 就够。少一个依赖就少一个在别人电脑上跑不起来的理由。3. 总体架构设计四层结构与四个核心模块的职责划分分层的目的是让换一台读写器这件事只影响一个文件而不是把整个工程翻一遍。这个项目按四层切每层职责单一。3.1 四层职责表现层、业务层、设备通信层、数据层表现层只做三件事展示、收集输入、把结果画出来。它不碰串口对象不拼字节数组也不写 SQL。界面上的连接设备读卡写入按钮点击后一律调业务层的方法拿到结果对象再渲染。业务层是整条链路的中枢负责编排收到一帧数据后判断是寻卡响应还是读块响应决定下一步发认证还是发读块读到的字节怎么解析成卡号解析完要不要落库、要不要去重。它依赖设备通信层的接口和数据层的仓储接口但不依赖它们的具体实现。设备通信层封装了串口、帧编解码、超时重试、设备状态对外只暴露发一条命令等一个响应这样的语义。这一层是整个项目最容易出 Bug 的地方也是唯一一个需要跟着读写器型号改的地方。数据层负责 SQLite 的建表、插入、查询和事务。它只管数据不关心数据是从串口来的还是从文件导入的。四层之间的数据流是单向的界面 → 业务 → 通信/数据 → 返回结果对象 → 界面。中间没有反向回调穿透除了卡片到达这个事件。3.2 卡片与指令的抽象把厂商差异关进一个类不同厂商的读写器指令字不一样、校验算法不一样、响应格式也不一样。如果把这些散落在业务代码里换一台设备就是灾难。标准的做法是定义一个接口把所有厂商相关的细节关进实现类。/// summary读写器统一抽象业务层只认这个接口/summary public interface ICardReader : IDisposable { string DeviceName { get; } bool IsOpen { get; } bool Open(); void Close(); /// summary寻卡并返回卡片信息未寻到返回 null/summary CardInfo RequestCard(int timeoutMs 500); /// summary对指定扇区做密钥认证/summary bool AuthSector(byte sector, byte[] key, bool useKeyA); /// summary读一个数据块返回 16 字节失败返回 null/summary byte[] ReadBlock(byte blockAddr, int timeoutMs 500); /// summary写一个数据块内部必须拦截控制块/summary bool WriteBlock(byte blockAddr, byte[] data16); event EventHandlerCardEventArgs CardArrived; } /// summary卡片信息模型UID 统一用大写十六进制字符串/summary public class CardInfo { public string Uid { get; set; } // 例A1B2C3D4 public string CardType { get; set; } // M1 / CPU / ID public int UidLength { get; set; } // 字节数用于卡型辅助判断 public DateTime FirstSeen { get; set; } } public class CardEventArgs : EventArgs { public CardInfo Card { get; set; } }把SerialPortCardReader作为ICardReader的一个实现业务层用构造注入拿接口。这样以后接以太网读写器只需要再写一个TcpCardReader业务层一行不改。这套抽象在答辩时也是个加分项——面试官或者老师最爱问的就是你这套代码换设备怎么办。CardInfo.Uid用字符串而不是字节数组是因为卡号最终要入库、要显示、要跟工号绑定字符串在整个链路里最省心。转成字符串时统一ToString(X2)拼成大写避免大小写混用导致查库查不到。3.3 线程模型DataReceived 不能干重活SerialPort.DataReceived事件是在一个后台线程池线程上触发的这个线程很宝贵。如果在里面做数据库写入、弹窗、或者任何超过几十毫秒的事情串口接收缓冲区就会溢出表现为偶发丢帧而且是那种一天出一次、复现不了的类型。正确的做法是把DataReceived里的工作量压到最小读字节、丢进缓冲区、拼帧、把完整帧塞进队列然后立刻返回。所有解析、落库、界面更新都在另一个消费线程上做。// 生产者串口线程只负责收字节和拼帧 private readonly BlockingCollectionbyte[] _frameQueue new(new ConcurrentQueuebyte[](), 256); private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { var sp (SerialPort)sender; int n sp.BytesToRead; if (n 0) return; var tmp new byte[n]; sp.Read(tmp, 0, n); lock (_rxBuffer) _rxBuffer.AddRange(tmp); // 接收缓冲处理粘包 ExtractFrames(); // 只做拼帧不做业务 } // 消费者独立后台线程串行处理每一帧 private void ConsumeLoop(CancellationToken token) { foreach (var frame in _frameQueue.GetConsumingEnumerable(token)) { try { _dispatcher.Handle(frame); // 业务层根据命令字分发 } catch (Exception ex) { _logger.Error(ex, 帧处理异常: {0}, BitConverter.ToString(frame)); } } }BlockingCollection的容量设成 256是为了防止消费线程卡住时内存无限增长。投递时用TryAdd而不是Add队列满了就记一条日志丢帧宁可丢也不能让串口线程阻塞——串口线程一旦阻塞后面的帧会全部积压在驱动缓冲区里等消费线程恢复时一次性涌进来时间戳全乱。界面更新这一侧消费者线程不能直接改控件属性必须回到 UI 线程// 消费线程里更新界面必须回到 UI 线程 private void OnCardHandled(CardInfo card) { if (this.IsHandleCreated !this.IsDisposed) this.BeginInvoke(new Action(() RenderCard(card))); }用BeginInvoke而不是Invoke是因为Invoke会同步等待 UI 线程处理完才返回如果 UI 线程此刻正忙比如在弹一个模态框消费线程就会挂住队列跟着积压。BeginInvoke是异步投递投完就走。4. 核心链路实现组帧、寻卡、认证读写到落库的完整代码路径这一章把整条链路拆成四段每段给关键代码和参数说明。不同型号读写器的指令字和校验算法不一样这里给的是一种很常见的自定义帧格式接具体设备时按手册替换命令字和校验算法即可骨架是不变的。4.1 帧的组装与校验长度域、命令字与CRC自定义帧格式是55 AA | LEN | CMD | DATA... | CRC_H CRC_L。55 AA是帧头用于在一串字节里定位帧的起点LEN是长度域等于命令字 1 字节 数据域 N 字节 校验 2 字节接收方靠它判断这一帧有多长CMD是命令字后面的数据域长度由命令字决定最后两字节是 CRC16-CCITT初始值 0xFFFF多项式 0x1021。public static class FrameCodec { public const byte Head0 0x55; public const byte Head1 0xAA; /// summary组帧帧头 长度 命令字 数据 CRC16/summary public static byte[] Build(byte cmd, params byte[] data) { int dataLen data?.Length ?? 0; var frame new byte[4 dataLen 2]; frame[0] Head0; frame[1] Head1; frame[2] (byte)(dataLen 3); // 命令字1 数据N 校验2 frame[3] cmd; if (dataLen 0) Buffer.BlockCopy(data, 0, frame, 4, dataLen); // 校验范围从长度域开始算到数据域末尾 ushort crc Crc16(frame, 2, dataLen 2); frame[4 dataLen] (byte)(crc 8); frame[5 dataLen] (byte)(crc 0xFF); return frame; } /// summaryCRC16-CCITT初值 0xFFFF多项式 0x1021/summary public static ushort Crc16(byte[] buf, int offset, int len) { ushort crc 0xFFFF; for (int i offset; i offset len; i) { crc ^ (ushort)(buf[i] 8); for (int b 0; b 8; b) crc (crc 0x8000) ! 0 ? (ushort)((crc 1) ^ 0x1021) : (ushort)(crc 1); } return crc; } }长度域写成dataLen 3而不是dataLen 2是因为它自己不算自己但命令字和两个校验字节都要算进去。这个长度域到底含不含自己的问题是组帧时最典型的错误来源一旦算错接收方永远等不到完整帧。参数说明里之所以强调 CRC 的起点是offset 2是因为帧头两个字节不参与校验从长度域开始才算。接收侧必须处理粘包和半包。做法是维护一个_rxBuffer每次收到新字节就追加然后循环从缓冲区头部找帧头找不到就清空找到但长度不够就等待下一次数据长度够且校验通过就取出这一帧剩下的字节留着继续找。private void ExtractFrames() { while (true) { int idx -1; // 1. 在缓冲区里找帧头 55 AA for (int i 0; i _rxBuffer.Count - 1; i) if (_rxBuffer[i] 0x55 _rxBuffer[i 1] 0xAA) { idx i; break; } if (idx 0) { _rxBuffer.Clear(); return; } // 全是垃圾数据丢掉 if (idx 0) _rxBuffer.RemoveRange(0, idx); // 帧头之前的字节丢掉 if (_rxBuffer.Count 4) return; // 连长度域都没收全 int len _rxBuffer[2]; int total 2 1 len; // 帧头2 长度1 长度域覆盖的内容 if (_rxBuffer.Count total) return; // 半包等下一次 DataReceived var frame _rxBuffer.GetRange(0, total).ToArray(); _rxBuffer.RemoveRange(0, total); // 2. 校验不通过直接丢不抛异常 ushort crc FrameCodec.Crc16(frame, 2, len); if (frame[total - 2] ! (byte)(crc 8) || frame[total - 1] ! (byte)(crc 0xFF)) continue; // 3. 投递给消费线程投不进去也不能阻塞串口线程 if (!_frameQueue.TryAdd(frame)) _logger.Warn(帧队列已满丢弃一帧: {0}, BitConverter.ToString(frame)); } }_rxBuffer的清理逻辑很关键找不到帧头就直接清空说明之前收到的全是不完整的干扰字节留着只会让缓冲区越来越脏。校验失败的帧用continue而不是return因为后面可能还有合法帧在缓冲区里丢一个继续找下一个。4.2 寻卡流程从寻卡命令到拿到 UID寻卡在读写器这一层通常是一步完成的——读写器内部已经做完了防冲突和选卡上位机发一条寻卡命令返回的就是 4 字节 UID 加卡类型。真正的请求-响应时序是发命令 → 等响应 → 超时就重发重发三次还不响应就报故障。/// summary寻卡命令字 0x10数据域为空响应首字节 0x00 表示成功/summary public CardInfo RequestCard(int timeoutMs 500) { var resp SendAndWait(0x10, Array.Emptybyte(), timeoutMs, retry: 3); if (resp null || resp.Length 6 || resp[0] ! 0x00) return null; // 响应格式状态(1) 卡类型(1) UID长度(1) UID(n) byte cardType resp[1]; int uidLen resp[2]; if (resp.Length 3 uidLen) return null; var uid new byte[uidLen]; Buffer.BlockCopy(resp, 3, uid, 0, uidLen); return new CardInfo { Uid BitConverter.ToString(uid).Replace(-, ), // 转成 A1B2C3D4 CardType cardType 0x01 ? M1 : (cardType 0x02 ? CPU : ID), UidLength uidLen, FirstSeen DateTime.Now }; } /// summary发送并等待特定命令字的响应带超时和重试/summary private byte[] SendAndWait(byte cmd, byte[] data, int timeoutMs, int retry 1) { for (int attempt 1; attempt retry; attempt) { var frame FrameCodec.Build(cmd, data); lock (_writeLock) _port.Write(frame, 0, frame.Length); // 写必须串行 var sw Stopwatch.StartNew(); while (sw.ElapsedMilliseconds timeoutMs) { if (_responseSlot.TryTake(out var resp, 50) resp[3] cmd) return resp.Skip(4).ToArray(); // 去掉帧头和命令字 } } _logger.Warn(命令 0x{0:X2} 重试 {1} 次仍未响应, cmd, retry); return null; }几个参数值得解释。timeoutMs给 500 毫秒是因为寻卡本身应该在 100 毫秒内完成超时设长了只会让界面卡顿。retry 3是现场经验值——现场电磁环境复杂的时候单次寻卡失败很正常重试三次能把成功率拉到可接受范围但重试次数再多就会拖慢交互节奏。_writeLock是必须的因为串口写操作不是线程安全的多线程同时写会导致帧字节交错发出去的就是一坨垃圾。_responseSlot是一个单槽的BlockingCollection由消费线程在分发时把响应投进去SendAndWait在这里取。用单槽而不是队列是为了防止历史响应堆积导致后续命令错配——每次发命令前先清空这一槽保证拿到的肯定是这次命令的响应。4.3 密钥认证与块读写扇区结构必须记牢M1 卡读数据前必须先认证。认证的对象是整个扇区不是单个块认证通过后这个扇区下的四个块都解锁了可以直接读。默认密钥是六个 0xFF实际部署时肯定要改。/// summary密钥认证命令字 0x20数据域 扇区号(1) 密钥类型(1) 密钥(6)/summary public bool AuthSector(byte sector, byte[] key, bool useKeyA true) { if (key null || key.Length ! 6) throw new ArgumentException(M1 密钥必须 6 字节); var payload new byte[8]; payload[0] sector; payload[1] (byte)(useKeyA ? 0x60 : 0x61); // 0x60 认证 KeyA0x61 认证 KeyB Buffer.BlockCopy(key, 0, payload, 2, 6); var resp SendAndWait(0x20, payload, 800); return resp ! null resp[0] 0x00; } /// summary读块命令字 0x21数据域 块地址(1)响应 状态(1) 16字节/summary public byte[] ReadBlock(byte blockAddr, int timeoutMs 500) { var resp SendAndWait(0x21, new[] { blockAddr }, timeoutMs); if (resp null || resp.Length 17 || resp[0] ! 0x00) return null; var data new byte[16]; Buffer.BlockCopy(resp, 1, data, 0, 16); return data; } /// summary写块命令字 0x22数据域 块地址(1) 16字节数据/summary public bool WriteBlock(byte blockAddr, byte[] data16) { if (data16 null || data16.Length ! 16) throw new ArgumentException(块数据必须正好 16 字节); if (IsProtectedBlock(blockAddr)) throw new InvalidOperationException($块 {blockAddr} 是厂商块或控制块禁止写入); var payload new byte[17]; payload[0] blockAddr; Buffer.BlockCopy(data16, 0, payload, 1, 16); var resp SendAndWait(0x22, payload, 1500); // 写操作超时给宽一点 return resp ! null resp[0] 0x00; } /// summary1K 卡每扇区 4 块块号 % 4 3 是控制块块 0 是厂商块/summary private static bool IsProtectedBlock(byte blockAddr) blockAddr 0 || (blockAddr % 4) 3;WriteBlock里那行IsProtectedBlock判断是整个项目里最不能省的一行代码原因在第 5 章展开。这里的逻辑是块 0厂商块绝对只读写它会直接失败甚至损坏卡片每扇区最后一块块号 % 4 3是控制块写错访问位会把整个扇区锁死而且是不可逆的。AuthSector里的 0x60/0x61 不是随意的数字是 ISO14443 里 KeyA 和 KeyB 的认证指令码很多读写器直接透传这个值所以这里保留原值最不容易出错。实际读一整个扇区的数据是把认证加四次读块串起来/// summary读取整个扇区的三个数据块返回 48 字节/summary public byte[] ReadSector(int sector, byte[] key) { if (sector 0 || sector 15) throw new ArgumentOutOfRangeException(nameof(sector)); if (!AuthSector((byte)sector, key)) return null; // 认证失败就停别硬读 var result new byte[48]; for (int i 0; i 3; i) // 只读前 3 块跳过控制块 { int blockAddr sector * 4 i; var block ReadBlock((byte)blockAddr); if (block null) return null; Buffer.BlockCopy(block, 0, result, i * 16, 16); } return result; }循环只跑三次是因为第 4 块是控制块读它返回的密钥和访问位信息在业务上没有意义还容易让人误以为可以拿来存数据。4.4 数据落库与去重两张表撑起整个业务数据结构不复杂两张表就够。一张存人员与卡的绑定关系一张存刷卡流水。SQLite 建表语句如下-- 人员与卡绑定表 CREATE TABLE CardHolder ( HolderId INTEGER PRIMARY KEY AUTOINCREMENT, Uid TEXT NOT NULL UNIQUE, -- 卡 UID大写十六进制 HolderName TEXT NOT NULL, DeptCode TEXT, CardType TEXT, -- M1 / CPU / ID Status INTEGER NOT NULL DEFAULT 1, -- 1 正常0 挂失 CreateTime TEXT NOT NULL DEFAULT (datetime(now,localtime)) ); -- 刷卡流水表 CREATE TABLE SwipeLog ( LogId INTEGER PRIMARY KEY AUTOINCREMENT, Uid TEXT NOT NULL, DeviceNo TEXT NOT NULL, -- 读写器编号多点位时区分 SwipeTime TEXT NOT NULL, -- yyyy-MM-dd HH:mm:ss Direction INTEGER, -- 0 进1 出 RawHex TEXT, -- 原始块十六进制排查用 UNIQUE (Uid, DeviceNo, SwipeTime) -- 同卡同机同秒只留一条 );Uid上的UNIQUE约束和流水表的复合唯一索引是防重复入库的第一道防线。但如果只靠数据库约束重复插入会抛异常程序里到处都是 try-catch 很难看所以业务层还要再做一层内存去抖private readonly Dictionarystring, DateTime _lastSwipe new(); private readonly object _lastSwipeLock new(); /// summary同一张卡 2 秒内重复读到视为同一次刷卡/summary private bool IsDuplicate(string uid, string deviceNo, int windowMs 2000) { string key uid | deviceNo; lock (_lastSwipeLock) { if (_lastSwipe.TryGetValue(key, out var last) (DateTime.Now - last).TotalMilliseconds windowMs) return true; _lastSwipe[key] DateTime.Now; return false; } }2 秒这个窗口是根据现场调的卡片放在读写器感应区上不动读写器会连续上报间隔通常在 200 到 500 毫秒人正常刷一下就走两次真实刷卡间隔不会小于 2 秒。窗口设太小挡不住重复上报设太大又会把正常的连续两次刷卡合并掉。这个值做成了参数不同项目可以现场标定。RawHex字段存原始块数据BitConverter.ToString的结果平时没人看但一旦出现卡读出来了但数据不对的问题它就是唯一的证据。多存 32 个字符的成本换来的是排查时不用再跑一趟现场。5. 避坑与排查现场最容易翻车的五个点下面五条都是从实际调试里攒出来的按出现频率从高到低排。5.1 现象能读到卡号但读块一直返回失败原因几乎总是卡型不匹配或者密钥不对。读到卡号说明寻卡链路是通的问题出在后面的认证上。三种可能一是这张卡根本不是 M1是 CPU 卡不响应 M1 的认证指令二是密钥被改过还在用默认的六个 0xFF三是认证的扇区选错了比如数据在第 2 扇区代码去认证第 1 扇区。解决顺序是先把卡的 UID 长度和卡类型字段打到日志里确认是不是 M1再用密钥逐个扇区试认证把能通过的扇区号和密钥类型记下来做一张卡片画像表最后才是读块。密钥这块建议做成界面上的可配置项不要写死在代码里现场改密钥的概率比想象中高得多。5.2 现象串口Open()成功但一帧数据都收不到Open()成功只说明端口被占用了不代表数据能通。最常见的是 TX/RX 接反其次是波特率对不上第三是 USB 转串口线用的是劣质芯片驱动装上了但收发不稳。排查的标准动作是先关掉自己的程序打开串口助手用同样的波特率发一条寻卡命令看有没有字节回来。这一步能立刻把问题切成两半——串口助手也没数据那是硬件或接线的问题串口助手有数据那是自己代码的问题多半是没订阅DataReceived或者ReadTimeout设得太短。提示现场一定带一根 USB 转串口线和一台装着串口助手的笔记本这是我个人认为性价比最高的一项准备。5.3 现象程序跑两三个小时后卡死必须重启这类问题几乎都是线程阻塞。前面说过DataReceived里不能做重活现实里最常见的写法是在事件里直接while循环等响应、或者直接调数据库插入跑一会儿串口接收缓冲区就满了然后整个界面卡住。另一个隐蔽的原因是跨线程更新界面用了Invoke而不是BeginInvoke。UI 线程在等其他事情时Invoke会一直等消费线程挂着队列越积越满最后TryAdd全部失败看起来就是程序不动了。解决方向是彻底改成生产者-消费者模型并且给队列设上限、给每个命令设超时。再补一条串口对象在Close()之前必须先退订事件再Dispose否则可能出现Close()卡住不动的情况。5.4 现象写卡之后这张卡彻底废了读也读不出来这个最严重因为它不可逆。原因是写到了控制块或者写到了厂商块。M1 卡的访问位一旦被写成不规则的值整个扇区就锁死只能报废。防这个问题的做法就一条代码层面加硬拦截WriteBlock里先判断块地址blockAddr 0或blockAddr % 4 3一律抛异常不给任何绕过的口子。别指望操作人员不会输错块号块号是手输的就一定会错。另外写操作要幂等设计先把原始 16 字节读出来改需要改的字节再整体写回不要写半截。写之前把原始数据打印到日志里万一真出事至少知道之前是什么。5.5 现象一张卡刷一次流水表里出现七八条记录读卡器天线的感应区有一定范围卡放上去不动读写器会以几十毫秒的间隔反复上报同一张卡。如果没有去抖每一次上报都入库就变成一堆重复记录。解法是第 4.4 节里的双层防护内存里用Uid|DeviceNo做键记时间戳2 秒内不重复处理数据库层面再用UNIQUE (Uid, DeviceNo, SwipeTime)兜底。两层缺一不可——内存那层挡住 99% 的重复数据库那层防止程序重启后内存状态丢失导致的重复。还有一个小细节去抖的键里必须带设备号。如果是多点位部署同一个人从 A 门走到 B 门两次刷卡间隔可能真的不到 2 秒不带设备号就会把 B 门那次合法记录吞掉。6. 验收与答辩用一张检查表把整条链路验到位交付前我会拿这张表走一遍每一项都要有可复现的操作和明确的判定标准不接受应该没问题。验收项判定标准验证方法串口连接与断开连续开关 20 次不抛异常、不残留句柄点连接/断开按钮循环任务管理器看进程寻卡成功率同一张卡连续寻卡 100 次成功 ≥ 99 次写个小循环脚本自动跑读块正确性读出的数据与写入的一致逐字节比对先写已知数据再读回比对认证失败处理错误密钥返回失败程序不崩、界面提示明确故意用错密钥跑一遍写块保护写块 0 和控制块时被拦截卡片仍可正常读在界面上手输块号 3 试写去抖效果卡片压在感应区 10 秒流水表只增 1 条压住不动数数据库行数长时间稳定性连续运行 4 小时无内存增长、无卡死挂着跑定时读一下进程内存断电恢复拔掉读写器再插回程序能自动重连拔插串口线观察答辩演示的流程建议控制在 5 分钟以内先插上读写器界面上点连接状态栏变绿贴一张 M1 卡屏幕显示 UID 和卡型切到读写页选扇区 1读一次把那 48 字节的十六进制显示出来改其中 4 个字节写回去再读一次证明写入生效最后贴一张 ID 卡界面明确提示当前卡型为 ID 卡不支持扇区读写——这个失败演示往往比成功演示更能说明你对卡型的理解。老师或者评委常问的三个问题提前准备好答案为什么不用成品 SDK——因为要自己控制指令时序和异常处理成品 SDK 出错时是黑匣子M1 卡的安全性够不够——不够密钥可以被暴力破解所以它只适合做内部管理不适合做金融换一台读写器要改多少代码——只改ICardReader的一个实现类业务层零改动。有个血泪教训我一直记着早期版本我把WriteBlock里的块地址保护写成了块号大于 63 就拦截结果有人在界面上输了个 3一次就把测试卡的扇区 0 写死了赔了一张卡不说那批测试数据全没了。从那以后我每次写涉及硬件写操作的代码都强制走一遍先在代码里拦、再在界面里二次确认、最后在日志里留原始数据这三步一步都不省。希望这套结构能帮到你少走一点弯路。本文还有配套的精品资源点击获取
