易语言局域网聊天源码解析：TCP通信、粘包与编码实践

简介：这是一套基于易语言编写的局域网聊天源码，面向易语言初学者与需要快速搭建局域网通讯功能的开发者，目标是实现小范围内多台电脑间的即时消息收发与在线状态维持。源码中包含了“取时间”“持续在线”等聊天程序常用功能，窗口程序集结构明确：启动窗口创建完毕事件负责初始化，修改、保存、发送三个按钮的单击事件分别对应配置信息更新、参数保存与消息发送，便于读者对照学习易语言窗口组件与事件驱动编程思路。资源以zip压缩包形式发布，体积仅7KB，压缩包内为易语言源码工程文件，可导入后直接查看和调试。该资源已有69人学习下载，适合作为网络编程课的课后练习或个人练手项目。得益于完整的按钮事件处理逻辑，读者可以快速理解系统时间获取、在线状态维护和消息发送的实现方法，并进一步扩展出好友列表、异常断线重连等更丰富的功能。

1. 易语言局域网聊天源码：一个 .e 文件背后的通信功课

「易语言局域网聊天源码」这类资源，常被当作“不务正业的小玩具”看待。但真把它在宿舍、小办公室或实验室里跑一遍的人都知道，界面简单只是表象，真正决定能不能用的是网络层那几十行代码。这套源码解决的核心问题是：不借助公网服务器，在同一个局域网内完成多台机器之间的实时文本收发。适合两类人——想快速搭一个内部沟通小工具的入门者，以及想弄明白 TCP 连接、端口绑定、数据粘包这些概念在中文编程环境里长什么样的学习者。动手之前先想清楚一个问题：你要的是“两台机器能聊”，还是“多机器稳定不掉线”。这两个目标，指向完全不同的实现路径。

2. 服务端与客户端架构：TCP 和 UDP 怎么选，源码站在哪一边

2.1 易语言网络组件：服务器、客户、数据报的分工

易语言里和网络通信相关的组件主要有三个：服务器、客户、数据报。新手最容易犯的错，是打开源码后看到一堆组件不知道谁在干活，先分清它们的分工，后面读代码才不会被绕晕。

服务器组件负责在某个端口上监听，接收多个客户端的连接请求。每个客户端连进来后，服务器会拿到一个整数型的句柄，之后所有收发操作都靠这个句柄来区分是哪个客户端。它天然适合做“一对多转发中心”，也就是服务端收到一条消息后，转手发给所有在线的人。客户组件则简单得多，主动填上服务端的 IP 和端口，连上去就能收发数据，通常在窗口上表现为“连接服务器”按钮背后的那段逻辑。数据报组件走的是 UDP 协议，无连接，直接把数据丢给目标 IP 和端口，不需要先握手。

三者的关系用一张表可以看得很清楚：

从这张表能看出选型逻辑：如果只是两台机器临时通信，数据报组件最省事；但凡是“多人群聊”或“需要知道谁在线”，就必须有一个 TCP 服务端做中转，否则离线状态根本无法集中管理。这套源码选择 TCP 服务器加客户的组合，本质上是一个“可维护”的架构决定，而不是随手选的。

2.2 读源码第一步：区分服务端与客户端

拿到一份局域网聊天源码，不要先急着编译，先把窗口界面翻开，看组件面板里放了什么。判断标准很简单：有服务器组件的，这个程序就是服务端；有客户组件的，就是客户端。还有一种是两边都放了，做成“既当服务端又可当客户端”的一体式程序，多见于早期小工具。

服务端启动那段代码，长这样：

.版本 2 .程序集 窗口程序集_启动窗口 .子程序 _按钮_启动服务_被单击 服务器1.端口 ＝ 5200 服务器1.启动 () 编辑框_日志.加入文本 (“服务端已启动，等待客户端连接...”) .子程序 _服务器1_客户进入 .参数 客户句柄, 整数型 编辑框_日志.加入文本 (“客户端接入，句柄：” ＋ 到文本 (客户句柄))

