尧图网站建设 
简介这是一份面向C# Winform开发者的Socket通信与JSON序列化综合示例适合初学网络编程或希望掌握前后端数据交互的学员。资源参考博客中的JSON与对象互转思路在Winform界面中完整呈现对象序列化为JSON、JSON反序列化为对象的过程并借助Socket实现数据收发直观展示从对象到网络报文再到目标端还原的链路。压缩包共33个文件约66KB以13个cs源码文件为核心涵盖窗体逻辑、Socket客户端处理、JSON解析辅助类及用户实体定义附带config配置、resx资源、exe可执行程序等文件便于直接运行对比源码与效果。已有1875人学习说明该样例在实际开发中有一定参考价值。通过阅读源码与运行Demo读者可快速理解客户端与服务器之间的通信机制掌握用Json.NET或类似库完成对象转换的常见写法并能将代码迁入自己的项目中复用。 做上位机开发的同行应该都有印象只要涉及设备对接八成绕不开TCP Socket而现在的设备为了调试方便报文几乎清一色用JSON。C# Winform Sockets JSON这个组合说是工控通讯里的“三件套”也不夸张。我前阵子刚做完一个扫码枪实时上报的案子用的就是这套架构。今天我就把源码级别的收发样例完整整理出来配上我在现场踩过的坑和试出来的经验给后面要做类似功能的朋友当个参考。这篇内容适合谁看一个是刚入行写上位机的新人知道Socket收发能跑通但不知道代码到底怎么组织才算稳另一个是已经能写CRUD但一碰网络通讯就心里没底的同学。文章不聊虚的直接说通讯方案怎么选、代码怎么写、坑怎么避看完你能独立写一个可以和设备联调的上位机通讯模块。1. 方案选型为什么是 Socket JSON1.1 设备通讯的主流传法对比实际项目里设备给上位机传数据常见的就那么几条路串口、TCP Socket、HTTP接口。串口的优点是实现简单、抗干扰但速率和距离都受限数据量稍微大一点就容易成为瓶颈HTTP接口赢在标准化可如果设备每秒钟要上报很多次数据每次都有HTTP握手的开销实时性就打了折扣。TCP Socket是长连接建立一次连接后持续双向收发延迟低、实时性好所以工控设备基本都走这个路子。我之前接的扫码枪触发项目扫码枪通过网口接入局域网由上位机主动连它也可以反过来扫到的条码以TCP报文实时推送过来。扫码枪的触发方式有两种一种是模拟键盘输入把焦点放在文本框上利用失去焦点事件去触发后续查询另一种就是这里讲的网口TCP推送。这两种我都试过现场环境里后者明显更稳不依赖界面焦点也不会因为弹窗抢焦点导致漏码。1.2 JSON 比二进制报文强在哪设备通讯的数据格式行业里出现过两种流派一种是自定义二进制协议定长字节、大小端、位运算效率高但排错真要命另一种就是JSON这种文本协议。我选JSON的理由很直接。可读性强抓包之后一眼就能看出内容是否正常不用对着字节数数跨语言互通设备端不管是C、Python还是嵌入式脚本随便一个JSON库都能解析扩展性好协议里加字段不影响旧客户端比二进制报文改一个字节就出问题的情况友好太多。当然JSON也有代价字节流比二进制大解析开销高一些。但在绝大多数上位机应用里每秒几千帧的小报文根本不是瓶颈。真到了性能不够那天再升级成“固定包头长度字段”的协议也来得及业务跑通永远是第一位。2. 核心代码实现搭建一个可用的收发框架2.1 自写 Socket 客户端的连接管理很多人喜欢直接用第三方通讯库但一个示例程序里自写连接管理反而更透明出问题容易排查。关键就三步建立TcpClient、连接目标地址、拿到NetworkStream。下面这段是我常用的连接方法private TcpClient _client; private NetworkStream _stream; private readonly object _sendLock new object(); public bool Connect(string ip, int port, int timeoutMs 3000) { try { _client new TcpClient(); var task _client.ConnectAsync(ip, port); if (!task.Wait(timeoutMs)) { throw new TimeoutException(连接超时); } _stream _client.GetStream(); return _client.Connected; } catch (Exception ex) { MessageBox.Show($连接失败: {ex.Message}); return false; } }这里有个细节容易踩坑TcpClient.Connect是同步阻塞的如果目标IP不可达默认可能卡住几十秒才抛异常。所以我用ConnectAsync配合Wait做超时控制3秒连不上直接报错现场联调体验会舒服很多。发送的时候我加了一个_sendLock对象锁因为数据显示线程、心跳线程、界面手动发送可能会同时在写流NetworkStream的并发写不加锁很容易出现报文交错这个我在实际项目里真切遇到过。2.2 消息模型与 JSON 序列化通讯之前先定义好消息结构。我的样例里用一个统一的JsonMessage类来承载这样序列化规则、字段约定写在了一处不会到处散落。public class JsonMessage { public int Type { get; set; } // 1-心跳 2-数据 3-应答 public string Content { get; set; } // 业务内容 public string Timestamp { get; set; } // 时间戳 }发送的时候先把对象序列化成JSON字符串再转成字节数组写入NetworkStreampublic void SendJson(JsonMessage msg) { string json JsonConvert.SerializeObject(msg); // 注意每条消息末尾追加换行符作为消息边界 json \n; byte[] bytes Encoding.UTF8.GetBytes(json); lock (_sendLock) { _stream.Write(bytes, 0, bytes.Length); _stream.Flush(); } }这里我用的序列化库是Newtonsoft.Json也就是JsonConvert。如果你想用微软官方的System.Text.Json写法也差不多JsonSerializer.Serialize(msg)就行性能还更好。我自己两者都用示例里选Newtonsoft更顺手因为它默认容错性好对字段大小写、缺失字段的处理比较宽容对新手友好。2.3 接收线程与 UI 刷新接收数据必须在独立线程里跑不能占着UI线程。我开了一个专用的接收循环private void BeginReceive() { Task.Run(() { byte[] buffer new byte[4096]; while (_client.Connected) { try { int length _stream.Read(buffer, 0, buffer.Length); if (length 0) break; // 连接断开 OnDataReceived(buffer, length); } catch (Exception ex) { AppendLog(接收异常: ex.Message); break; } } }); }这段代码里有个工控场景很容易犯的错直接在新线程里操作TextBox控件运行时就会飙出“线程间操作无效”的异常。解决办法是跨线程调用控件时先判断InvokeRequired再通过BeginInvoke把操作切回UI线程private void AppendLog(string text) { if (txtLog.InvokeRequired) { txtLog.BeginInvoke(new Action(() AppendLog(text))); return; } txtLog.AppendText(text Environment.NewLine); }这一招看着简单但能解决80%的Winform卡顿和崩溃问题。凡是网络线程要碰控件的地方统一走这个方法界面就不会因为高频率刷新而假死。3. 收发过程中的关键细节拆解3.1 解决粘包拆包问题TCP是字节流协议它本身不知道消息在哪里结束。设备连续发两条JSON可能一次Read就全收到了也可能一条JSON被切成了两半这就是常说的粘包和拆包。如果不处理反序列化必报错。我的解决思路很朴素每条JSON结尾加一个换行符\n把\n当成分隔符。接收端维护一个缓存按行切分读取完整的一行才交给JSON解析private readonly StringBuilder _recvBuffer new StringBuilder(); private void OnDataReceived(byte[] data, int length) { string chunk Encoding.UTF8.GetString(data, 0, length); _recvBuffer.Append(chunk); string all _recvBuffer.ToString(); int index; while ((index all.IndexOf(\n)) 0) { string line all.Substring(0, index).Trim(); if (line.Length 0) { ProcessJsonLine(line); } all all.Substring(index 1); } _recvBuffer.Clear(); _recvBuffer.Append(all); // 残余的不完整数据留到下次继续 }这个方案对JSON格式非常适用因为JSON本身不会包含裸换行符。字符串截取用的就是Substring关键是解析完一条就丢弃一条缓存里只留不完整的数据。现场如果报文很大还可以升级成“固定包头长度”的方式但一般上位机数据帧都小换行分隔已经够用了。3.2 字节编码和字符串转换C#里发送和接收都涉及byte[]和字符串互转核心就是编码必须全程统一。我只用UTF-8不用ASCII和Encoding.Default。原因是很多设备端默认按UTF-8处理文本如果上位机用Encoding.Default去转Windows环境一换就会出问题中文直接变乱码。另一个细节是string在C#里是UTF-16的表现形式byte和char是完全不同的东西别混用。收到字节数组后先用Encoding.UTF8.GetString还原成字符串再交给JSON解析器发送时反过来。如果设备那边对字节序有额外要求比如小端整数、高位在前那就得用BitConverter做专门转换那部分和文本JSON分开处理不要混在一个方法里。3.3 心跳、断线检测与自动重连设备侧可能断电、网线松动、程序崩溃上位机得能及时发现并恢复。我的做法是启动一个System.Windows.Forms.Timer每3秒发一次心跳JSON连续几次没收到应答就认定连接断开进入重连逻辑private int _missHeartbeatCount; private void HeartbeatTimer_Tick(object sender, EventArgs e) { if (!_client.Connected) { TryReconnect(); return; } SendJson(new JsonMessage { Type 1, Content ping }); _missHeartbeatCount; if (_missHeartbeatCount 3) { AppendLog(心跳无响应准备重连); _client.Close(); TryReconnect(); } }收到设备返回的pong时把_missHeartbeatCount归零。重连不能太激进我一般是隔2秒、5秒、10秒递增重试避免设备还没起来就把日志刷爆也避免反复重连对现场网关造成压力。4. 实测排坑那些现场才能遇到的问题4.1 高频异常查阅表现象根因解决办法界面卡死、白屏网络操作跑了UI线程全部使用Task.Run BeginInvokeJSON反序列化失败字段名大小写不一致设置PropertyNameCaseInsensitive或统一命名中文乱码接收端和发送端编码不一致全程统一UTF-8收到一半数据拆包没处理加消息边界按行解析多次发送数据交错多线程同时写流发送加锁窗体拉伸后控件变形未用布局容器多用Dock和TableLayoutPanel表里的最后一行跟Winform窗体缩放有关。很多人在开发机上界面正常换到低分辨率屏幕或者手动缩放窗体控件就跑位了。这不是网络问题但却是Winform上位机被问到最多的坑之一。解法很简单界面布局用Dock配合TableLayoutPanel而不是一堆绝对坐标窗体允许缩放时控件能自适应。如果业务要求固定尺寸就把FormBorderStyle和AutoScaleMode设置好别让它随意拉伸。4.2 一个真实的 JSON 解析翻车记录我在调试数据上报功能时设备明明把数据发过来了上位机却反复报错“Failed to deserialize the JSON body into the target type”。抓了报文才发现设备发来的字段type是小写而我定义的类属性是Type。Newtonsoft.Json默认对属性名大小写不敏感但换成System.Text.Json之后默认区分大小写字段匹配不上就直接反序列化失败。这个问题很常见因为很多设备端的JSON库会动态小写化字段名Java里大写开头的变量转成JSON时也容易变成小写。解决办法有两个要么在反序列化时设置大小写不敏感要么给属性加特性强制映射到小写字段。这个坑写出来是因为现场报错信息非常迷惑不看原始报文根本猜不到是字段大小写的问题。建议大家在排查反序列化问题时第一步永远是先打印原始JSON字符串别盯着异常信息猜。5. 项目改造方向与个人实操体会最后聊几点我做这类通讯模块攒下来的经验。第一个建议是一定要写一个模拟设备端。你在Winform旁边放一个简单的控制台程序监听同一个端口收到JSON后按你设计好的规则回包。现场联调之前先在模拟环境把正常包、异常包、大包、断包全部测一遍能省掉大量和真设备耗在一起的时间。第二个建议是收发JSON的样例要留着当“脚手架”。这个组合的可扩展性很强往后无论是接扫码枪、接仪表、接PLC网关还是对接摄像头SDK识别结果通讯层的代码都能复用你只需要换掉ProcessJsonLine里面的业务处理逻辑就行。第三个建议是不要一上来就迷信第三方TCP组件。自己手写一遍连接、收发、拆包、心跳你对网络通讯的底层机制会有完全不一样的理解。等真的需要高并发、高可靠了再去引入更重的框架也有能力判断它到底适不适合自己的场景。踩过坑才知道坑长什么样这句话放在Socket开发里再合适不过。本文还有配套的精品资源点击获取 C# Winform上位机Socket通讯实战：JSON收发与踩坑总结
简介这是一份面向C# Winform开发者的Socket通信与JSON序列化综合示例适合初学网络编程或希望掌握前后端数据交互的学员。资源参考博客中的JSON与对象互转思路在Winform界面中完整呈现对象序列化为JSON、JSON反序列化为对象的过程并借助Socket实现数据收发直观展示从对象到网络报文再到目标端还原的链路。压缩包共33个文件约66KB以13个cs源码文件为核心涵盖窗体逻辑、Socket客户端处理、JSON解析辅助类及用户实体定义附带config配置、resx资源、exe可执行程序等文件便于直接运行对比源码与效果。已有1875人学习说明该样例在实际开发中有一定参考价值。通过阅读源码与运行Demo读者可快速理解客户端与服务器之间的通信机制掌握用Json.NET或类似库完成对象转换的常见写法并能将代码迁入自己的项目中复用。 做上位机开发的同行应该都有印象只要涉及设备对接八成绕不开TCP Socket而现在的设备为了调试方便报文几乎清一色用JSON。C# Winform Sockets JSON这个组合说是工控通讯里的“三件套”也不夸张。我前阵子刚做完一个扫码枪实时上报的案子用的就是这套架构。今天我就把源码级别的收发样例完整整理出来配上我在现场踩过的坑和试出来的经验给后面要做类似功能的朋友当个参考。这篇内容适合谁看一个是刚入行写上位机的新人知道Socket收发能跑通但不知道代码到底怎么组织才算稳另一个是已经能写CRUD但一碰网络通讯就心里没底的同学。文章不聊虚的直接说通讯方案怎么选、代码怎么写、坑怎么避看完你能独立写一个可以和设备联调的上位机通讯模块。1. 方案选型为什么是 Socket JSON1.1 设备通讯的主流传法对比实际项目里设备给上位机传数据常见的就那么几条路串口、TCP Socket、HTTP接口。串口的优点是实现简单、抗干扰但速率和距离都受限数据量稍微大一点就容易成为瓶颈HTTP接口赢在标准化可如果设备每秒钟要上报很多次数据每次都有HTTP握手的开销实时性就打了折扣。TCP Socket是长连接建立一次连接后持续双向收发延迟低、实时性好所以工控设备基本都走这个路子。我之前接的扫码枪触发项目扫码枪通过网口接入局域网由上位机主动连它也可以反过来扫到的条码以TCP报文实时推送过来。扫码枪的触发方式有两种一种是模拟键盘输入把焦点放在文本框上利用失去焦点事件去触发后续查询另一种就是这里讲的网口TCP推送。这两种我都试过现场环境里后者明显更稳不依赖界面焦点也不会因为弹窗抢焦点导致漏码。1.2 JSON 比二进制报文强在哪设备通讯的数据格式行业里出现过两种流派一种是自定义二进制协议定长字节、大小端、位运算效率高但排错真要命另一种就是JSON这种文本协议。我选JSON的理由很直接。可读性强抓包之后一眼就能看出内容是否正常不用对着字节数数跨语言互通设备端不管是C、Python还是嵌入式脚本随便一个JSON库都能解析扩展性好协议里加字段不影响旧客户端比二进制报文改一个字节就出问题的情况友好太多。当然JSON也有代价字节流比二进制大解析开销高一些。但在绝大多数上位机应用里每秒几千帧的小报文根本不是瓶颈。真到了性能不够那天再升级成“固定包头长度字段”的协议也来得及业务跑通永远是第一位。2. 核心代码实现搭建一个可用的收发框架2.1 自写 Socket 客户端的连接管理很多人喜欢直接用第三方通讯库但一个示例程序里自写连接管理反而更透明出问题容易排查。关键就三步建立TcpClient、连接目标地址、拿到NetworkStream。下面这段是我常用的连接方法private TcpClient _client; private NetworkStream _stream; private readonly object _sendLock new object(); public bool Connect(string ip, int port, int timeoutMs 3000) { try { _client new TcpClient(); var task _client.ConnectAsync(ip, port); if (!task.Wait(timeoutMs)) { throw new TimeoutException(连接超时); } _stream _client.GetStream(); return _client.Connected; } catch (Exception ex) { MessageBox.Show($连接失败: {ex.Message}); return false; } }这里有个细节容易踩坑TcpClient.Connect是同步阻塞的如果目标IP不可达默认可能卡住几十秒才抛异常。所以我用ConnectAsync配合Wait做超时控制3秒连不上直接报错现场联调体验会舒服很多。发送的时候我加了一个_sendLock对象锁因为数据显示线程、心跳线程、界面手动发送可能会同时在写流NetworkStream的并发写不加锁很容易出现报文交错这个我在实际项目里真切遇到过。2.2 消息模型与 JSON 序列化通讯之前先定义好消息结构。我的样例里用一个统一的JsonMessage类来承载这样序列化规则、字段约定写在了一处不会到处散落。public class JsonMessage { public int Type { get; set; } // 1-心跳 2-数据 3-应答 public string Content { get; set; } // 业务内容 public string Timestamp { get; set; } // 时间戳 }发送的时候先把对象序列化成JSON字符串再转成字节数组写入NetworkStreampublic void SendJson(JsonMessage msg) { string json JsonConvert.SerializeObject(msg); // 注意每条消息末尾追加换行符作为消息边界 json \n; byte[] bytes Encoding.UTF8.GetBytes(json); lock (_sendLock) { _stream.Write(bytes, 0, bytes.Length); _stream.Flush(); } }这里我用的序列化库是Newtonsoft.Json也就是JsonConvert。如果你想用微软官方的System.Text.Json写法也差不多JsonSerializer.Serialize(msg)就行性能还更好。我自己两者都用示例里选Newtonsoft更顺手因为它默认容错性好对字段大小写、缺失字段的处理比较宽容对新手友好。2.3 接收线程与 UI 刷新接收数据必须在独立线程里跑不能占着UI线程。我开了一个专用的接收循环private void BeginReceive() { Task.Run(() { byte[] buffer new byte[4096]; while (_client.Connected) { try { int length _stream.Read(buffer, 0, buffer.Length); if (length 0) break; // 连接断开 OnDataReceived(buffer, length); } catch (Exception ex) { AppendLog(接收异常: ex.Message); break; } } }); }这段代码里有个工控场景很容易犯的错直接在新线程里操作TextBox控件运行时就会飙出“线程间操作无效”的异常。解决办法是跨线程调用控件时先判断InvokeRequired再通过BeginInvoke把操作切回UI线程private void AppendLog(string text) { if (txtLog.InvokeRequired) { txtLog.BeginInvoke(new Action(() AppendLog(text))); return; } txtLog.AppendText(text Environment.NewLine); }这一招看着简单但能解决80%的Winform卡顿和崩溃问题。凡是网络线程要碰控件的地方统一走这个方法界面就不会因为高频率刷新而假死。3. 收发过程中的关键细节拆解3.1 解决粘包拆包问题TCP是字节流协议它本身不知道消息在哪里结束。设备连续发两条JSON可能一次Read就全收到了也可能一条JSON被切成了两半这就是常说的粘包和拆包。如果不处理反序列化必报错。我的解决思路很朴素每条JSON结尾加一个换行符\n把\n当成分隔符。接收端维护一个缓存按行切分读取完整的一行才交给JSON解析private readonly StringBuilder _recvBuffer new StringBuilder(); private void OnDataReceived(byte[] data, int length) { string chunk Encoding.UTF8.GetString(data, 0, length); _recvBuffer.Append(chunk); string all _recvBuffer.ToString(); int index; while ((index all.IndexOf(\n)) 0) { string line all.Substring(0, index).Trim(); if (line.Length 0) { ProcessJsonLine(line); } all all.Substring(index 1); } _recvBuffer.Clear(); _recvBuffer.Append(all); // 残余的不完整数据留到下次继续 }这个方案对JSON格式非常适用因为JSON本身不会包含裸换行符。字符串截取用的就是Substring关键是解析完一条就丢弃一条缓存里只留不完整的数据。现场如果报文很大还可以升级成“固定包头长度”的方式但一般上位机数据帧都小换行分隔已经够用了。3.2 字节编码和字符串转换C#里发送和接收都涉及byte[]和字符串互转核心就是编码必须全程统一。我只用UTF-8不用ASCII和Encoding.Default。原因是很多设备端默认按UTF-8处理文本如果上位机用Encoding.Default去转Windows环境一换就会出问题中文直接变乱码。另一个细节是string在C#里是UTF-16的表现形式byte和char是完全不同的东西别混用。收到字节数组后先用Encoding.UTF8.GetString还原成字符串再交给JSON解析器发送时反过来。如果设备那边对字节序有额外要求比如小端整数、高位在前那就得用BitConverter做专门转换那部分和文本JSON分开处理不要混在一个方法里。3.3 心跳、断线检测与自动重连设备侧可能断电、网线松动、程序崩溃上位机得能及时发现并恢复。我的做法是启动一个System.Windows.Forms.Timer每3秒发一次心跳JSON连续几次没收到应答就认定连接断开进入重连逻辑private int _missHeartbeatCount; private void HeartbeatTimer_Tick(object sender, EventArgs e) { if (!_client.Connected) { TryReconnect(); return; } SendJson(new JsonMessage { Type 1, Content ping }); _missHeartbeatCount; if (_missHeartbeatCount 3) { AppendLog(心跳无响应准备重连); _client.Close(); TryReconnect(); } }收到设备返回的pong时把_missHeartbeatCount归零。重连不能太激进我一般是隔2秒、5秒、10秒递增重试避免设备还没起来就把日志刷爆也避免反复重连对现场网关造成压力。4. 实测排坑那些现场才能遇到的问题4.1 高频异常查阅表现象根因解决办法界面卡死、白屏网络操作跑了UI线程全部使用Task.Run BeginInvokeJSON反序列化失败字段名大小写不一致设置PropertyNameCaseInsensitive或统一命名中文乱码接收端和发送端编码不一致全程统一UTF-8收到一半数据拆包没处理加消息边界按行解析多次发送数据交错多线程同时写流发送加锁窗体拉伸后控件变形未用布局容器多用Dock和TableLayoutPanel表里的最后一行跟Winform窗体缩放有关。很多人在开发机上界面正常换到低分辨率屏幕或者手动缩放窗体控件就跑位了。这不是网络问题但却是Winform上位机被问到最多的坑之一。解法很简单界面布局用Dock配合TableLayoutPanel而不是一堆绝对坐标窗体允许缩放时控件能自适应。如果业务要求固定尺寸就把FormBorderStyle和AutoScaleMode设置好别让它随意拉伸。4.2 一个真实的 JSON 解析翻车记录我在调试数据上报功能时设备明明把数据发过来了上位机却反复报错“Failed to deserialize the JSON body into the target type”。抓了报文才发现设备发来的字段type是小写而我定义的类属性是Type。Newtonsoft.Json默认对属性名大小写不敏感但换成System.Text.Json之后默认区分大小写字段匹配不上就直接反序列化失败。这个问题很常见因为很多设备端的JSON库会动态小写化字段名Java里大写开头的变量转成JSON时也容易变成小写。解决办法有两个要么在反序列化时设置大小写不敏感要么给属性加特性强制映射到小写字段。这个坑写出来是因为现场报错信息非常迷惑不看原始报文根本猜不到是字段大小写的问题。建议大家在排查反序列化问题时第一步永远是先打印原始JSON字符串别盯着异常信息猜。5. 项目改造方向与个人实操体会最后聊几点我做这类通讯模块攒下来的经验。第一个建议是一定要写一个模拟设备端。你在Winform旁边放一个简单的控制台程序监听同一个端口收到JSON后按你设计好的规则回包。现场联调之前先在模拟环境把正常包、异常包、大包、断包全部测一遍能省掉大量和真设备耗在一起的时间。第二个建议是收发JSON的样例要留着当“脚手架”。这个组合的可扩展性很强往后无论是接扫码枪、接仪表、接PLC网关还是对接摄像头SDK识别结果通讯层的代码都能复用你只需要换掉ProcessJsonLine里面的业务处理逻辑就行。第三个建议是不要一上来就迷信第三方TCP组件。自己手写一遍连接、收发、拆包、心跳你对网络通讯的底层机制会有完全不一样的理解。等真的需要高并发、高可靠了再去引入更重的框架也有能力判断它到底适不适合自己的场景。踩过坑才知道坑长什么样这句话放在Socket开发里再合适不过。本文还有配套的精品资源点击获取