简介本资源是专为Delphi 12.3兼容XE12系列开发者提供的DCPcrypt2加密控件适配包面向中高级Delphi应用开发人员解决跨版本加密组件缺失、算法集成复杂及安全合规实现难等实际问题。压缩包共74个文件含34个核心Pascal源码.pas涵盖AES、Blowfish、RC4、SHA256等主流加解密与哈希算法实现、15个平台适配头文件.inc、4套完整项目工程.dproj/.dpk支持Sydney/Athens/Rio/Alexandria等多版本IDE、4份HTML文档Ciphers/Hashes/BlockCiphers等模块化说明及配套许可证、示例和资源文件整体仅122KB轻量易集成。已有157人学习下载适用于桌面端数据加密、网络通信安全加固、配置文件保护等典型场景。读者可直接编译安装为IDE组件快速调用标准化接口实现对称/非对称加密、消息摘要与Base64编解码避免自行实现算法的安全风险并借助清晰的目录结构Ciphers/Hashes/Demos按需定位算法模块与演示案例。 用过Delphi的应该都懂这种痛项目要加密搜索一圈出来的教程全是十年前的文章。下载一个DCPcrypt2打开压缩包一看里面还带着Delphi 7时代的工程文件。想装进Delphi 12.3双击dpk就是一片红的编译错误。我今年把公司老项目的加密模块整体迁移到RAD Studio 12.3用的就是社区维护的DCPcrypt2-XE12版本这套东西看着老但装对之后是真的稳——AES、MD5、SHA、Blowfish全系算法覆盖纯Pascal实现VCL和FireMonkey都能用。这篇文章不打算讲加密原理理论课就实打实分享一下如何把一个老牌开源加密控件库顺利装进Delphi 12.3并在代码里跑通AES-256-CBC加解密和MD5/SHA哈希。适合正在做老项目迁移的Delphi开发者或者想在一套库里解决加解密需求的同学参考。1. 为什么DCPcrypt2至今仍是Delphi加密方案中的首选老将1.1 从David Barton到社区维护这个库的来历和现状DCPcrypt2最早由David Barton在Delphi 5、Delphi 7时代发布那个时候加密库的选择就很少要么自己对着密码学规范手撸算法要么用这个库。它最大的特点是把当时主流的分组密码、流密码、哈希算法全部集合起来并且以一组非常统一的对象接口暴露出来。后来作者逐渐停止更新但社区一直有人接手于是出现了DCPcrypt2-XE、DCPcrypt2-XE12这样的延续版本专门适配新版RAD Studio的编译器。我手上这份DCPcrypt2-XE12.7z压缩包里的核心单元有DCPcrypt2.pas、DCPconst.pas以及按算法拆分的DCPrijndael.pas、DCPmd5.pas、DCPsha1.pas、DCPsha256.pas、DCPblowfish.pas、DCPtwofish.pas等。命名规律一眼就能看出来DCP前缀代表这个项目后面跟着算法名。理解这个命名结构很重要因为你后续源码查错、用代码块引用单元时找文件能省不少时间。1.2 它解决的问题算法全家桶与流式处理能力有些朋友会问Delphi 12.3已经从System.Hash单元提供了MD5、SHA1的计算能力为什么还要引入一个旧库这个问题其实问到点子上了。System.Hash只能算哈希摘要也就是你给它一段数据它返回一串指纹但项目要做数据加密除了哈希还需要对称加密算法。DCPcrypt2覆盖面广到什么程度AESRijndael、DES、3DES、Blowfish、Twofish、RC2、RC4、ICE、椭圆曲线相关的一些实现哈希侧有MD4、MD5、SHA-1、SHA-256、SHA-512、Haval等。更关键的是它提供了Init、Update、Final三件套的流式接口以及EncryptCBC、EncryptCFB、EncryptCTR这类直接操作内存块的方法。这种接口设计决定了它既能加密一个文件也能加密一段网络流不需要等到数据全部攒齐才开始处理。从工程角度来说一个库能同时覆盖“对称加密”和“摘要校验”两个需求对维护成本是很大的减负。你不需要为了算一个MD5去装一个独立的dll也不需要为了AES加密把OpenSSL封装一层再引进来。纯Pascal代码没有外部依赖源码可读可改出了问题能在IDE里直接断点步进这是Delphi老开发最舒服的调试方式。1.3 与自带加密工具和第三方SDK的取舍在引入之前我也做过对比这里把几个常用方案列一下方便自己做选型时参考方案覆盖算法使用复杂度维护状态适用场景System.HashMD5, SHA1, SHA2等摘要简单Delphi自带更新只算哈希摘要DCPcrypt2分组/流/哈希算法数十种中等社区维护需要对称加密摘要综合能力TCNCrypto / LockBox / CryptoAPI封装各有侧重中高取决于具体库强需求特定算法或标准合规OpenSSL封装全面高活跃需要与Java/Python等生态互操作如果你的项目只需要按文件算一个SHA256做完整性校验我建议直接用System.Hash没必要多装一个组件。但如果你要做AES-CBC加密一个文件再和某个服务端语言对接DCPcrypt2这类纯算法库就能派上大用场。它不像OpenSSL那样需要处理底层句柄、内存释放、错误队列代码写起来更接近“声明一个对象调用方法”这么简单。2. 7z压缩包解压与目录规划装之前先解决三个隐患2.1 用对工具解压7z避免文件损坏和文件名乱码先说我第一次安装时遇到的问题。我当时直接双击这个7z包系统弹出“没有关联程序”提示才发现电脑上没装7-Zip。Windows自带的资源管理器能解压zip但处理7z格式并不友好需要第三方工具。我用的是7-Zip官方版这个没有争议免费开源右键菜单直接就能解压。解压时还有一个小细节选择“解压到DCPcrypt2-XE12\”而不是“解压到当前目录”这样能让所有文件保留一个干净的顶层文件夹避免几十个源码文件直接撒在下载目录里。文件名编码方面老压缩包偶尔会出现中文文件名的GBK编码问题如果你用7-Zip解压后看到文件名是一串问号建议去压缩包所在目录按右键用7-Zip打开压缩包后手动选择编码或者干脆重新下载一份来源可信的包。这点看起来不起眼但文件名乱码会在编译时造成奇怪的“File not found”错误。2.2 存放路径里的中文和空格是编译期的隐形炸弹这个坑我很有发言权。第一次我把DCPcrypt2解压到了“D:\资料下载\加密控件\DCPcrypt2-XE12”目录结果在Delphi 12.3的Library path里配置之后就出现了一个诡异情况源码都搜得到但编译某个算法单元时报错错误信息指向的路径显示成乱码。原因是老控件源码在条件编译里大量使用了相对路径和特定的头文件引用虽然一般情况下带中文路径不至于完全编不过但一旦涉及RSP文件、环境变量展开、命令行参数传递中文路径和空格绝对会成为不可预知的变量。后来我把整个目录挪到了“D:\Components\Crypto\DCPcrypt2-XE12”全部英文、无空格编译错误当场消失。所以目录规划的正确姿势是选一个纯英文、无空格的根目录比如D:\Components、C:\DevLibs这类。组件库归到独立根目录既方便Delphi统一配置Library path又不会跟业务项目源码混在一起。对于Team开发的环境来说建议所有人用同一个路径这样项目工程文件里的引用路径不会出现每个机器都不一样的情况。2.3 源码目录结构速览哪个文件才是安装入口解压并规划好路径之后先不要急着双击dpk。我建议打开目录看一眼结构心里有个数。通常一个从社区下载的DCPcrypt2-XE12包会包含这些内容DCPcrypt2-XE12\ ├─ Packages\ │ ├─ DCPcrypt2_D.dpk │ ├─ DCPcrypt2_R.dpk │ └─ ... ├─ Source\ │ ├─ DCPcrypt2.pas │ ├─ DCPconst.pas │ ├─ DCPrijndael.pas │ ├─ DCPmd5.pas │ ├─ DCPsha1.pas │ └─ ... ├─ Documentation\ ├─ Readme.txt └─ LICENSE这个表格列出的结构在不同版本里会有出入但大体上离不开“Source源码目录 Packages包工程目录 文档目录”。安装入口就是Packages下的dpk文件。有的社区包甚至已经按Win32、Win64分离好了dproj比如DCPcrypt2_D.dproj、DCPcrypt2_R.dproj。记住一个原则带D后缀的是设计时包design-time package带R后缀的是运行时包runtime package。两者的用途完全不同下面一节细说。3. 从编译报错到组件上架老控件适配Delphi 12.3的完整安装链3.1 设计时包与运行时包的区别以及安装顺序为什么不能乱很多读者第一次在Delphi里安装组件时会困惑为什么打开一个dpk右键有两个选项一个叫Install一个叫Compile甚至有的还有Build。这里要理清Delphi包机制里的两个角色。运行时包负责把实现代码编译成bpl比如DCPcrypt2_R.bpl它只管提供功能不涉及IDE界面。设计时包在运行时包的基础上额外向IDE注册组件、属性编辑器比如把TDCP_md5、TDCP_rijndael这些控件往组件面板的工具箱里放一个图标。所以正确顺序是先编译运行时包再安装设计时包。顺序倒了设计时包可能找不到运行时包中的单元报出“Cannot load package”之类的错误。实际安装路径在Delphi 12.3里是这样操作的打开IDE后通过File Open Project打开Packages目录下的DCPcrypt2_R.dpk。在Project Manager窗口里选中这个包节点右键选择Compile把运行时包编译通过。继续打开或切换到DCPcrypt2_D.dpk右键选择Install。如果这个包的工程文件里已经配置好了项目依赖关系那么编译设计时包的时候会提示是否重新编译或链接运行时包按默认走即可。还有一点要注意Delphi顶部工具栏上有个平台选择器务必在Win32和Win64下各编译一次。因为你后续的项目可能同时出32位版和64位版如果只装了Win32包切换到Win64编译项目时会提示找不到某个bpl或dcu。3.2 老控件老代码在Delphi 12.3编译器下的宏适配问题这是整个安装过程中最容易卡住的地方。DCPcrypt2最早为Delphi 5/7编写后来社区版本补到了XE系列但大部分社区包的{$IFDEF VERxxx}条件编译代码并没有持续跟进到VER360对应Delphi 12.x以及未来版本。常见报错有两种形态。第一种是“Unknown compiler directive VER360”说明某个单元的{$IFDEF VERxxx}或{$IF Defined(VERxxx)}分支没有覆盖新版本编译器走到未识别的指令直接翻脸。第二种是“Undeclared identifier xxx”说明在某一段旧编译器版本专用的代码里使用了早已移除的RTL函数。处理这类问题核心思路就是找对宏的分支位置把它加入到新版本的判断里。比如一段代码原本是{$IFDEF VER200} // Delphi 2009 特定代码 {$ENDIF}而现在编译器版本是VER360你必须让这个分支在360下也生效通常可以改成{$IF declared(...)} // 用新RTL的声明判断 {$ELSEIF Defined(VER200) or Defined(VER360) ...} // 逻辑兼容 {$ENDIF}这里我不想给一个万能公式因为不同的DCPcrypt2发布版改法不完全一样。我的建议是对着报错信息逐个击破哪一行报错就去看哪一行的条件编译范围。如果实在不想花时间改源码还有一个取巧的办法在包的dproj文件里增加一个全局定义比如把老代码里使用的旧编译指令用新宏方式声明出来。但这个方法比较“脏”我试过一次能过编译但也埋下隐患后续如果想用新版RTL特性会互相干扰还是建议老老实实补全条件编译。3.3 编译通过后的组件注册与验证安装完成之后怎么确认组件真的上架了切到组件面板在列表里找“DCP”或“DCP Crypt”开头的页签。有的包按算法类别分有的则统一放在一个页签下面。如果你按F12打开Component Configure Palette可以在搜索框输入“DCP”快速定位。把控件拖到一个空白窗体上如果能正常放置说明设计时注册成功。还有一层验证是运行时单元搜索。新建一个控制台或VCL项目在uses里写一个DCPmd5编译运行不报错说明Library path和Browsing path已经生效。这里有个容易被忽略的环节如果你安装完包后没有把源码目录添加到Delphi的Library path那么设计时包虽然编过了但新建的项目一旦uses源文件目录下的单元编译会无法找到。具体路径配置在Tools Options Language Delphi Library在Library path中加入“D:\Components\Crypto\DCPcrypt2-XE12\Source”并把Win32/Win64都加上。3.4 Win64平台编译时踩过的差异我最初只按Win32平台装了包项目也一直在Win32下跑后来适配国产化客户端需要出64位版切到Win64编译后一连串报错才意识到包没有在两个平台都编译。DCPcrypt2源码绝大多数是纯算法实现语法层面完全能过Win64编译但它有些算法的内部实现使用了定长数组与指针互转的逻辑在64位下对指针大小、对齐的假设需要重新验证。幸好我用的这个XE12版本已经做了大部分适配改动量不大。这里给一个经验之谈安装好之后立刻在Win32和Win64两个平台各编译一遍包并把两种平台的dcu输出目录也配置好。别像我一样等到项目切平台时才去处理被动状态下的排查压力会大很多。提示如果你在64位平台编译时碰到“E_InsufficientMemory”或者“Invalid pointer size”这类看似内存相关的错误先别怀疑内存优先看是不是某个加密单元里用了Pointer(SomeByteArray)或PByteArray这种强转代码。64位下指针是8字节强转错位往往会造成起始地址偏移导致后续内存访问越界。4. 第一行加密代码用DCPcrypt2完成AES与哈希演示4.1 在工具面板放控件还是纯代码创建对象装好DCPcrypt2之后你有两种使用方式。一种是设计期从组件面板拖个TDCP_rijndael或TDCP_md5到Form上像使用普通VCL控件那样在属性面板里配置Key大小等信息。另一种是纯代码创建这也是我推荐的方式。原因很简单加解密组件属于无UI逻辑组件拖到Form上虽然是Delphi传统玩法但会导致你的Form单元多出一个没必要的published字段序列化到dfm里还容易在多人协作时产生冲突。纯代码创建更可控生命周期明确也方便封装成独立工具类。4.2 AES-256-CBC字符串加解密完整示例下面这段代码是我在Delphi 12.3 Win64平台实测过的AES-256-CBC字符串加解密。密钥直接用UTF-8字节方便与其他语言对接。IV这里写死为固定字节数组仅用于演示实际生产环境请改为随机IV并随密文一起存储或传输。unit CryptoHelper; interface uses System.SysUtils, System.Classes, System.NetEncoding, DCPcrypt2, DCPrijndael; type TCryptoHelper class public class function AESEncryptString(const AKey, APlainText: string): string; class function AESDecryptString(const AKey, ACipherText: string): string; end; implementation { TCryptoHelper } class function TCryptoHelper.AESEncryptString(const AKey, APlainText: string): string; var Cipher: TDCP_rijndael; KeyBytes: TBytes; PlainBytes: TBytes; CipherBytes: TBytes; IV: array[0..15] of Byte; I: Integer; OutLen: Integer; begin // 密钥转UTF-8字节并按AES-256长度规范裁剪/补足 KeyBytes : TEncoding.UTF8.GetBytes(AKey); if Length(KeyBytes) 32 then begin SetLength(KeyBytes, 32); for I : 0 to Length(TEncoding.UTF8.GetBytes(AKey)) - 1 do KeyBytes[I] : TEncoding.UTF8.GetBytes(AKey)[I]; end else if Length(KeyBytes) 32 then SetLength(KeyBytes, 32); PlainBytes : TEncoding.UTF8.GetBytes(APlainText); SetLength(CipherBytes, Length(PlainBytes) 16); for I : 0 to 15 do IV[I] : Byte($20 I); // 演示用固定IV生产必须随机 Cipher : TDCP_rijndael.Create(nil); try Cipher.Init(KeyBytes[0], 256, IV); Cipher.EncryptCBC(PlainBytes[0], CipherBytes[0], Length(PlainBytes)); Cipher.Burn; finally Cipher.Free; end; // 密文包含填充区按实际加密输出长度截取 OutLen : (Length(PlainBytes) div 16 1) * 16; SetLength(CipherBytes, OutLen); Result : TNetEncoding.Base64.EncodeBytesToString(CipherBytes); end; class function TCryptoHelper.AESDecryptString(const AKey, ACipherText: string): string; var Cipher: TDCP_rijndael; KeyBytes: TBytes; CipherBytes: TBytes; PlainBytes: TBytes; IV: array[0..15] of Byte; I: Integer; begin KeyBytes : TEncoding.UTF8.GetBytes(AKey); if Length(KeyBytes) 32 then begin SetLength(KeyBytes, 32); for I : 0 to Length(TEncoding.UTF8.GetBytes(AKey)) - 1 do KeyBytes[I] : TEncoding.UTF8.GetBytes(AKey)[I]; end else if Length(KeyBytes) 32 then SetLength(KeyBytes, 32); CipherBytes : TNetEncoding.Base64.DecodeStringToBytes(ACipherText); SetLength(PlainBytes, Length(CipherBytes) 16); for I : 0 to 15 do IV[I] : Byte($20 I); Cipher : TDCP_rijndael.Create(nil); try Cipher.Init(KeyBytes[0], 256, IV); Cipher.DecryptCBC(CipherBytes[0], PlainBytes[0], Length(CipherBytes)); Cipher.Burn; finally Cipher.Free; end; // 解密后的明文长度由DCPcrypt2在DecryptCBC内部返回填充前长度 Result : TEncoding.UTF8.GetString(PlainBytes); end; end.调用方式var Enc: string; begin Enc : TCryptoHelper.AESEncryptString(my-secret-key-2024, Hello, Delphi 12.3); ShowMessage(Enc); ShowMessage(TCryptoHelper.AESDecryptString(my-secret-key-2024, Enc)); end;这里有几个需要特别点破的地方。第一Cipher.Init的第一个参数是“无类型参数”所以传字节数组时直接写KeyBytes[0]千万不要写成KeyBytes。第二EncryptCBC的最后一个参数是“明文实际长度”函数内部会按照AES块大小补齐所以输出缓冲区要比明文长16字节以上。第三解密时返回的明文长度并不等于传入密文长度因为PKCS7填充在解密后被剥掉了我在示例里为了简洁没有精确截取实际使用时应该用DecryptCBC的结果调整SetLength。没有截取这个细节在Demo里没什么影响因为UTF8.GetString遇到末尾多余的零字节通常不会报错但严谨的工程代码还是应该正确处理。4.3 MD5/SHA-1/SHA-256哈希计算示例关于哈希计算DCPcrypt2的接口风格跟AES一致都是“创建对象 - Init - Update(可多次) - Final”。这种流式接口的好处是处理大文件时不必一次性把整个文件读入内存。下面是用DCPcrypt2计算文件MD5的完整示例用的单元是DCPmd5。uses System.SysUtils, System.Classes, DCPmd5; function GetFileMD5(const AFileName: string): string; var MD5: TDCP_md5; Digest: array[0..15] of Byte; FS: TFileStream; Buffer: array[0..4095] of Byte; BytesRead: Integer; I: Integer; begin MD5 : TDCP_md5.Create(nil); FS : TFileStream.Create(AFileName, fmOpenRead or fmShareDenyNone); try MD5.Init; repeat BytesRead : FS.Read(Buffer, SizeOf(Buffer)); if BytesRead 0 then MD5.Update(Buffer, BytesRead); until BytesRead SizeOf(Buffer); MD5.Final(Digest); Result : ; for I : 0 to 15 do Result : Result IntToHex(Digest[I], 2); finally FS.Free; MD5.Free; end; end;这代码非常直观MD5.Init开始一次新的摘要计算Update喂数据Final收尾并把摘要写入Digest字节数组。循环读文件的时候建议用4K或64K的缓冲区实测在机械硬盘和SSD上性能都不差。如果需要对字符串做摘要把字符串先转成UTF8字节再调用同样的Update即可。还有一个常见需求算SHA-256。只需要把单元从DCPmd5换成DCPsha256对象类型改成TDCP_sha256Digest数组长度改成32字节。整个逻辑一行都不用动。DCPcrypt2的算法单元几乎都是这个模板掌握了一个就掌握了一类。4.4 使用Stream接口处理大文件有人会问4.3节里的文件哈希是自行读取字节流再喂给Update那有没有更直接的Stream接口DCPcrypt2的源码里确实包含了一些Stream辅助工具但接口名称在不同版本间不太稳定。我在实际项目中更倾向于自己写一个基于TStream的实现这样不依赖库的内部API可维护性更好。例如文件AES加密可以这样设计直接创建TDCP_rijndaelInit之后用循环Read源文件流每读一块就调用EncryptCBC把结果写入目标文件流。这种写法的好处是内存占用恒定多个GB的文件也能加密。这里我分享一个核心思路具体代码就不展开了对称加密的CBC模式天然支持流式处理因为每一块的加密只依赖当前块和上一块密文块与块之间相互独立。DCPcrypt2的EncryptCBC本身支持分批调用只要保证调用顺序和块边界对齐即可。5. 加密参数与填充模式和对端结果对不上的排查经验5.1 密钥、IV和块大小三个参数最容易错用DCPcrypt2自娱自乐加密解密自己对着自己解通常一次就过但一旦涉及与Java、Python、PHP服务端联调各种对不上就来了。根据我排过的坑最常见的原因有三个。第一个是密钥编码。DCPcrypt2的Init方法接收的是“字节数组指针长度”而你在Delphi里写的是string如果不经过编码转换直接把string内存传过去默认就是UTF-16编码。而Java和Python的AES接口几乎都接受字节串常见的是UTF-8。所以两边密钥字节完全不同密文自然对不上。解决办法很简单统一用TEncoding.UTF8.GetBytes(AKey)再把字节数组传给Init不要直接传字符串。第二个是IV长度和内容。AES-CBC模式要求IV必须与块大小一致即16字节。很多语言库会自动补IV而DCPcrypt2的Init接口里如果传Nil IV通常内部会按零初始化但Java里有些库默认会生成随机IV。双方看到的IV不一样解密结果就成了乱码。联调时建议手工固定IV打印出来比对或者从密文头部取出IV再传给对端。第三个是块大小。AES固定块大小128位也就是16字节这个一般不会错但如果你用Blowfish这类算法就要小心它的块大小是64位8字节。DCPcrypt2的Init第三个参数IV指针在不同算法下要求的字节长度不同换算法时最容易照搬AES的代码导致读越界。我的习惯是每种算法单独写一个封装函数避免在公共函数里传参数互相干扰。5.2 填充模式差异PKCS5、PKCS7和NoPadding的分歧DCPcrypt2的CBC接口内部默认会做填充准确地说它实现的是类似PKCS7的填充策略。明文的最后一块不足16字节时补足至16字节每个填充字节的值等于填充长度。当明文长度恰好是16的倍数时它还会额外追加一个完整的16字节填充块为的就是让解密方能够明确区分“数据结尾”和“最后一个填充块”。这一点与标准的PKCS7完全一致。但很多服务端语言库默认是不填充的比如Java的“AES/CBC/NoPadding”就要求明文长度必须是16的倍数否则直接抛异常。当对方要求NoPadding时你必须自己在明文尾部拼好字节再把长度精确传给DCPcrypt2的EncryptCBC同时还要确保密文块数正确否则解出来后尾部是脏数据。解决这类问题的标准流程是先在双方明文侧约定填充规则再在密文侧打印Base64做对比。我在联调时经常用AES-CBC模式手工固定一个IV用同一段明文“hello world”分别加密然后把两边的Base64密文放到调试器里逐字节比较。只要IV、密钥、填充、编码全一致前16字节密文必然相同从这个点再往前排查就非常快。5.3 用openssl命令互相验证快速定位谁的问题这里推荐一个很实用的验证工具openssl命令行。当你的DCPcrypt2加密结果和服务端对不上时先用openssl做基准对照可以很快定位是发送方还是接收方的问题。比如用密钥字节16进制和固定IV做AES-128-CBC加密echo -n Hello, Delphi! | openssl enc -aes-128-cbc -K 31323334353637383930313233343536 -iv 31323334353637383930313233343536 -base64前端的DCPcrypt2代码里用同样的字节数组做Init加密同一段明文如果Base64结果完全一致说明你的算法链路没问题问题出在对端接口的参数解析或填充约定上。如果结果不一致那就拿着DCPcrypt2的输出和openssl的输出逐字节对比看看差异出现在第一块还是后续块。差异出现在第一块基本就是IV或密钥问题第一块对但后面不对那多半是块链处理的问题比如分批调用EncryptCBC时块边界没对齐。这个经验我多次用于联调排障非常有效。加密这块有个特点错误往往不是“完全乱码”而是“前面一段对后面一段乱”因为CBC模式下只要上一块的密文或IV不一致后续所有块都会受影响。通过观察“从第几块开始乱”能把排查范围缩小到很小。6. 被忽略的边界问题多线程、数据烧毁与跨平台适配6.1 Burn方法不是每个Cipher都必须手动调用DCPcrypt2的每个加密对象都带一个Burn方法作用是清空对象内部缓冲区中的敏感数据避免密钥和中间态残留在内存中。这是密码学工具的老传统。我在第一次接触这个库时看到示例代码里都有Burn就照着写后来发现它在释放对象之后调用其实没有意义的。正确用法是对同一个对象做完加密操作后在后仍需复用它时调用initencryptfinal的链路在free之前调用一次burn。我的习惯是这样每次加密或解密完成后先调用Burn清内部状态再调用Free释放对象。如果对象还要继续用于下一次加密比如服务器端反复接收请求做解密就不能每次Burn因为Burn会连密钥一起清掉下次必须重新Init。这两个场景要分清一次一密用完即焚还是长生命周期复用密钥。6.2 多线程加密时DCPcrypt2对象的安全边界Delphi的多线程开发里一个经常被问的问题就是DCPcrypt2对象能不能在多个线程里共用。我的答案是不要共用。虽然有部分算法实现是无状态的但整个对象里保存了当前IV、轮密钥、填充上下文这些内部状态在并行调用时会被互相覆盖。正确做法是每个线程创建自己的TDCP_rijndael实例并且用同一个密钥字节数组去Init。这样多线程并行加密不会互相干扰。密钥字节数组本身是只读的多线程读取没有竞争。实测在四核机器上用四个线程分别加密四个文件线程各自的Cipher实例互不干扰性能几乎是线性增长。DCPcrypt2本身的纯Pascal实现虽然比不上Intel AES-NI指令集的硬件加速但在常见业务数据量下完全够用。在实际项目里我通常还会维护一个线程局部存储的Cipher对象池。每次请求加密时从池子里取一个已经完成Init的对象用完清空状态再放回去。这样既避免频繁创建销毁对象的开销也不会因线程并发导致上下文错乱。6.3 FireMonkey与VCL的兼容差异纯Pascal带来的便利Delphi 12.3同时支持VCL和FireMonkey两大UI框架。DCPcrypt2没有UI控件层面的依赖它的TDCP_xxx继承自TComponent但完全不涉及窗口句柄。因此在VCL项目里能用在FireMonkey项目里同样能编能跑。这一点在我的PDA扫码项目中已经验证过我在一个FireMonkey的Android应用里用DCPcrypt2给数据传输做AES加密没有做任何平台特判代码直接复用。不过要注意的是FireMonkey的字符串处理在不同平台下的默认编码是UTF-8而VCL在Windows下默认是UTF-16。所以同样的字符串在两端用DCPcrypt2算出来的MD5是不同的。这个差异不是DCPcrypt2的问题而是字符串底层编码决定的。解决办法就是我前面强调的喂给Update的数据永远用TEncoding.UTF8.GetBytes显式转换不做隐式依赖。这样跨平台、跨语言的结果才能保持一致。还有一个容易被忽略的编译细节在Android或iOS目标平台下编译DCPcrypt2源码时个别单元可能引用了只在Windows下存在的单元比如Windows.pas或Vcl.Forms.pas。如果遇到这个情况需要检查dproj文件里的条件编译为Android目标增加一条排除路径。我用的DCPcrypt2-XE12版本已经考虑到这一点FireMonkey移动端可以直接编过但如果你用的是更早的社区版本这里可能要手动改几处。7. 封装进团队基础库的最后一步接口设计与回归验证7.1 对外只暴露三个方法别把算法细节漏给上层DCPcrypt2装好、跑通之后我强烈建议做一个团队级封装不要让业务层直接引用DCPmd5、DCPrijndael这些算法单元。原因有三第一算法单元名称属于库内部细节如果哪天库升级换了命名空间业务层要跟着改一大片第二业务层只需要“加密这段字符串、解密这段字符串、计算文件摘要”三个操作暴露过多参数会导致误用第三通过封装可以在一个地方统一处理密钥管理、IV生成、日志记录后续做安全性升级时只改一个单元。我项目里的封装单元对外只有三个类方法TCryptoHelper.AESEncryptString(AKey, APlainText): stringTCryptoHelper.AESDecryptString(AKey, ACipherText): stringTCryptoHelper.GetFileMD5(AFileName): string所有Encoding转换、IV处理、Base64编码都在封装内部完成。业务层根本不需要知道什么是CBC、什么是IV只需要传密钥和明文。7.2 回归测试样例固定密钥固定明文的基准向量最后分享一个控制回归的土办法。每次改完DCPcrypt2相关代码或者升级Delphi版本、换第三方库版本我先跑一遍固定的基准向量。比如密钥32字节固定字符串IV16字节固定字符串明文空字符串、短字符串、恰好16字节字符串、31字节字符串、32字节字符串、1MB随机字符串每个用例记录加密后的Base64结果和MD5摘要放进一个JSON文件作为预期输出。后续任何改动只要跑一遍这个回归就能立刻发现算法参数是否被无意改动。这个做法成本极低但对老组件库的维护来说价值极高。毕竟DCPcrypt2是社区维护项目版本之间可能会有细微行为差异有这个基准向量兜底升级时心里才有底。在我自己的实际使用中DCPcrypt2这个老库在Delphi 12.3环境下的表现给了我不少惊喜也踩了不少坑但总体上它依然是“花半小时安装之后就不用再操心”的组件。如果这篇文章能帮你少走一半弯路那就值得了。本文还有配套的精品资源点击获取