这段代码的逻辑是：点击按钮后，先给服务器组件指定端口，再执行启动命令。注意端口必须在启动前赋值，否则启动时用的还是组件默认值。端口号一般选 1024 到 65535 之间，避开 80、8080、3389 这类被系统或其他服务占用的常见端口。局域网内部聊天没有公网暴露需求，5200、6000 这类不常用的数字段足够了。

“客户进入”事件里的参数叫客户句柄，这是个整数型的唯一标识，不是 IP 地址。易语言在这点上设计得很隐蔽：服务器组件不会直接告诉你“谁进来了”，只给你一个句柄，你要自己维护句柄和昵称、IP 的对应关系。这也是我前面说的隐藏复杂度，源码里如果看到有“在线句柄”“在线昵称”这样的数组变量，通常就是在做这件事。

客户端这边的连接代码更直白：

.子程序 _按钮_连接服务器_被单击 客户1.连接 (编辑框_服务器IP.内容, 5200) .子程序 _客户1_连接成功 编辑框_日志.加入文本 (“连接成功”) .子程序 _客户1_数据到达 .局部变量 数据, 字节集 .局部变量 文本, 文本型 数据 ＝ 客户1.取回数据 () 文本 ＝ 到文本 (数据) 编辑框_消息记录.加入文本 (文本)

连接命令需要两个参数：服务端 IP 和端口。IP 这里强烈建议做成编辑框让用户手工输入，不要写死在源码里。写死在代码里的 IP 在你自己机器上调试没问题，一换环境就要重新编译，这是源码落地时最常见的翻车点之一。“连接成功”事件用来更新界面状态，“数据到达”事件里用取回数据把收到的字节集拿出来，再转成文本显示。注意这里“到文本”的隐含编码转换，是后面中文乱码的源头，第 4 章会专门展开。

2.3 连接时序：从端口绑定到消息收发

一份典型的局域网聊天源码，运行时完整的事件顺序是：服务端点按钮启动监听，客户端填好 IP 和端口点连接，服务端触发“客户进入”事件，客户端这边触发“连接成功”事件，然后任意一方发送数据，对方触发“数据到达”事件。这个时序搞清楚，后面排查问题就有了坐标轴：卡在哪一步，就去看对应的事件有没有触发。

服务端要支持多人群聊，光会收数据不够，还得会转发。核心逻辑是收到任意一个客户端的消息后，遍历在线句柄数组，发给除发送者之外的所有人：

.子程序 _服务器1_数据到达 .参数 客户句柄, 整数型 .局部变量 原始数据, 字节集 .局部变量 i, 整数型 原始数据 ＝ 服务器1.取回数据 () 计次循环首 (取数组下标 (在线句柄, ), i) 如果真 (在线句柄 [i] ≠ 客户句柄) 服务器1.发送数据 (在线句柄 [i], 原始数据) 如果真结束 计次循环尾 ()

这段代码的关键是“排除自己再群发”。如果不判断句柄是否相等，发送者自己也会收到自己的消息，出现“我发一条、显示两条”的诡异现象。取数组下标返回的是在线句柄数组的成员数量，计次循环首从 1 循环到该数量，逐个取出句柄发送数据。这里还有个细节：消息被原样转发时，接收方看到的只是一段文本，没有来源标识。所以多数源码在转发前会先拼一个“昵称:消息”的格式，或者用第 4 章讲的结构化消息头，把发送者信息带上去。

服务端转发方案的取舍也很清楚：优点是消息统一过中转，在线状态集中管理；缺点是多一次转发延迟，而且服务端一挂，全部客户端集体掉线。所以在局域网规模不大（几十人以内）的情况下，这种中心化架构是性价比最高的，不需要像公网聊天工具那样做去中心化。

3. 把源码变成可执行程序：改 IP、换端口、静态编译的三站路

3.1 源码包结构：一个 .e 文件如何撑起整个聊天程序

下载下来的源码包，核心是一个 .e 后缀的易语言工程文件，所有窗口布局和逻辑都在这一个文件里。除此之外可能还有几个辅助文件，别忽略它们：

拿到源码包后，第一件事不是双击 .e 文件，而是先看看有没有带 .fne 或 .ec 后缀的模块文件。如果有，把它复制到易语言安装目录下的 lib 文件夹里。否则打开源码时，IDE 会弹窗提示找不到指定支持库，然后一堆子程序名字变成红色问号，根本没法编译。我一般会直接全盘搜索一下 lib 目录里是否已经存在同名文件，避免重复安装把旧版本覆盖掉。

