简介这份C# IC卡读写实例源码面向具备一定C#基础的开发者聚焦通过PC/SC接口与读卡器硬件交互解决智能卡数据读取与写入的实际问题。资源包共49个文件约1023KB以13个cs源码文件为核心配合9个dll依赖库、5个resx与5个resources资源文件以及sln解决方案、csproj工程、mdb数据库和exe可执行程序构成一套可直接编译运行的完整示例工程。源码围绕ISO 7816协议展开演示了查找读卡器、建立连接、选卡、发送APDU命令、解析响应及断开连接等关键环节并涉及SELECT、READ BINARY、UPDATE BINARY等典型指令的调用方式。目前已有737人学习下载适合希望快速理解智能卡通信流程、掌握PCSC-sharp库用法或需要硬件读写排错思路的开发者参考也可作为企业员工IC卡类项目的起步模板。1. C# IC卡读写实例源码从“能读到卡号”到“能稳定跑在现场”很多人第一次做 C# IC卡读写卡在的不是 C# 语法而是“读卡器到底在跟谁说话”。我见过太多上位机项目界面做得漂漂亮亮结果现场一插 USB 读卡器要么找不到端口要么读出来一堆乱码要么今天能读明天就翻车。这个标题——C# IC卡读写 实例源码硬件读写——说的就是一件很具体的事用 C# 写一个上位机程序通过读卡器硬件把 IC 卡里的数据读出来、写进去并且这套代码能直接拿去改、拿去用。它适合两类人一类是刚接手上位机项目的 C# 开发者需要一份能跑通的硬件读写骨架另一类是做门禁、考勤、消费机、会员系统的工程师想把读卡这一环从“玄学”变成“可控”。核心不是背 API而是搞清楚三件事读卡器走什么协议、卡是什么类型、C# 这边怎么把字节流翻译成业务数据。把这三件事理顺实例源码才有意义否则复制过去也只是换个地方报错。2. 先分清读卡器和卡选错协议代码写得再漂亮也白搭2.1 常见 IC 卡读写硬件与通信方式做 C# IC卡读写之前先确认你手里那台读卡器属于哪一类。市面上常见的硬件读写方案按通信方式大致分四种USB 免驱 HID、USB 转串口虚拟 COM、串口 RS232/RS485、网络 TCP。它们对 C# 代码的影响完全不同。USB 免驱 HID 类读卡器插上电脑后系统识别成键盘或 HID 设备C# 侧往往不需要打开串口而是监听键盘输入或调用厂商 DLL。这种最省事但也最受限因为数据格式被厂商固化了。USB 转串口和原生串口是 C# 上位机里最常见的方案用SerialPort类就能打开波特率、数据位、校验位这些参数必须和读卡器手册一致。网络读卡器则走 TCPC# 用TcpClient或TcpListener收发字节。提示不要凭感觉猜通信方式。先看设备管理器里读卡器显示成什么再看厂商手册里的“通信协议”章节这一步省不得。卡这边也要分清。标题里说的是 IC 卡通常指符合 ISO/IEC 7816 或 ISO/IEC 14443 的卡片。常见的有 M1 卡Mifare Classic、CPU 卡、NFC 标签。M1 卡读写相对简单有扇区和密钥的概念CPU 卡更复杂涉及 APDU 指令。很多“IC卡读写实例源码”之所以跑不起来就是因为源码针对的是 M1 卡而读者手里拿的是 CPU 卡指令集根本不一样。2.2 用 C# 打开串口读卡器的最小可运行骨架假设你手里是一台 USB 转串口的读卡器厂商手册写明波特率 96008 位数据位1 位停止位无校验主动读卡时返回 10 字节数据前 2 字节是帧头最后 1 字节是校验。下面这段代码就是一个最小可运行骨架先保证能打开端口、收到数据。using System; using System.IO.Ports; class IcCardReader { private SerialPort _port; public bool Open(string portName) { _port new SerialPort(portName) { BaudRate 9600, // 必须与读卡器手册一致 DataBits 8, StopBits StopBits.One, Parity Parity.None, ReadTimeout 500, // 读超时避免界面卡死 WriteTimeout 500 }; _port.DataReceived OnDataReceived; _port.Open(); return _port.IsOpen; } private void OnDataReceived(object sender, SerialDataReceivedEventArgs e) { int len _port.BytesToRead; byte[] buffer new byte[len]; _port.Read(buffer, 0, len); // 这里先原样打印确认硬件确实在发数据 Console.WriteLine(BitConverter.ToString(buffer)); } public void Close() { if (_port ! null _port.IsOpen) _port.Close(); } }这段代码的逻辑很直白构造SerialPort时把波特率、数据位、停止位、校验位设成手册值绑定DataReceived事件打开端口。收到数据后先不解析直接以十六进制打印。参数里ReadTimeout和WriteTimeout很关键现场调试时如果读卡器没响应没有超时设置界面就会一直等用户以为死机了。注意DataReceived事件在后台线程触发如果你要更新 WinForm 或 WPF 界面必须用Invoke或Dispatcher切回 UI 线程否则会报跨线程访问异常。2.3 帧解析把字节流变成卡号能收到数据只是第一步接下来要把字节流按协议拆开。假设手册定义帧头固定0x02 0x00第 3 到第 6 字节是卡号小端序第 10 字节是前面 9 字节的异或校验。解析代码可以这样写private byte[] _frameBuffer new byte[10]; private int _frameIndex 0; private void ParseFrame(byte[] data) { foreach (byte b in data) { // 先找帧头再攒满一帧 if (_frameIndex 0 b ! 0x02) continue; _frameBuffer[_frameIndex] b; if (_frameIndex 10) { if (CheckXor(_frameBuffer)) { // 小端序拼卡号 uint cardId (uint)(_frameBuffer[2] | (_frameBuffer[3] 8) | (_frameBuffer[4] 16) | (_frameBuffer[5] 24)); Console.WriteLine($卡号: {cardId}); } _frameIndex 0; // 无论校验是否通过都重置避免卡死 } } } private bool CheckXor(byte[] frame) { byte xor 0; for (int i 0; i 9; i) xor ^ frame[i]; return xor frame[9]; }这里有几个容易翻车的点。第一串口数据不是一帧一帧来的可能一次收到半帧也可能一次收到两帧所以必须用缓冲区攒帧不能假设Read一次就是完整帧。第二帧头判断要放在攒帧之前否则数据错位后永远对不上。第三校验失败也要重置索引不然缓冲区会一直卡在错误状态。参数上_frameBuffer长度必须和协议帧长一致卡号字节序要按手册确认有的厂商用大端序拼出来就是另一个数。3. 硬件读写实例源码从读卡号到写数据把流程跑通3.1 读卡号、读扇区、写扇区的代码分层一份能用的 C# IC卡读写实例源码不应该把所有逻辑塞在一个Form1.cs里。我一般会分成三层通信层负责打开端口、收发字节协议层负责组帧、解帧、校验业务层负责卡号、扇区、密钥这些业务概念。这样换一款读卡器时只需要改通信层和协议层业务层不动。以 M1 卡为例读卡号通常是一条指令读扇区是另一条指令写扇区又是另一条。下面是一个协议层的指令封装示例假设手册定义读卡号指令为0x02 0x10 0x00 0x00 0x12读扇区指令为0x02 0x20 扇区号 密钥类型 0x00 校验。public static class CardCommand { // 读卡号指令固定帧 public static byte[] ReadCardId() { return new byte[] { 0x02, 0x10, 0x00, 0x00, 0x12 }; } // 读扇区sector 0-15keyType 0KeyA 1KeyB public static byte[] ReadSector(byte sector, byte keyType) { byte[] cmd new byte[6]; cmd[0] 0x02; cmd[1] 0x20; cmd[2] sector; cmd[3] keyType; cmd[4] 0x00; cmd[5] ComputeXor(cmd, 5); return cmd; } private static byte ComputeXor(byte[] data, int len) { byte xor 0; for (int i 0; i len; i) xor ^ data[i]; return xor; } }这段代码的价值在于把“指令”和“通信”分开。ReadCardId返回固定帧ReadSector根据扇区和密钥类型动态组帧最后一位校验用异或算出来。参数sector的范围取决于卡片容量M1 卡通常是 0 到 15写错会返回错误码。keyType决定用 KeyA 还是 KeyB 验证默认密钥通常是FF FF FF FF FF FF但现场卡往往改过密钥读不到就要先问清楚。3.2 写数据时的密钥验证与块地址写扇区比读扇区多一步必须先验证密钥再写数据。很多实例源码只贴了写指令没贴验证流程结果读者一跑就返回“密钥错误”。正确的顺序是选卡、验证密钥、写块、断电或复位。下面是一个写块的封装示例。public static byte[] WriteBlock(byte block, byte[] data16) { if (data16.Length ! 16) throw new ArgumentException(M1 卡每块必须 16 字节); byte[] cmd new byte[22]; cmd[0] 0x02; cmd[1] 0x30; // 写块指令 cmd[2] block; // 块地址不是扇区号 Array.Copy(data16, 0, cmd, 3, 16); cmd[21] ComputeXor(cmd, 21); return cmd; }这里最容易踩的坑是“块地址”和“扇区号”混用。M1 卡每个扇区有 4 个块扇区 0 对应块 0 到 3扇区 1 对应块 4 到 7以此类推。如果你把扇区号直接当块地址传进去写的就是错误位置轻则写不进去重则把厂商块写坏。参数data16必须是 16 字节不足要补零超过要截断这个校验不能省。提示写操作之前最好先读一次目标块确认当前内容再决定是否覆盖。现场调试时我习惯把读到的原始十六进制打印出来方便对照。3.3 用状态机管理“选卡—验证—读—写”流程硬件读写不是单次调用而是一个有顺序的流程。如果直接在按钮事件里写一长串Send和Sleep代码会很难维护而且容易因为读卡器响应慢而翻车。我一般用一个简单的状态机来管理空闲、等待选卡、等待验证、等待读、等待写。每个状态收到响应后切换到下一个状态超时就回到空闲。enum CardState { Idle, WaitSelect, WaitAuth, WaitRead, WaitWrite } private CardState _state CardState.Idle; private void OnFrameReceived(byte[] frame) { switch (_state) { case CardState.WaitSelect: if (frame[1] 0x10 frame[2] 0x00) _state CardState.WaitAuth; break; case CardState.WaitAuth: if (frame[1] 0x20 frame[2] 0x00) _state CardState.WaitRead; break; case CardState.WaitRead: // 处理读到的块数据 _state CardState.Idle; break; } }状态机的好处是每个状态只关心自己该等的响应收到不符合预期的帧就忽略或报错不会因为一次乱序数据把整个流程带偏。参数上每个状态最好配一个超时定时器比如 500 毫秒没收到响应就复位到Idle并提示“读卡超时”。现场经验是读卡器偶尔会因为卡片移动太快而丢帧有超时复位比死等强得多。4. 避坑与排查C# IC卡读写现场最常见的 5 个翻车点4.1 现象串口打开成功但一条数据都收不到原因通常有三个一是波特率或校验位和读卡器不一致虽然端口能打开但数据全是乱码或直接丢弃二是读卡器其实走 HID 模式被系统识别成键盘根本不往串口发数据三是DataReceived事件没绑定或者绑定了但Read时BytesToRead为 0。解决方法是先用厂商自带的调试工具确认硬件能正常读卡再用 C# 打开同一个端口把DataReceived里收到的原始字节打印出来。如果厂商工具能读、C# 读不到优先检查波特率和事件绑定。如果厂商工具也读不到那就是硬件或驱动问题跟 C# 代码无关。4.2 现象卡号读出来是反的或者多两位少两位原因是字节序和帧偏移没对齐。有的读卡器返回的卡号是大端序有的是小端序有的帧头占 2 字节有的占 3 字节。手册上写“第 3 到第 6 字节为卡号”但实际抓包发现第 2 字节也是数据。解决方法是不要猜直接抓一帧原始数据对照手册逐字节标注。如果手册和实际不符以实际抓包为准但要在代码注释里写清楚。卡号拼接时先确认字节序再用BitConverter.ToUInt32或手动移位不要两种混用。4.3 现象读扇区返回“密钥错误”但密钥明明是对的原因可能是密钥类型选错KeyA 和 KeyB 是两套独立密钥也可能是卡片已经被其他系统改过密钥默认的FF FF FF FF FF FF已经失效还有可能是验证指令的帧格式不对比如校验位算错。解决方法是先用厂商工具验证密钥确认能读再回到 C#。如果厂商工具也读不到说明密钥确实被改了需要找发卡方要密钥。如果厂商工具能读对比两者发送的指令帧重点看校验位和密钥类型字节。4.4 现象写数据成功返回但重新读出来还是旧数据原因是写的是缓存块没有真正落卡或者写块地址算错写到了别的块。M1 卡的写操作有的读卡器会返回“写成功”但实际需要断电再上电才生效。解决方法是写完以后立刻读同一块对比数据。如果读出来是旧数据检查块地址是否算错扇区和块的换算关系是否搞反。另外有些读卡器写完后需要发送复位指令手册里通常会写别漏掉。4.5 现象程序跑一段时间后串口报“访问被拒绝”或“端口已关闭”原因是串口没有正确释放或者DataReceived事件里抛异常导致端口状态异常。现场长时间运行的程序还可能是 USB 转串口线松动系统重新枚举了设备。解决方法是在Close里先解绑事件再关闭端口异常处理里加try-catch并在捕获到IOException时尝试重新打开端口。如果是 USB 松动建议在代码里加一个定时检测发现端口消失就提示用户检查硬件而不是直接崩溃。5. 进阶技巧用日志和模拟器把硬件读写变成可回归的工程硬件读写最麻烦的地方在于“不可重复”同一张卡今天读得到明天可能因为摆放位置不同就读不到。我的习惯是给每个项目加两层保护一层是原始日志一层是模拟器。原始日志不是简单写个文本文件而是把每次收发的字节、时间戳、当前状态都记下来。这样现场出问题时你可以让用户把日志发回来直接看到底是没收到数据还是收到了但解析错了。下面是一个简单的日志封装private static readonly object _logLock new object(); private void LogFrame(string direction, byte[] data) { string line ${DateTime.Now:HH:mm:ss.fff} {direction} BitConverter.ToString(data); lock (_logLock) { File.AppendAllText(card_reader.log, line Environment.NewLine); } }direction用TX和RX区分发送和接收BitConverter.ToString输出十六进制方便对照手册。lock是为了避免多线程同时写文件导致内容交错。日志文件不要无限增长可以按天切分或者超过一定大小就滚动。模拟器则是把协议层抽出来用一个假的响应源替代真实串口。这样你可以在没有硬件的情况下测试解析逻辑、状态机、异常分支。做法很简单定义一个ICardTransport接口真实串口和模拟器都实现它业务层只依赖接口。public interface ICardTransport { event Actionbyte[] FrameReceived; void Send(byte[] frame); void Open(); void Close(); }真实实现里Send调用SerialPort.Write模拟器里Send根据指令返回预置的响应帧。这样单元测试可以覆盖“帧头错位”“校验失败”“超时”这些现场很难复现的场景。参数上模拟器的响应延迟可以设成 0 到 200 毫秒随机更接近真实硬件。最后说一个我自己的习惯每次接手新的读卡器先不写业务代码而是花半小时用厂商工具抓三帧数据——读卡号、读扇区、写扇区——把原始字节抄在纸上再开始写 C#。这个习惯帮我省掉了无数次“代码没问题但硬件不配合”的扯皮。C# IC卡读写这件事代码只是冰山一角水面下的是协议、硬件和现场环境。把日志和模拟器做扎实后面换卡、换读卡器、换现场你都有后悔药可吃。希望帮到你。本文还有配套的精品资源点击获取