简介一份面向 Delphi 72007 开发者的 Indy 10.2.3 网络组件库完整源码包。Indy 是开源跨平台的网络通信组件集它提供了 TCP/IP、HTTP、FTP、SMTP、POP3 及 SSL/TLS 支持可直接用于构建客户端与服务端网络应用。资源共 839 个文件压缩包仅 4.98MB以 Pascal 源文件.pas、组件包工程.dpk、设计期包.bpl、编译配置.bdsproj及资源文件.rc/.res/.bmp为主便于源码阅读与重新编译安装目前已有 347 人学习下载。包内含 clear.bat、build.bat、makeres.bat 构建脚本以及 IndyCore、IndySystem、IndyProtocols 等系列工程能够帮助开发者在老版本 Delphi 中快速生成运行时包与设计期包完成组件注册借助这份资源开发者可省去自行收集散落源码的麻烦直接获得经过整理的 Indy 10.2.3 源码树和编译配置进而在 Delphi 72007 环境中使用 TIdTCPClient、TIdHTTPServer、TIdFTP、TIdSMTP 等常用组件提升网络应用开发效率。1. 还在用 Indy 10.2.3老 Delphi 项目绕不开的套接字底座Indy 10.2.3 这个版本号在很多维护型项目里不是随便能换的。团队老代码当年写在 Delphi 7/2007 时代TCP 通信、HTTP 接口、FTP 上传全挂在 TIdTCPClient、TIdHTTP 上。新版本 Indy 的接口把 IOHandler、编码、包管理全部重排过直接升级等于把几百处网络调用重写一遍。于是不少团队把 10.2.3 当成“标准件”锁在版本库里能编译、能跑、能维护。这篇文章就把这套资源怎么装进 IDE、怎么写最小客户端和服务端、以及最常踩的坑讲清楚。适合做遗留系统维护的 Delphi 开发者也适合刚接手老项目、需要快速把手头网络功能跑通的初学者。2. 装进 IDEIndy 10.2.3 的安装与组件注册资源包解压后第一眼看到一堆目录别急着往 IDE 里拖。先把包的组成弄清楚再决定是手工编译还是直接装 BPL。很多人一上来就把整个目录塞进 Library Path结果编译时单元互相覆盖报出一堆莫名奇妙的错误。2.1 一个发布包常见组成是什么Indy 10.2.3 的源码包通常按模块拆成几个子目录目录名可能略有出入但职责基本一致。下表是我拆过这类包后的通用结论目录 / 文件作用Lib/SystemIdGlobal 等最基础通用单元编译期必须最先找到Lib/Core底层套接字、TIdTCPClient、TIdTCPServer 等核心类Lib/SuperCoreIOHandler、Intercept、缓冲与线程辅助类Lib/Protocols上层协议实现HTTP、FTP、SMTP、POP3 等Packages/D7、D9、D10不同 IDE 版本对应的 .dpk 编译工程根目录或 Bin部分发布包会带预编译 DCU/BPL但跨版本不可靠这里要泼一盆冷水同是 10.2.3在 Delphi 7 下编出来的 DCU放到 Delphi 2010 里基本不能直接用。Delphi 编译器版本不同生成的 .dcu 格式和内部 RTL 接口都有差异直接复制 BPL 进新 IDE 是翻车重灾区。我一般建议绕开预编译文件用源码重编。源码的方式虽然多花几分钟但之后不会再被“DCU 版本不匹配”这种问题反复纠缠。2.2 编译前先配置库路径打开 IDE 的环境选项找到 Library PathDelphi 7 在 Tools Environment Options Library新版本在 Tools Options Environment Options Library把下面四个路径加进去。注意顺序System 要在最前面Core 其次Protocols 最后。Delphi 搜索单元是按路径顺序来同一个单元名出现在多个路径时先找到的先生效顺序颠倒可能把类型定位到错误的源文件。# 假设解压到 D:\ThirdParty\Indy10 # 下面四条路径逐条加进 IDE 的 Library Path D:\ThirdParty\Indy10\Lib\System D:\ThirdParty\Indy10\Lib\Core D:\ThirdParty\Indy10\Lib\SuperCore D:\ThirdParty\Indy10\Lib\Protocols路径是假设值实际以你解压的位置为准。加完后不要急着点确定先确认这些目录里确实有 .pas 文件。有些发布包把源码直接铺在根目录没有 System/Core 这样的子目录那只要把根目录加进去即可。接下来是编译顺序。Indy 分成几个运行时包包与包之间有依赖IndySystem 是基础IndyCore 依赖它IndyProtocols 依赖 Core。顺序反了会报“无法找到单元 IdGlobal.pas”或“依赖的包未安装”。进入 Packages 下对应 IDE 版本的目录按下面顺序编译cd D:\ThirdParty\Indy10\Packages\D7 # -B 表示全量重建-JL 表示生成运行时包BPL dcc32 -B -JL IndySystem10.dpk dcc32 -B -JL IndyCore10.dpk dcc32 -B -JL IndyProtocols10.dpk命令里的包名是常见命名实际包名可能带版本后缀例如 IndySystem10_D7.dpk以包内文件为准。如果你用的是 Delphi 2010 以上版本我一般不建议走命令行直接在 IDE 里打开 .dproj/.dpk用 Project Manager 逐个项目 Build 更稳。命令行适合 Delphi 7而且要先保证 dcc32.exe 在 PATH 里。编译运行时包之后还要编译并安装设计时包。设计时包负责把组件注册到 IDE 的组件面板常见文件名以 dcl 开头。先编译再安装dcc32 -B -JL dclIndyCore10.dpk dcc32 -B -JL dclIndyProtocols10.dpk然后在 IDE 菜单里打开 Component Install Packages点 Add 找到刚才生成的 dclIndyCore10.bpl 和 dclIndyProtocols10.bpl。安装成功后组件面板会多出 Indy Clients、Indy Servers、Indy IO Handlers 等页签。这里的关键点是只编译 dcl 包但不 Add 到 IDE组件面板不会有任何变化这是新手最容易忽略的一步。2.3 装完组件面板没有出现装完重启 IDE组件面板还是空的按下面几条逐个排查。确认 Add 的是 dcl 开头的设计时包不是运行时包。运行时包只提供类实现不注册组件。确认没有旧版 Indy 占用同名包。Delphi 7 自带 Indy 9面板上已经有一组 Indy Clients/Servers再装 Indy 10 时两者会并存但如果 IDE 报“Contains unit ... which is already loaded”说明有另一个 Indy 10 实例已经被加载需要先在 Install Packages 里移除旧包。确认 Library Path 里的路径是源码目录不是编译输出目录。曾见过把路径指向 DCU 输出目录结果 IDE 拿着旧的 .dcu 去编译始终加载不到新版组件。用代码验证最直接。新建一个工程在 uses 里引用 IdGlobal然后打印编译期版本常量uses IdGlobal; procedure TForm1.FormCreate(Sender: TObject); begin // 能编译并能显示数字说明 Library Path 生效 // IdBuildNumber 是编译期常量不同构建版本值不同 Self.Caption : Indy Build: IntToStr(IdBuildNumber); end;如果编译时提示找不到 IdGlobal.pas说明路径没配好或顺序不对。如果编译通过但运行报错再回头看包有没有装全。这套验证成本很低比在面板上反复拖组件快得多。3. 上手跑通TIdTCPClient 与 TIdHTTPServer 的最小可运行实现装好组件后先不要急着套业务写一个能连通的 Client 和 Server把 IOHandler、超时、编码这几个核心点摸清楚。Indy 10 和早期版本最大的区别是 IOHandler 被提到了核心位置所有的读写都通过 IOHandler它本身又是惰性创建的连接建立时才真正分配资源。3.1 客户端连一次、发一条、读一行下面的函数演示最常用的“连接-发送-读取-断开”完整回合。很多老项目里 TCP 自定义协议都是这个套路只是命令和响应格式不同。uses System.SysUtils, IdGlobal, IdTCPClient; function SendCommand(const AHost: string; APort: Integer; const ACmd: string): string; var LClient: TIdTCPClient; begin LClient : TIdTCPClient.Create(nil); try LClient.Host : AHost; LClient.Port : APort; LClient.ConnectTimeout : 3000; LClient.ReadTimeout : 5000; LClient.IOHandler.DefStringEncoding : IndyTextEncoding_UTF8; LClient.Connect; try LClient.IOHandler.WriteLn(ACmd); Result : LClient.IOHandler.ReadLn; finally LClient.Disconnect; end; finally LClient.Free; end; end;代码逻辑分三段创建并配置、连接并通信、断开并释放。Connect 之前不要碰 IOHandler它是连接建立后自动创建的提前访问会拿到 nil。ConnectTimeout 和 ReadTimeout 的单位都是毫秒ConnectTimeout 默认 0 表示无限等待局域网内建议设 3000跨网段可以放宽到 5000-8000ReadTimeout 表示等待对端数据的最大时间超过后抛 EIdReadTimeout 异常。DefStringEncoding 这里显式改成 UTF8否则老版本默认 ASCII中文会乱。ReadLn 是按换行符分割读取的文本读取方法适合行协议。如果你的协议是二进制格式比如“4 字节长度头 正文”可以先用 ReadBytes 读固定长度var LHead: TIdBytes; LBodyLen: Integer; begin // 读 4 字节定长包头 LClient.IOHandler.ReadBytes(LHead, 4, False); // 把包头转成整数再按长度读正文 LBodyLen : (LHead[0] shl 24) or (LHead[1] shl 16) or (LHead[2] shl 8) or LHead[3]; end;ReadBytes 的第二个参数是字节数第三个参数表示是否把数据追加到原缓冲区。这里设为 False 表示每次只取 4 字节。注意它不会自动处理粘包只是“阻塞式读满指定字节数”上层需要自己维护包头和正文的边界。3.2 服务端TIdHTTPServer 挂路由做一个最简单的 HTTP 服务端响应 /ping 和 404 两种情况。TIdHTTPServer 比 TIdTCPServer 封得更上层它已经帮你解析了 HTTP 请求行、请求头和请求体。type TForm1 class(TForm) procedure FormCreate(Sender: TObject); procedure FormDestroy(Sender: TObject); private FServer: TIdHTTPServer; procedure DoCommandGet(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo); end; procedure TForm1.FormCreate(Sender: TObject); begin FServer : TIdHTTPServer.Create(Self); FServer.DefaultPort : 8080; FServer.OnCommandGet : DoCommandGet; FServer.Active : True; end; procedure TForm1.DoCommandGet(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo); begin if ARequestInfo.Document /ping then begin AResponseInfo.ContentText : {code:0,msg:pong}; AResponseInfo.ContentType : application/json; end else begin AResponseInfo.ResponseNo : 404; AResponseInfo.ContentText : {code:404,msg:no route}; end; end;OnCommandGet 不是在主线程里执行的。Indy 为每个连接分配一个独立线程在请求到达时回调一次。如果要在回调里更新界面不能直接改 Memo 或 Label要用 TThread.Synchronize 或 TThread.QueueDelphi 2009 以后可以配合匿名方法老项目还在 Delphi 7 的话就用 TIdNotify 或 PostMessage避免跨线程访问。ARequestInfo.Document 拿的是 URL 路径请求 /ping?x1 时 Document 是 /ping查询参数在 ARequestInfo.Params 里。AResponseInfo 是响应对象设置 ContentText 后组件会自动生成响应头不需要手工拼 HTTP 协议这也是 TIdHTTPServer 比 TIdTCPServer 省心的原因。3.3 超时、缓冲区和编码参数这三个参数基本决定了联调时是否抓狂。很多“时好时坏”的问题最后都落在参数配置上。参数类型典型默认建议ConnectTimeoutInteger0无限局域网 3000跨网 5000-8000ReadTimeoutInteger0 或 -1无限2000-10000按业务容忍度DefStringEncoding编码对象随版本通常 ASCII统一 UTF8RecvBufferSizeInteger0大文件传输可调到 32*1024SendBufferSizeInteger0大文件上传可调到 32*1024ReadTimeout 的语义是“单个读操作没有读到数据时的最大等待时间”不是整个报文读完的总超时。假设服务器分两次发送数据第一次在超时前到达第二次隔了很久才到Indy 会把两次都算作独立读操作各自等待一个 ReadTimeout。如果要控制整个报文的总时长需要自己在循环里计时。服务端和客户端都要设置编码单边设置只在单边生效。TIdHTTPServer 也有 IOHandler可以设置默认编码FServer.IOHandler.DefStringEncoding : IndyTextEncoding_UTF8;老版本默认编码偏 ASCII这是历史包袱不要依赖默认值。客户端的协议文档里如果写的是 GBK就设置对应编码如果两边都是你控制的直接统一 UTF8 最省事。4. 避坑与常见问题Indy 10.2.3 翻车现场老库的问题不在于功能不够用而在于错误信息太“黑匣子”。下面这五类问题基本覆盖了我在项目里遇到的大多数情况每一条都按现象、原因、解决三步拆开讲。4.1 现象连接正常发数据时偶发 Unknown socket error 10038一个客户端程序运行一段时间后发送消息时随机抛EIdSocketError错误码 10038有时候重启程序又好了。原因是把 IOHandler 缓存到了成员变量里。连接断开后Indy 会释放套接字和 IOHandler 资源但缓存引用还指向已释放对象。再次调用 WriteLn 时底层实际操作了一个已经不存在的 socket所以返回 10038。这是典型的“连接生命周期管理不当”。解决方法是不要缓存 IOHandler每次连接建立后再通过 LClient.IOHandler 访问并在 try/finally 中做释放。Indy 的 Disconnect 内部会同步释放 IOHandler你不需要手动 Free。如果确实需要在多个地方复用连接要考虑用锁保护连接状态而不是假设连接永远存在。4.2 现象服务端收到一串乱码TIdHTTPServer 返回的 JSON 里中文变成问号或者 TIdTCPClient 发出去的字符串到对端变成“aÌ„”之类的字符。原因是文本编码不一致。Indy 10.2.3 的默认 DefStringEncoding 偏 ASCII高位字节不被保留所以中文这种多字节字符传到对端就丢了信息。HTTP 场景下响应头里如果没有明确 charset客户端可能又按 ISO-8859-1 去解码乱码就叠加了。解决方式是双边统一编码。客户端和服务端都显式设置 UTF8LClient.IOHandler.DefStringEncoding : IndyTextEncoding_UTF8; FServer.IOHandler.DefStringEncoding : IndyTextEncoding_UTF8;如果对端是 GBK 的系统就两边都设成 GBK不要一边 UTF8 一边默认。HTTP 响应里最好也设置 ContentType 的 charset例如AResponseInfo.ContentType : application/json; charsetutf-8;这样第三方客户端拿到响应头就知道按什么编码解析而不是去猜。4.3 现象HTTPServer 的 HTTP 请求卡死不返回用 TIdHTTP 去 Get 某个接口有时数据量一大就卡住几十秒后超时甚至永久挂起。原因大概率在 HTTP/1.1 的 keep-alive 机制上。服务器返回响应时如果没有 Content-Length也没有 chunked 编码Indy 只能通过“连接关闭”来判断响应结束。但 keep-alive 下连接不会主动关闭于是客户端一直等数据。另一个常见来源是服务器先回 100 Continue老版 10.2.3 对这类中间状态处理不够完善把 100 状态混进了正文解析。解决方式最直接的是在请求头里要求关闭连接同时设置 ReadTimeout 兜底LHTTP.Request.Connection : Close; LHTTP.ReadTimeout : 10000;如果还遇到 100 Continue 干扰可以尝试把 ExpectContinue 设为 False。10.2.3 的某些构建没有这个属性那就把协议版本降为 HTTP/1.0LHTTP.ProtocolVersion : pv1_0;HTTP/1.0 默认不启用 keep-alive连接用完就关响应结束边界反而清晰。代价是每次请求多一次握手开销但对稳定性要求高的场景值得。4.4 现象TLS 握手失败报 “SSL could not be initialized”TIdHTTPServer 或 TIdHTTP 启用 TIdSSLIOHandlerSocketOpenSSL 后访问 https 地址报初始化失败几乎没有任何日志细节。原因是 OpenSSL 动态库版本不对。Indy 10.2.3 通过固定文件名 libeay32.dll 和 ssleay32.dll 加载 OpenSSL。新版本 OpenSSL 1.1 开始把动态库改名为 libcrypto-1_1.dll 和 libssl-1_1.dll老代码按旧文件名找就找不到。这问题在 64 位服务器上尤其常见系统装了 64 位新版 OpenSSLDelphi 的 32 位程序又不能用结果两边对不上。解决方法是下载 OpenSSL 1.0.2 的 32 位版本把 libeay32.dll 和 ssleay32.dll 放到 exe 同级目录。不要放在系统目录里避免被其它软件覆盖。放置位置优先级是exe 目录 当前工作目录 系统 Path。我把这两个 DLL 跟 exe 放在一起后SSL 初始化就稳定了。还有一个边界要提前知道10.2.3 年代的 SSLOptions.Method 枚举值有限对现代只开 TLS 1.2 的服务器兼容性一般。如果对接的是新的 https 接口建议评估升级到更高版本 Indy而不是死守 10.2.3。老库适合老系统新接口用新库。4.5 现象内存一直涨跑几天就吃满TIdHTTPServer 长时间运行后内存持续上升或者用 TIdHTTP 循环请求几千次后内存降不下去。原因是回调里创建的对象没有释放。Indy 的连接线程由线程池管理连接上下文、IOHandler、事件参数等都是组件自己创建并释放的但你在 OnExecute、OnCommandGet 里手工创建的 TStringList、TBytesStream、TIdMessage 等对象不在它的管理范围内不手动释放就会越积越多。解决方式是每个回调入口都用 try/finally 保护临时对象。以 TIdHTTP 循环请求为例for I : 0 to 9999 do begin LHttp : TIdHTTP.Create(nil); try LHttp.ReadTimeout : 5000; LHttp.Get(AURL); finally LHttp.Free; end; end;不要试图靠系统 GCDelphi 没有自动垃圾回收。另外要注意如果给 AResponseInfo.ContentStream 手动指定了流对象要确认组件是否会释放它。TIdHTTPServer 的 ContentStream 释放策略在不同版本里不完全一致最稳妥做法是在回调里一次性创建流、赋值、并让组件在回应结束后负责释放拿不准时就用 AResponseInfo.ContentText 而非 ContentStream避免流对象生命周期纠缠。5. 进阶调试用 TIdLogFile 和回环测试把网络读写看清最后一次联调时先把“数据到底长什么样”看清楚再动手。Indy 10 自带一个经常被忽略的日志组件 TIdLogFile可以把它挂到 IOHandler 的 Intercept 上把每次网络读写的行为记录到文件里。uses IdLogFile, IdTCPClient; var LLog: TIdLogFile; begin LLog : TIdLogFile.Create(nil); LLog.Filename : C:\Logs\tcp_client.log; LLog.LogTime : True; LClient.IOHandler.Intercept : LLog; end;LogTime 会在每条记录前打时间戳用于对照卡顿发生的时间点。挂上后WriteLn、ReadLn、ReadBytes 这些操作都会记录到文件收发内容能看到最原始形态。服务端同理在 TIdTCPServer 的 OnConnect 事件里给当前连接的 IOHandler 挂 Intercept。这个思路比到处写 ShowMessage 高效得多也更容易定位“数据到底发没发出去、对面到底回了什么”。如果不想看日志文件还可以做纯本机回环测试。客户端连 127.0.0.1端口选 12000 以上的高位端口在同一台机器上把服务端跑起来。这样可以隔离防火墙策略和网络丢包的影响。回环通了再换真实 IP问题定位范围缩小一大半。如果只是验证端口转发逻辑Indy 自带 TIdMappedPortTCP几十行代码就能把一个端口的数据转发到另一个端口用来排查网络链路问题非常方便。沿用这个思路我后来的项目习惯是任何网络模块第一版写完不急着接对方联调先本地搭一个最小服务端用 TIdLogFile 把请求报文全量记录下来自己先检查一遍协议格式再做对接。这样做的原因是联调时对方往往没有能力帮你抓包你自己先把报文搞清楚了对接时才能直接指出“你的包头长度字段多算了 2 字节”这类问题而不是猜来猜去。从那以后我每次接触陌生协议都会强制自己走一遍“日志 回环”流程哪怕是一个只有两三个交互的小模块也不跳过。希望这个习惯对你也有用。本文还有配套的精品资源点击获取
简介一份面向 Delphi 72007 开发者的 Indy 10.2.3 网络组件库完整源码包。Indy 是开源跨平台的网络通信组件集它提供了 TCP/IP、HTTP、FTP、SMTP、POP3 及 SSL/TLS 支持可直接用于构建客户端与服务端网络应用。资源共 839 个文件压缩包仅 4.98MB以 Pascal 源文件.pas、组件包工程.dpk、设计期包.bpl、编译配置.bdsproj及资源文件.rc/.res/.bmp为主便于源码阅读与重新编译安装目前已有 347 人学习下载。包内含 clear.bat、build.bat、makeres.bat 构建脚本以及 IndyCore、IndySystem、IndyProtocols 等系列工程能够帮助开发者在老版本 Delphi 中快速生成运行时包与设计期包完成组件注册借助这份资源开发者可省去自行收集散落源码的麻烦直接获得经过整理的 Indy 10.2.3 源码树和编译配置进而在 Delphi 72007 环境中使用 TIdTCPClient、TIdHTTPServer、TIdFTP、TIdSMTP 等常用组件提升网络应用开发效率。1. 还在用 Indy 10.2.3老 Delphi 项目绕不开的套接字底座Indy 10.2.3 这个版本号在很多维护型项目里不是随便能换的。团队老代码当年写在 Delphi 7/2007 时代TCP 通信、HTTP 接口、FTP 上传全挂在 TIdTCPClient、TIdHTTP 上。新版本 Indy 的接口把 IOHandler、编码、包管理全部重排过直接升级等于把几百处网络调用重写一遍。于是不少团队把 10.2.3 当成“标准件”锁在版本库里能编译、能跑、能维护。这篇文章就把这套资源怎么装进 IDE、怎么写最小客户端和服务端、以及最常踩的坑讲清楚。适合做遗留系统维护的 Delphi 开发者也适合刚接手老项目、需要快速把手头网络功能跑通的初学者。2. 装进 IDEIndy 10.2.3 的安装与组件注册资源包解压后第一眼看到一堆目录别急着往 IDE 里拖。先把包的组成弄清楚再决定是手工编译还是直接装 BPL。很多人一上来就把整个目录塞进 Library Path结果编译时单元互相覆盖报出一堆莫名奇妙的错误。2.1 一个发布包常见组成是什么Indy 10.2.3 的源码包通常按模块拆成几个子目录目录名可能略有出入但职责基本一致。下表是我拆过这类包后的通用结论目录 / 文件作用Lib/SystemIdGlobal 等最基础通用单元编译期必须最先找到Lib/Core底层套接字、TIdTCPClient、TIdTCPServer 等核心类Lib/SuperCoreIOHandler、Intercept、缓冲与线程辅助类Lib/Protocols上层协议实现HTTP、FTP、SMTP、POP3 等Packages/D7、D9、D10不同 IDE 版本对应的 .dpk 编译工程根目录或 Bin部分发布包会带预编译 DCU/BPL但跨版本不可靠这里要泼一盆冷水同是 10.2.3在 Delphi 7 下编出来的 DCU放到 Delphi 2010 里基本不能直接用。Delphi 编译器版本不同生成的 .dcu 格式和内部 RTL 接口都有差异直接复制 BPL 进新 IDE 是翻车重灾区。我一般建议绕开预编译文件用源码重编。源码的方式虽然多花几分钟但之后不会再被“DCU 版本不匹配”这种问题反复纠缠。2.2 编译前先配置库路径打开 IDE 的环境选项找到 Library PathDelphi 7 在 Tools Environment Options Library新版本在 Tools Options Environment Options Library把下面四个路径加进去。注意顺序System 要在最前面Core 其次Protocols 最后。Delphi 搜索单元是按路径顺序来同一个单元名出现在多个路径时先找到的先生效顺序颠倒可能把类型定位到错误的源文件。# 假设解压到 D:\ThirdParty\Indy10 # 下面四条路径逐条加进 IDE 的 Library Path D:\ThirdParty\Indy10\Lib\System D:\ThirdParty\Indy10\Lib\Core D:\ThirdParty\Indy10\Lib\SuperCore D:\ThirdParty\Indy10\Lib\Protocols路径是假设值实际以你解压的位置为准。加完后不要急着点确定先确认这些目录里确实有 .pas 文件。有些发布包把源码直接铺在根目录没有 System/Core 这样的子目录那只要把根目录加进去即可。接下来是编译顺序。Indy 分成几个运行时包包与包之间有依赖IndySystem 是基础IndyCore 依赖它IndyProtocols 依赖 Core。顺序反了会报“无法找到单元 IdGlobal.pas”或“依赖的包未安装”。进入 Packages 下对应 IDE 版本的目录按下面顺序编译cd D:\ThirdParty\Indy10\Packages\D7 # -B 表示全量重建-JL 表示生成运行时包BPL dcc32 -B -JL IndySystem10.dpk dcc32 -B -JL IndyCore10.dpk dcc32 -B -JL IndyProtocols10.dpk命令里的包名是常见命名实际包名可能带版本后缀例如 IndySystem10_D7.dpk以包内文件为准。如果你用的是 Delphi 2010 以上版本我一般不建议走命令行直接在 IDE 里打开 .dproj/.dpk用 Project Manager 逐个项目 Build 更稳。命令行适合 Delphi 7而且要先保证 dcc32.exe 在 PATH 里。编译运行时包之后还要编译并安装设计时包。设计时包负责把组件注册到 IDE 的组件面板常见文件名以 dcl 开头。先编译再安装dcc32 -B -JL dclIndyCore10.dpk dcc32 -B -JL dclIndyProtocols10.dpk然后在 IDE 菜单里打开 Component Install Packages点 Add 找到刚才生成的 dclIndyCore10.bpl 和 dclIndyProtocols10.bpl。安装成功后组件面板会多出 Indy Clients、Indy Servers、Indy IO Handlers 等页签。这里的关键点是只编译 dcl 包但不 Add 到 IDE组件面板不会有任何变化这是新手最容易忽略的一步。2.3 装完组件面板没有出现装完重启 IDE组件面板还是空的按下面几条逐个排查。确认 Add 的是 dcl 开头的设计时包不是运行时包。运行时包只提供类实现不注册组件。确认没有旧版 Indy 占用同名包。Delphi 7 自带 Indy 9面板上已经有一组 Indy Clients/Servers再装 Indy 10 时两者会并存但如果 IDE 报“Contains unit ... which is already loaded”说明有另一个 Indy 10 实例已经被加载需要先在 Install Packages 里移除旧包。确认 Library Path 里的路径是源码目录不是编译输出目录。曾见过把路径指向 DCU 输出目录结果 IDE 拿着旧的 .dcu 去编译始终加载不到新版组件。用代码验证最直接。新建一个工程在 uses 里引用 IdGlobal然后打印编译期版本常量uses IdGlobal; procedure TForm1.FormCreate(Sender: TObject); begin // 能编译并能显示数字说明 Library Path 生效 // IdBuildNumber 是编译期常量不同构建版本值不同 Self.Caption : Indy Build: IntToStr(IdBuildNumber); end;如果编译时提示找不到 IdGlobal.pas说明路径没配好或顺序不对。如果编译通过但运行报错再回头看包有没有装全。这套验证成本很低比在面板上反复拖组件快得多。3. 上手跑通TIdTCPClient 与 TIdHTTPServer 的最小可运行实现装好组件后先不要急着套业务写一个能连通的 Client 和 Server把 IOHandler、超时、编码这几个核心点摸清楚。Indy 10 和早期版本最大的区别是 IOHandler 被提到了核心位置所有的读写都通过 IOHandler它本身又是惰性创建的连接建立时才真正分配资源。3.1 客户端连一次、发一条、读一行下面的函数演示最常用的“连接-发送-读取-断开”完整回合。很多老项目里 TCP 自定义协议都是这个套路只是命令和响应格式不同。uses System.SysUtils, IdGlobal, IdTCPClient; function SendCommand(const AHost: string; APort: Integer; const ACmd: string): string; var LClient: TIdTCPClient; begin LClient : TIdTCPClient.Create(nil); try LClient.Host : AHost; LClient.Port : APort; LClient.ConnectTimeout : 3000; LClient.ReadTimeout : 5000; LClient.IOHandler.DefStringEncoding : IndyTextEncoding_UTF8; LClient.Connect; try LClient.IOHandler.WriteLn(ACmd); Result : LClient.IOHandler.ReadLn; finally LClient.Disconnect; end; finally LClient.Free; end; end;代码逻辑分三段创建并配置、连接并通信、断开并释放。Connect 之前不要碰 IOHandler它是连接建立后自动创建的提前访问会拿到 nil。ConnectTimeout 和 ReadTimeout 的单位都是毫秒ConnectTimeout 默认 0 表示无限等待局域网内建议设 3000跨网段可以放宽到 5000-8000ReadTimeout 表示等待对端数据的最大时间超过后抛 EIdReadTimeout 异常。DefStringEncoding 这里显式改成 UTF8否则老版本默认 ASCII中文会乱。ReadLn 是按换行符分割读取的文本读取方法适合行协议。如果你的协议是二进制格式比如“4 字节长度头 正文”可以先用 ReadBytes 读固定长度var LHead: TIdBytes; LBodyLen: Integer; begin // 读 4 字节定长包头 LClient.IOHandler.ReadBytes(LHead, 4, False); // 把包头转成整数再按长度读正文 LBodyLen : (LHead[0] shl 24) or (LHead[1] shl 16) or (LHead[2] shl 8) or LHead[3]; end;ReadBytes 的第二个参数是字节数第三个参数表示是否把数据追加到原缓冲区。这里设为 False 表示每次只取 4 字节。注意它不会自动处理粘包只是“阻塞式读满指定字节数”上层需要自己维护包头和正文的边界。3.2 服务端TIdHTTPServer 挂路由做一个最简单的 HTTP 服务端响应 /ping 和 404 两种情况。TIdHTTPServer 比 TIdTCPServer 封得更上层它已经帮你解析了 HTTP 请求行、请求头和请求体。type TForm1 class(TForm) procedure FormCreate(Sender: TObject); procedure FormDestroy(Sender: TObject); private FServer: TIdHTTPServer; procedure DoCommandGet(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo); end; procedure TForm1.FormCreate(Sender: TObject); begin FServer : TIdHTTPServer.Create(Self); FServer.DefaultPort : 8080; FServer.OnCommandGet : DoCommandGet; FServer.Active : True; end; procedure TForm1.DoCommandGet(AContext: TIdContext; ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo); begin if ARequestInfo.Document /ping then begin AResponseInfo.ContentText : {code:0,msg:pong}; AResponseInfo.ContentType : application/json; end else begin AResponseInfo.ResponseNo : 404; AResponseInfo.ContentText : {code:404,msg:no route}; end; end;OnCommandGet 不是在主线程里执行的。Indy 为每个连接分配一个独立线程在请求到达时回调一次。如果要在回调里更新界面不能直接改 Memo 或 Label要用 TThread.Synchronize 或 TThread.QueueDelphi 2009 以后可以配合匿名方法老项目还在 Delphi 7 的话就用 TIdNotify 或 PostMessage避免跨线程访问。ARequestInfo.Document 拿的是 URL 路径请求 /ping?x1 时 Document 是 /ping查询参数在 ARequestInfo.Params 里。AResponseInfo 是响应对象设置 ContentText 后组件会自动生成响应头不需要手工拼 HTTP 协议这也是 TIdHTTPServer 比 TIdTCPServer 省心的原因。3.3 超时、缓冲区和编码参数这三个参数基本决定了联调时是否抓狂。很多“时好时坏”的问题最后都落在参数配置上。参数类型典型默认建议ConnectTimeoutInteger0无限局域网 3000跨网 5000-8000ReadTimeoutInteger0 或 -1无限2000-10000按业务容忍度DefStringEncoding编码对象随版本通常 ASCII统一 UTF8RecvBufferSizeInteger0大文件传输可调到 32*1024SendBufferSizeInteger0大文件上传可调到 32*1024ReadTimeout 的语义是“单个读操作没有读到数据时的最大等待时间”不是整个报文读完的总超时。假设服务器分两次发送数据第一次在超时前到达第二次隔了很久才到Indy 会把两次都算作独立读操作各自等待一个 ReadTimeout。如果要控制整个报文的总时长需要自己在循环里计时。服务端和客户端都要设置编码单边设置只在单边生效。TIdHTTPServer 也有 IOHandler可以设置默认编码FServer.IOHandler.DefStringEncoding : IndyTextEncoding_UTF8;老版本默认编码偏 ASCII这是历史包袱不要依赖默认值。客户端的协议文档里如果写的是 GBK就设置对应编码如果两边都是你控制的直接统一 UTF8 最省事。4. 避坑与常见问题Indy 10.2.3 翻车现场老库的问题不在于功能不够用而在于错误信息太“黑匣子”。下面这五类问题基本覆盖了我在项目里遇到的大多数情况每一条都按现象、原因、解决三步拆开讲。4.1 现象连接正常发数据时偶发 Unknown socket error 10038一个客户端程序运行一段时间后发送消息时随机抛EIdSocketError错误码 10038有时候重启程序又好了。原因是把 IOHandler 缓存到了成员变量里。连接断开后Indy 会释放套接字和 IOHandler 资源但缓存引用还指向已释放对象。再次调用 WriteLn 时底层实际操作了一个已经不存在的 socket所以返回 10038。这是典型的“连接生命周期管理不当”。解决方法是不要缓存 IOHandler每次连接建立后再通过 LClient.IOHandler 访问并在 try/finally 中做释放。Indy 的 Disconnect 内部会同步释放 IOHandler你不需要手动 Free。如果确实需要在多个地方复用连接要考虑用锁保护连接状态而不是假设连接永远存在。4.2 现象服务端收到一串乱码TIdHTTPServer 返回的 JSON 里中文变成问号或者 TIdTCPClient 发出去的字符串到对端变成“aÌ„”之类的字符。原因是文本编码不一致。Indy 10.2.3 的默认 DefStringEncoding 偏 ASCII高位字节不被保留所以中文这种多字节字符传到对端就丢了信息。HTTP 场景下响应头里如果没有明确 charset客户端可能又按 ISO-8859-1 去解码乱码就叠加了。解决方式是双边统一编码。客户端和服务端都显式设置 UTF8LClient.IOHandler.DefStringEncoding : IndyTextEncoding_UTF8; FServer.IOHandler.DefStringEncoding : IndyTextEncoding_UTF8;如果对端是 GBK 的系统就两边都设成 GBK不要一边 UTF8 一边默认。HTTP 响应里最好也设置 ContentType 的 charset例如AResponseInfo.ContentType : application/json; charsetutf-8;这样第三方客户端拿到响应头就知道按什么编码解析而不是去猜。4.3 现象HTTPServer 的 HTTP 请求卡死不返回用 TIdHTTP 去 Get 某个接口有时数据量一大就卡住几十秒后超时甚至永久挂起。原因大概率在 HTTP/1.1 的 keep-alive 机制上。服务器返回响应时如果没有 Content-Length也没有 chunked 编码Indy 只能通过“连接关闭”来判断响应结束。但 keep-alive 下连接不会主动关闭于是客户端一直等数据。另一个常见来源是服务器先回 100 Continue老版 10.2.3 对这类中间状态处理不够完善把 100 状态混进了正文解析。解决方式最直接的是在请求头里要求关闭连接同时设置 ReadTimeout 兜底LHTTP.Request.Connection : Close; LHTTP.ReadTimeout : 10000;如果还遇到 100 Continue 干扰可以尝试把 ExpectContinue 设为 False。10.2.3 的某些构建没有这个属性那就把协议版本降为 HTTP/1.0LHTTP.ProtocolVersion : pv1_0;HTTP/1.0 默认不启用 keep-alive连接用完就关响应结束边界反而清晰。代价是每次请求多一次握手开销但对稳定性要求高的场景值得。4.4 现象TLS 握手失败报 “SSL could not be initialized”TIdHTTPServer 或 TIdHTTP 启用 TIdSSLIOHandlerSocketOpenSSL 后访问 https 地址报初始化失败几乎没有任何日志细节。原因是 OpenSSL 动态库版本不对。Indy 10.2.3 通过固定文件名 libeay32.dll 和 ssleay32.dll 加载 OpenSSL。新版本 OpenSSL 1.1 开始把动态库改名为 libcrypto-1_1.dll 和 libssl-1_1.dll老代码按旧文件名找就找不到。这问题在 64 位服务器上尤其常见系统装了 64 位新版 OpenSSLDelphi 的 32 位程序又不能用结果两边对不上。解决方法是下载 OpenSSL 1.0.2 的 32 位版本把 libeay32.dll 和 ssleay32.dll 放到 exe 同级目录。不要放在系统目录里避免被其它软件覆盖。放置位置优先级是exe 目录 当前工作目录 系统 Path。我把这两个 DLL 跟 exe 放在一起后SSL 初始化就稳定了。还有一个边界要提前知道10.2.3 年代的 SSLOptions.Method 枚举值有限对现代只开 TLS 1.2 的服务器兼容性一般。如果对接的是新的 https 接口建议评估升级到更高版本 Indy而不是死守 10.2.3。老库适合老系统新接口用新库。4.5 现象内存一直涨跑几天就吃满TIdHTTPServer 长时间运行后内存持续上升或者用 TIdHTTP 循环请求几千次后内存降不下去。原因是回调里创建的对象没有释放。Indy 的连接线程由线程池管理连接上下文、IOHandler、事件参数等都是组件自己创建并释放的但你在 OnExecute、OnCommandGet 里手工创建的 TStringList、TBytesStream、TIdMessage 等对象不在它的管理范围内不手动释放就会越积越多。解决方式是每个回调入口都用 try/finally 保护临时对象。以 TIdHTTP 循环请求为例for I : 0 to 9999 do begin LHttp : TIdHTTP.Create(nil); try LHttp.ReadTimeout : 5000; LHttp.Get(AURL); finally LHttp.Free; end; end;不要试图靠系统 GCDelphi 没有自动垃圾回收。另外要注意如果给 AResponseInfo.ContentStream 手动指定了流对象要确认组件是否会释放它。TIdHTTPServer 的 ContentStream 释放策略在不同版本里不完全一致最稳妥做法是在回调里一次性创建流、赋值、并让组件在回应结束后负责释放拿不准时就用 AResponseInfo.ContentText 而非 ContentStream避免流对象生命周期纠缠。5. 进阶调试用 TIdLogFile 和回环测试把网络读写看清最后一次联调时先把“数据到底长什么样”看清楚再动手。Indy 10 自带一个经常被忽略的日志组件 TIdLogFile可以把它挂到 IOHandler 的 Intercept 上把每次网络读写的行为记录到文件里。uses IdLogFile, IdTCPClient; var LLog: TIdLogFile; begin LLog : TIdLogFile.Create(nil); LLog.Filename : C:\Logs\tcp_client.log; LLog.LogTime : True; LClient.IOHandler.Intercept : LLog; end;LogTime 会在每条记录前打时间戳用于对照卡顿发生的时间点。挂上后WriteLn、ReadLn、ReadBytes 这些操作都会记录到文件收发内容能看到最原始形态。服务端同理在 TIdTCPServer 的 OnConnect 事件里给当前连接的 IOHandler 挂 Intercept。这个思路比到处写 ShowMessage 高效得多也更容易定位“数据到底发没发出去、对面到底回了什么”。如果不想看日志文件还可以做纯本机回环测试。客户端连 127.0.0.1端口选 12000 以上的高位端口在同一台机器上把服务端跑起来。这样可以隔离防火墙策略和网络丢包的影响。回环通了再换真实 IP问题定位范围缩小一大半。如果只是验证端口转发逻辑Indy 自带 TIdMappedPortTCP几十行代码就能把一个端口的数据转发到另一个端口用来排查网络链路问题非常方便。沿用这个思路我后来的项目习惯是任何网络模块第一版写完不急着接对方联调先本地搭一个最小服务端用 TIdLogFile 把请求报文全量记录下来自己先检查一遍协议格式再做对接。这样做的原因是联调时对方往往没有能力帮你抓包你自己先把报文搞清楚了对接时才能直接指出“你的包头长度字段多算了 2 字节”这类问题而不是猜来猜去。从那以后我每次接触陌生协议都会强制自己走一遍“日志 回环”流程哪怕是一个只有两三个交互的小模块也不跳过。希望这个习惯对你也有用。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