3.2 部署三件事：IP、端口、客户端列表

真正要把这套源码用到实际环境，需要处理三件事：IP 怎么定、端口怎么统一、在线客户端列表怎么维护。

IP 方面，服务端机器需要固定 IP。先在服务端那台机器上查一下当前局域网地址：

ipconfig

输出里找“IPv4 地址”，一般在 192.168.x.x 或 10.x.x.x 段。多网卡的机器会列出好几块网卡，有线、无线、虚拟机网卡的地址会混在一起，要填当前实际连接局域网的那一块。如果服务端用的是 DHCP 自动获取，重启路由器之后 IP 可能变，客户端那边就连不上了。所以我一般建议在路由器后台给服务端机器做 IP 绑定，或者干脆在 Windows 网络设置里把 IP 改成静态。

端口处理上，最省事的方式是不改源码里默认的端口号，三处保持统一：服务端启动用的端口、客户端连接用的端口、防火墙放行的端口。如果非要改，记得搜索源码里所有出现这个端口的地方。更稳妥的做法是把端口也做成可配置的：

.子程序 _按钮_启动服务_被单击 服务器1.端口 ＝ 到整数 (编辑框_端口.内容) 服务器1.启动 ()

这样一来，换环境时只需要打开界面改编辑框内容，不需要重新编译源码。端口变更后，Windows 防火墙的入站规则也要对应改，否则服务端能启动，但局域网其他机器连不进来。

客户端列表的维护是服务端的核心数据，源码里通常有两个数组配合使用：一个装句柄，一个装昵称。客户端一进一出一走，两个数组要同步增删。最容易出的问题是只加了句柄没加昵称，转发消息时变成“空名字发来一条消息”。

3.3 静态编译与运行分发：别在目标机器上再装环境

很多人编译完 exe，拷到别的机器上一双击，弹窗提示“无法找到支持库”或者直接没反应，然后就觉得是对方机器缺环境。这个认知是错的。易语言源码发布时要选“静态编译”，把用到的支持库代码直接打进 exe 里；如果当年选的是动态编译，exe 就会依赖外部的支持库文件，拷走时少带一个文件都跑不起来。

稳定的编译流程是：先保存源码，然后点菜单栏“编译”里的“静态编译”。输出目录自己选一个干净的文件夹。编译成功后，在本机先双击运行一次，Windows 防火墙会弹出授权窗口，这时候勾选“专用网络”允许。接着查看端口是否正常监听：

netstat -ano | findstr 5200

如果返回了 LISTENING 状态，说明服务端端口绑定成功。这一条命令能排除掉端口被占、服务没起来、防火墙拦截三类问题。确认无误后，再把 exe 单独拷到另一台机器上运行。静态编译出来的 exe 自带支持库，目标机器不需要安装任何开发环境，也不需要额外的运行库。

有一个反直觉的经验：静态编译的 exe 体积往往在几百 KB 到一两 MB 之间，如果编译出来只有几十 KB，基本可以断定是动态编译，运行时必然依赖额外支持库。判断一种源码是否能静态编译，要看它引用的第三方模块是否支持。部分老模块只支持动态编译，这种源码要么换模块，要么老老实实把支持库文件一并分发。

4. 消息协议与编码：乱码、粘包、半包，局域网聊天的三个深水坑

4.1 不可见的编码：GBK、ANSI 与 UTF-8 的中文乱码

中文乱码是局域网聊天源码里第一个深水坑。易语言在中文系统下，文本转成字节集时默认走 GBK 编码，接收端再把字节集转回文本，默认也按 GBK 解释。如果两端都是中文系统，这条链路是通的。但有个隐藏场景：服务端已经做了一次“字节集到文本”的转换，转发时又做一次“文本到字节集”，如果中间文本被当作 UTF-8 处理过一次，源头就歪了，后面怎么都掰不回来。

最稳的做法是全链路不转文本，直接用字节集搬运。需要显示时再转一次文本：

.子程序 发送消息, 逻辑型 .参数 目标句柄, 整数型 .参数 消息内容, 文本型 .局部变量 数据, 字节集 数据 ＝ 到字节集 (消息内容) 返回 (服务器1.发送数据 (目标句柄, 数据))

这段代码的重点是只在发送前做一次文本到字节集，接收方只在显示时做一次字节集到文本。中间任何转发环节都别碰编码转换。你把“到文本（取回数据（））”这行代码写在服务端转发逻辑里，就等于在中间环节引入了第二次解释，一旦原文本里有特殊字符就会出问题。

提示：易语言程序的源码文件本身也建议用 GBK 编码保存，保持整个项目编码一致，避免不同机器上打开源码就出现中文注释乱码。

4.2 消息格式设计：分隔符与消息头

两台机器之间发纯文本，可以直接发。但多用例下，消息里不只有对话内容，还要带发送者昵称、时间、消息类型。这时候就要设计消息格式。最简单的做法是固定分隔符拼接：

昵称|消息内容|时间

接收端用分割文本命令拆开。但这个方案有个众所周知的坑：如果消息内容里本身带了“|”字符，分割后字段数就对不上了。我见过有人用替换命令先把内容里的“|”换成全角“｜”，接收后再换回来，属于能用但很脆的方案。

更稳的是结构化消息头，在数据开头固定放几个字段，接收端按长度读取。字段定义如下：

构建消息的代码：

.子程序 构建消息, 字节集 .参数 消息类型, 整数型 .参数 内容, 文本型 .局部变量 类型文本, 文本型 .局部变量 长度文本, 文本型 .局部变量 内容字节, 字节集 .局部变量 数据, 字节集 内容字节 ＝ 到字节集 (内容) 长度文本 ＝ 到文本 (取字节集长度 (内容字节)) 如果真 (取文本长度 (长度文本) ＜ 10) 长度文本 ＝ 取空白文本 (10 － 取文本长度 (长度文本)) ＋ 长度文本 如果真结束 类型文本 ＝ 到文本 (消息类型) 数据 ＝ 到字节集 (类型文本 ＋ 长度文本) ＋ 内容字节 返回 (数据)

这段代码把消息类型和内容长度拼成 11 个字节的头部，再接上内容字节。长度字段用固定 10 位十进制文本而不是二进制整数，牺牲一点空间，换来两个好处：一是没有字节序问题，不用考虑大端小端；二是调试时把字节集转成文本就能直接读出长度值。类型字段这里只占 1 字节，聊天场景放 0 到 9 的类型足够，如果以后要扩展出文件传输、图片消息，把类型字段改成定长 2 位十进制即可。

接收端的拆包逻辑是这套协议的灵魂，放在下一节一起说。

4.3 数据边界：粘包和半包的重组策略

TCP 协议本身是流式的，没有消息边界。发送方连续发两条“你好”“在吗”，接收方可能一次收到“你好在吗”，这叫粘包；反过来一次收到的数据不足一条完整消息，这叫半包。这个坑在易语言局域网聊天里极其常见，表现为：两个人同时说话，消息串成一行；或者一条长消息时不时缺尾巴。

处理粘包和半包的标准思路是“缓冲区累积 + 按长度切分”。先在全局变量里放一个接收缓冲区，每次数据到达就把新数据追加进去，然后循环检查缓冲区里有没有完整消息：

.全局变量 接收缓冲区, 字节集 .子程序 处理新数据 .参数 新数据, 字节集 .局部变量 类型文本, 文本型 .局部变量 长度文本, 文本型 .局部变量 消息长度, 整数型 .局部变量 内容字节, 字节集 接收缓冲区 ＝ 接收缓冲区 ＋ 新数据 判断循环首 (取字节集长度 (接收缓冲区) ≥ 11) 类型文本 ＝ 到文本 (取字节集中间 (接收缓冲区, 1, 1)) 长度文本 ＝ 到文本 (取字节集中间 (接收缓冲区, 2, 10)) 消息长度 ＝ 到整数 (长度文本) 如果真 (取字节集长度 (接收缓冲区) ＜ 11 ＋ 消息长度) 跳出循环 如果真结束 内容字节 ＝ 取字节集中间 (接收缓冲区, 12, 消息长度) 编辑框_消息记录.加入文本 (“类型：” ＋ 类型文本 ＋ “，内容：” ＋ 到文本 (内容字节)) 接收缓冲区 ＝ 取字节集右边 (接收缓冲区, 取字节集长度 (接收缓冲区) － 11 － 消息长度) 判断循环尾 ()

这个循环的逻辑分四步：先检查缓冲区长度是否至少有 11 字节的头部，不足说明连头部都没收全，留到下次；读到长度字段后，检查缓冲区里是否已经有完整内容，不足就跳出循环等更多数据；够了就按长度取内容处理；最后把已处理的部分从缓冲区头部切掉。这里有个我自己踩过的坑：切缓冲区时容易把“保留剩余”和“删除已用”搞反，取字节集右边时，保留长度必须是缓冲区总长减去 11 再减去消息长度，而不是直接减十一，写错了会把前面的消息头又保留下来，导致下一条消息解析错位。

这套代码写完，继续用循环处理剩余数据，就能处理一次到达多条消息的情况。这也是判断一份源码水平高低的分界线：只写“取回数据显示”的不考虑边界，写出缓冲区循环的才算真正把 TCP 消息边界问题消化掉了。

5. 避坑与排查：部署局域网聊天源码的五条血泪经验

5.1 服务端能收到消息，客户端集体掉线

现象：服务端日志里能看到“客户端接入”，发消息也有记录，但所有客户端那边要么收不到消息，要么直接闪退。

原因：多半是服务端在“客户进入”事件里把客户句柄直接当数组下标使用，或者误调用了断开连接命令。易语言的数组越界不像别的语言只报错，很多情况下程序直接闪退，表现成“我在服务端发一条消息，全房间的人都掉了”。这是典型的处理客户端句柄时把句柄值和数组下标搞混了。

解决：在线列表用添加成员命令维护，句柄存进数组但绝不用它做下标；不要在“客户进入”事件里发送任何数据，只做登记。断开统一放在“客户离开”事件里，从数组中找到对应位置再删除成员。

5.2 本机调试正常，换一台机器就连不上

现象：在自己电脑上服务端和客户端都开着一个窗口，收发正常；把客户端程序拷到另一台笔记本上，连接按钮一点就报失败或超时。

原因：两种情况。一是客户端源码里 IP 写死成了 127.0.0.1，这是本机回环地址，换机器后连的还是自己的网卡；二是服务端那台机器的 IP 是 DHCP 分配的，重启后自动换了一个地址，客户端填的还是旧 IP。这两个原因都指向同一个本质：代码里用了“当前机器”的视角，而不是“局域网其他机器”的视角。

解决：客户端把服务端 IP 改成编辑框可填写，或者启动时用常见做法——调用系统命令 ipconfig 并把结果填到编辑框里让用户自己选。服务端这台机器在路由器后台绑定静态 IP，从根本上消灭“IP 变了”这类玄学问题。修改后我在一台机器上测连接，另一台机器测连接，两台都通了才算过。

5.3 中文消息变成问号和乱码

现象：本机聊天中文正常，但两台配置不同的机器互聊，A 发给 B 的中文显示成“？？？”或一堆乱码。

原因：消息在中间环节被二次转换。发生链通常是：发送端把文本转成 GBK 字节集，服务端取回数据后先做了“到文本”，转发时再“到字节集”，这一步把原本的 GBK 字节重新解释了一遍，编码就歪了。还有一种是机器区域设置不同，默认 ANSI 代码页不一致，导致同样的字节被解释成不同字符。

解决：按第 4.1 节的方式，全链路使用字节集，只在显示时做一次到文本转换。如果第三方模块或新代码里已经有“编码转换”类命令，统一把所有发送内容都经过同一套转换命令，不要一会手写字节集一会走文本转换，两套逻辑混用必出乱码。改完之后，找一个中文路径的机器和一个英文区域设置的机器做交叉测试，这一条值得单独跑一遍。

5.4 两条消息拼成一条，谁先发谁丢

现象：群里两个人几乎同时发消息，接收方看到一条长文本，把两个人的话拼在一起；或者高频发消息时，偶发丢最后几个字。

原因：标准的 TCP 粘包和半包问题。发送过快时，底层 TCP 协议栈会把多个小数据包合并成一个大数据包交给应用层；反过来，消息较长时可能被拆成多次到达，如果接收方每次只取一次数据就显示，就会显示到一半的消息。我之前调试时反复确认代码逻辑没问题，最后在缓冲区里打印十六进制才看清是粘包，这就是 TCP 流式传输的黑匣子特性。

解决：按第 4.3 节的缓冲区累积方案，每条消息带长度字段，接收循环里每次只处理一条完整消息，处理完继续看缓冲区里还有没有下一条。改完的验证方法：连续快速发送几十条不同内容的消息，接收端应该按顺序完整显示，且每条内容独立。

5.5 窗口关了进程没退出，端口被占用

现象：关掉聊天程序窗口，再重新启动同一服务端，弹窗提示端口被占用，或者服务启动失败。打开任务管理器一看，上一个进程还在后台躺着。

原因：易语言窗口关闭时，网络组件并没有自动释放端口。服务器组件还在监听原来的端口，新的进程自然绑不上。这种情况在调试时特别容易遇到，改一次代码重跑一次，偶尔就撞上。

解决：在窗口的将被销毁事件里显式释放网络资源：

.子程序 _窗口_将被销毁 服务器1.销毁 () 客户1.断开 () 结束 ()

销毁方法会释放端口，断开方法会中断客户端连接，最后的结束确保整个进程退出。从那以后我每次改完网络相关源码，关窗口前都习惯性地看一眼任务管理器里有没有残留进程，这个习惯帮我避免了很多次“端口被占”的假故障。

6. 小步进阶：给聊天源码加上在线状态列表

一套能用的局域网聊天工具，除了收发消息，至少还应该让每个人看到“谁在线”。这个功能改起来不复杂，正好把前面协议设计的功夫用上。

思路分三步。第一步，服务端在客户端进入和离开时，维护在线句柄数组和昵称数组。第二步，每次列表变化，服务端把完整名单广播给所有在线客户端。第三步，客户端解析名单消息，刷新窗口里的列表框或名单框。广播名单的代码：

.子程序 广播在线名单 .局部变量 i, 整数型 .局部变量 名单, 文本型 名单 ＝ “USERLIST|” 计次循环首 (取数组下标 (在线句柄, ), i) 名单 ＝ 名单 ＋ 在线昵称 [i] ＋ “|” 计次循环尾 () 计次循环首 (取数组下标 (在线句柄, ), i) 服务器1.发送数据 (在线句柄 [i], 到字节集 (名单)) 计次循环尾 ()

名单消息以 USERLIST 开头，方便客户端识别。客户端收到后，用分割文本把昵称拆出来，刷新列表框。这里的分隔符还是“|”，和第 4 章的转义规则保持一致，解析代码可以复用。

离线检测需要考虑。直接点关闭按钮的客户端会触发客户离开事件，名单更新及时；但拔网线、断电这类异常离开不会触发任何事件，名单里会残留死句柄。实战中的解法是心跳机制：客户端每 5 秒向服务端发一条类型为 0 的保活消息，服务端用定时器检查，10 秒内没收到某个客户端的任何消息，就判定它已离线并从名单移除。如果不想引入心跳，也有一种简单的兜底：每次服务端发消息时，如果某个句柄发生“句柄无效”错误，就顺手把它清掉。

完整的验证场景值得走一遍：开两台机器，A 上线后 B 的名单里出现 A；B 上线后 A 的名单里出现 B；把 A 的进程强制结束，等 10 秒，B 的名单里 A 自动消失。这三步全过，在线状态列表才算真正闭环。

这个功能做完，离发版就不远了。记得有一次我图省事，跳过离线检测直接演示，结果现场有一台机器被拔了网线，名单里那个名字挂了十分钟还挂在上面，当时确实尴尬。从那以后，我每次改完这套源码，都强制把“两台机器、拔网线、再插回去”的流程走一遍，确认名单能自己恢复才敢交付。希望这条习惯也能帮到你。

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