本文还有配套的精品资源点击获取简介这个Delphi AES加解密组件支持128/192/256位密钥用标准CBC模式和PKCS#7填充Delphi 10.1 Berlin的32位和64位都编译通过了。里面核心逻辑在ElAES.pas和JDAESExtend.pas两个单元里封装得比较干净调用简单也方便后续维护。配套带了一个带界面的测试工程AesTest.dpr可以手动输密钥、IV、明文实时看加密结果验证跨平台一致性特别方便。Java端给了AESTest.java参考实现跟常见Java后端比如Spring Boot用Cipher类能直接对接PHP那边也验证过openssl_encrypt/decrypt函数能解出来不用改算法参数。Readme.txt里写了常见问题、调用示例、密钥IV格式要求还有不同Delphi版本适配说明。untTest.pas这些单元做了多版本兼容处理从老版本迁移到新Delphi也不容易出错。目录里JAVA和Delphi文件夹分开整理.gitignore和.git相关文件也预留好了适合直接集成进团队项目。1. 项目概述为什么一个“能对得上号”的AES组件比写一百行加密代码还难在Delphi老项目维护、混合架构系统对接、或者需要把桌面客户端安全接入Java/PHP后端的场景里我见过太多次这样的现场开发同学兴冲冲写完Delphi端AES加密一联调——Java后端解出来全是乱码换PHP试openssl_decrypt返回false再查文档发现两边都号称“AES-CBC”但密钥长度、填充方式、IV生成逻辑、字节序处理……全在各自理解的平行宇宙里运行。最后不是改Java就是重写Delphi甚至临时加个中间转换服务成本远超预期。这个Delphi AES组件核心价值就四个字开箱即对。它不是又一个“理论上标准”的实现而是经过真实跨平台联调锤炼出来的“协议级兼容方案”。关键词“Delphi AES”、“Java互通”、“PHP加密兼容”不是宣传话术是每一行代码背后踩过的坑堆出来的结果。它默认采用AES-128-CBC PKCS#7填充 16字节固定IV可配置 UTF-8明文编码 Base64输出这一组合恰好是JavaCipher.getInstance(AES/CBC/PKCS5Padding)注意Java的PKCS5Padding实际等效PKCS#7、PHPopenssl_encrypt($data, AES-128-CBC, $key, OPENSSL_RAW_DATA, $iv)配合Base64编解码最常使用的默认行为交集。这不是巧合是刻意收敛。它面向三类人一是Delphi老项目要快速接入现代后端的维护者不用啃Java密码学API二是Java/PHP后端团队终于不用为Delphi客户端单独写适配层三是技术负责人需要一套经得起审计、版本可控、文档齐全的加密基础模块。它不追求炫技比如支持GCM模式或硬件加速只解决最痛的“互通”问题——就像一把精准校准过的螺丝刀不华丽但拧紧每一颗跨语言的螺丝时手感扎实绝不打滑。2. 整体设计与思路拆解为什么是CBCPKCS#7为什么密钥必须是UTF-8字节数组2.1 模式与填充的选择放弃ECB拥抱CBC但绝不碰GCMAES本身是块密码算法必须搭配工作模式使用。项目坚定选择CBCCipher Block Chaining模式原因非常务实ECBElectronic Codebook被彻底排除它把每个16字节块独立加密相同明文块产生相同密文块会暴露数据结构比如一张纯色图片加密后仍能看到轮廓。这在任何生产环境都是安全红线连测试都不该用。CBC是事实标准Java的Cipher.getInstance(AES/CBC/PKCS5Padding)、PHP的openssl_encrypt默认AES-CBC、.NET的AesCryptoServiceProvider默认也是CBC。它是跨语言生态里兼容性最高、文档最全、开发者最熟悉的工作模式。GCMGalois/Counter Mode被主动放弃虽然GCM提供认证加密AEAD安全性更高但它在Delphi原生支持弱需额外依赖OpenSSL动态库或第三方组件且Java/PHP的GCM实现细节如nonce长度、tag长度、字节序差异极大。一次联调可能耗掉两天——而本项目目标是“当天集成当天跑通”。所以安全性和易用性的平衡点落在了CBC上。只要IV随机且不复用CBC的安全性对绝大多数业务场景已足够。填充方式锁定PKCS#7在Java中常被误称为PKCS5Padding实则二者在128位块长下完全等效理由同样直白- 它是唯一被所有主流平台严格实现的标准填充。PKCS#5专为DES设计8字节块PKCS#7是其通用化版本适用于任意块长而AES块长固定为16字节故二者在此场景下行为一致。- 其他填充如ZeroPadding补0在PHP中需手动处理Java无原生支持ISO10126已淘汰。PKCS#7的填充字节值等于填充长度如缺3字节则填0x03 0x03 0x03解密后校验简单可靠出错即报杜绝静默失败。提示ElAES.pas中TPKCS7Padding类并非简单循环填充而是严格按RFC 5652实现先计算需填充字节数padLen 16 - (Length(plain) mod 16)再生成padLen个Byte(padLen)填充字节。这确保了与JavaCipher.doFinal()和PHPopenssl_decrypt()的填充验证逻辑100%一致。2.2 密钥与IV的“标准化”处理字符串不是密钥字节才是这是跨平台互通最容易翻车的环节。Delphi里一个string变量在不同版本、不同编译选项下内存布局可能完全不同AnsiString vs UnicodeString vs UTF8String。而Java的SecretKeySpec、PHP的openssl_encrypt函数接收的密钥参数本质都是原始字节数组byte[]。本组件强制规定-密钥Key必须是UTF-8编码的字节数组。用户传入的string密钥如MySecretKey123组件内部会调用TEncoding.UTF8.GetBytes(KeyStr)转为字节数组。若密钥长度不足16/24/32字节对应AES-128/192/256则进行零填充Zero-Pad若超过则截断Truncate。此逻辑与Java的SecretKeySpec构造行为完全一致Java中new SecretKeySpec(keyStr.getBytes(UTF-8), AES)。-初始化向量IV同理。必须是16字节AES块长的字节数组。UI测试工程中输入的IV字符串如1234567890123456会被TEncoding.UTF8.GetBytes转为字节并严格取前16字节。若用户想用随机IVJDAESExtend.pas提供了GenerateRandomIV: TBytes方法底层调用Windows CryptoAPICryptGenRandom或Linux/dev/urandom确保密码学安全。注意绝不能直接用string的Length()当密钥长度Length(密钥)在Delphi中返回字符数2但UTF-8编码后是6字节。ElAES.pas中所有密钥处理均绕过string长度陷阱直操作TBytes。2.3 封装哲学两个单元两种职责拒绝大杂烩代码组织体现清晰的分层思想-ElAES.pas核心算法引擎。只做一件事——AES加解密。它不关心UI、不处理字符串编码、不生成随机数是一个纯粹的、可单元测试的密码学工具。暴露的接口极简pascal function Encrypt(const PlainText, Key, IV: TBytes): TBytes; overload; function Decrypt(const CipherText, Key, IV: TBytes): TBytes; overload;所有参数均为TBytes输入输出无歧义。这是与Java/PHP交互的“协议层”稳定如磐石。JDAESExtend.pas应用胶水层。它站在ElAES.pas之上解决实际开发中的“脏活累活”提供EncryptString/DecryptString方法自动处理UTF-8编码、Base64编解码、密钥/IV字符串到TBytes的转换封装GenerateRandomIV和DeriveKeyFromPassword基于PBKDF2-HMAC-SHA256用于从口令派生密钥提供IsValidKeyLength等校验方法提前拦截非法密钥长度针对Delphi版本差异如XE2以下无TBytesXE7支持System.NetEncoding做了条件编译兼容。这种分离让ElAES.pas可以被嵌入无VCL的控制台程序、服务进程而JDAESExtend.pas则服务于常规GUI应用。升级算法时只需动ElAES.pas扩展功能时不影响核心稳定性。3. 核心细节解析与实操要点从Readme到代码那些没写在注释里的关键3.1 Readme.txt不是摆设密钥格式、IV要求、Base64细节全在这里很多团队忽略Readme.txt直到联调失败才打开。本项目的Readme.txt是联调手册而非代码说明。其中最关键的三条直接决定成败密钥字符串必须是ASCII或UTF-8可表示的文本错误示例密钥中文→ UTF-8编码为0xE5 0xAF 0xB9 0xE9 0x92 0xA56字节不足16字节组件会零填充至16字节。但Java端若用密钥.getBytes()默认平台编码如GBK得到的是0xC3 0xDC 0xC2 0xEB4字节两者完全不匹配。正确做法密钥统一用ASCII字符如A1b2C3d4E5f6G7h8或明确约定双方使用UTF-8编码。Readme.txt中强调“密钥字符串请确保在Java端用keyStr.getBytes(UTF-8)获取字节数组”。IV必须是16字节且两端必须完全一致Readme.txt明确警告“IV不是盐Salt不可随机生成后丢弃必须由一方生成并安全传递给另一方”。测试工程UI中IV输入框默认显示000000000000000016个ASCII 0其UTF-8编码正是16个0x30字节。Java端必须用0000000000000000.getBytes(UTF-8)生成IV字节数组而非Arrays.fill(iv, (byte)0)后者生成16个0x00完全不同。Base64编码必须使用标准URL安全变体不必须用标准Base64PHP的base64_encode()和Java的Base64.getEncoder().encodeToString()均生成标准Base64含、/、。Delphi的TNetEncoding.Base64.EncodeBytesToStringXE7或EncodeString旧版也默认标准。Readme.txt特别指出“禁用URL安全Base64无//用-/_替代否则Java/PHP无法识别”。这是因在HTTP GET中会被解码为空格但本组件设计为API Body传输故坚持标准。3.2untTest.pas的多版本适配如何让一份代码在Delphi XE2到11 Alexandria都编译通过Delphi版本碎片化是现实。untTest.pas测试窗体单元是适配策略的集中体现TBytes兼容性XE2引入TBytes但XE2以下只有array of byte。untTest.pas通过条件编译pascal {$IFDEF DELPHIXE2_UP} type TByteArray TBytes; {$ELSE} type TByteArray array of byte; {$ENDIF}所有涉及字节数组的操作均基于TByteArray屏蔽底层差异。字符串编码API差异XE7引入System.NetEncoding之前用SysUtils或第三方库。untTest.pas封装pascal function StringToBytes(const S: string): TByteArray; begin {$IFDEF DELPHIXE7_UP} Result : TNetEncoding.Base64.DecodeStringToBytes(S); {$ELSE} Result : DecodeString(S); // 调用旧版DecodeString {$ENDIF} end;VCL控件属性变化如TEdit.Text在XE10支持Text属性直接赋值Unicode旧版需UTF8Encode。untTest.pas中所有UI交互均通过GetEditText/SetEditText方法抽象内部根据版本自动处理编码转换。这种“版本门面模式”让核心加密逻辑ElAES.pas完全不受影响升级Delphi时只需更新untTest.pas的适配层而非重写整个加密模块。3.3 Java端AESTest.java的“反向验证”设计它不是示例是测试桩AESTest.java不是教你怎么用Java加密而是精确模拟Delphi端的行为用于验证Delphi输出是否正确。其关键设计点密钥处理private static byte[] getKey(String keyStr) throws Exception { return keyStr.getBytes(UTF-8); }—— 与ElAES.pas完全一致。IV处理private static byte[] getIV(String ivStr) throws Exception { return ivStr.getBytes(UTF-8); }—— 同样UTF-8编码然后取前16字节Arrays.copyOf。填充与模式Cipher cipher Cipher.getInstance(AES/CBC/PKCS5Padding);—— 注意PKCS5Padding在Java中对AES即PKCS#7。Base64使用java.util.Base64Java 8或org.apache.commons.codec.binary.Base64兼容旧版确保与Delphi输出可比。运行AESTest.java时它会读取test_vectors.txt由Delphi测试工程生成对每组明文、密钥、IV执行加密将结果与Delphi输出的Base64密文比对。只有全部通过才证明Delphi实现正确。这是一种“契约测试”而非单向示例。4. 实操过程与核心环节实现从零开始手把手搭建一次跨平台加密链路4.1 Delphi端三步集成五分钟搞定假设你有一个现有Delphi项目Delphi 10.4 Sydney需要添加AES加密功能。以下是精简后的集成路径第一步添加单元引用将ElAES.pas和JDAESExtend.pas复制到你的项目目录如lib/crypto/。在主窗体或业务单元的uses子句中加入uses ..., ElAES, JDAESExtend;无需修改项目设置无DLL依赖纯Pascal代码。第二步编写加密逻辑以登录密码加密为例procedure TForm1.Button1Click(Sender: TObject); var PlainText, Key, IV, CipherText: TBytes; EncryptedStr: string; begin // 1. 准备明文用户密码 PlainText : TEncoding.UTF8.GetBytes(Edit1.Text); // Edit1.Text是用户输入的密码 // 2. 准备密钥和IV从配置或服务端获取 Key : TEncoding.UTF8.GetBytes(MyAppSecretKey2024); // 16字节密钥 IV : TEncoding.UTF8.GetBytes(1234567890123456); // 16字节IV // 3. 加密核心调用 CipherText : Encrypt(PlainText, Key, IV); // 来自ElAES.pas // 4. 转为Base64字符串发送给后端 EncryptedStr : TNetEncoding.Base64.EncodeBytesToString(CipherText); Memo1.Lines.Add(Base64密文: EncryptedStr); end;实测心得Encrypt函数执行时间在毫秒级i7 CPU上1KB数据约0.2ms无性能瓶颈。若需频繁加密可将Key和IV预计算为TBytes变量避免每次调用TEncoding.UTF8.GetBytes。第三步解密验证服务端返回密文时procedure TForm1.Button2Click(Sender: TObject); var CipherText, Key, IV, PlainText: TBytes; DecryptedStr: string; begin // 1. 从服务端获取Base64密文 CipherText : TNetEncoding.Base64.DecodeStringToBytes(Edit2.Text); // Edit2.Text是Base64密文 // 2. 使用相同密钥和IV Key : TEncoding.UTF8.GetBytes(MyAppSecretKey2024); IV : TEncoding.UTF8.GetBytes(1234567890123456); // 3. 解密 PlainText : Decrypt(CipherText, Key, IV); // 来自ElAES.pas // 4. 转为字符串 DecryptedStr : TEncoding.UTF8.GetString(PlainText); Memo1.Lines.Add(解密明文: DecryptedStr); end;4.2 Java后端Spring Boot Controller无缝对接Java端无需任何额外库JDK 8内置。假设Spring Boot Controller接收JSON{ username: user1, password_encrypted: U2FsdGVkX1...Base64密文 }Controller代码PostMapping(/login) public ResponseEntity? login(RequestBody LoginRequest req) { try { String encrypted req.getPasswordEncrypted(); byte[] cipherBytes Base64.getDecoder().decode(encrypted); // JDK 8 // 密钥和IV必须与Delphi端完全一致 byte[] key MyAppSecretKey2024.getBytes(UTF-8); byte[] iv 1234567890123456.getBytes(UTF-8); // AES/CBC/PKCS5Padding解密 Cipher cipher Cipher.getInstance(AES/CBC/PKCS5Padding); SecretKeySpec secretKeySpec new SecretKeySpec(key, AES); IvParameterSpec ivParameterSpec new IvParameterSpec(iv); cipher.init(Cipher.DECRYPT_MODE, secretKeySpec, ivParameterSpec); byte[] plainBytes cipher.doFinal(cipherBytes); String plainPassword new String(plainBytes, UTF-8); // 后续验证逻辑... return ResponseEntity.ok(Login success); } catch (Exception e) { log.error(Decryption failed, e); return ResponseEntity.badRequest().build(); } }关键参数验证表确保两端一致参数Delphi端 (ElAES.pas)Java端 (Cipher.getInstance)是否必须一致算法AESAES是模式cbcCBC是填充PKCS7PKCS5Padding是AES下等效密钥编码UTF-8keyStr.getBytes(UTF-8)是IV编码UTF-8ivStr.getBytes(UTF-8)是Base64TNetEncoding.Base64Base64.getDecoder()是4.3 PHP后端一行openssl_decrypt搞定PHP 7.1 内置openssl扩展无需安装。假设接收POST参数password_encrypted?php $encrypted_base64 $_POST[password_encrypted] ?? ; if (empty($encrypted_base64)) { die(Missing encrypted password); } // Base64解码 $cipher_bytes base64_decode($encrypted_base64); // 密钥和IV必须与Delphi完全一致 $key MyAppSecretKey2024; // 16字节 $iv 1234567890123456; // 16字节 // AES-128-CBC解密OPENSSL_ZERO_PADDING 表示使用PKCS#7填充PHP 7.1自动处理 $plain_bytes openssl_decrypt( $cipher_bytes, AES-128-CBC, $key, OPENSSL_RAW_DATA, $iv ); if ($plain_bytes false) { error_log(PHP decrypt failed: . openssl_error_string()); die(Decryption failed); } $plain_password mb_convert_encoding($plain_bytes, UTF-8, UTF-8); echo Decrypted: . $plain_password; ?注意openssl_decrypt的第四个参数OPENSSL_RAW_DATA至关重要它告诉PHP输入是原始字节非Base64这与DelphiDecrypt函数的TBytes输入完全对应。若传入Base64字符串会解密失败。5. 常见问题与排查技巧实录那些让联调持续三天的“幽灵Bug”5.1 典型问题速查表现象可能原因排查步骤解决方案Java解密报BadPaddingExceptionIV不一致密钥长度错误填充方式不匹配1. 在Delphi测试工程中记录加密时的Key和IV的十六进制值2. 在Java中打印key.length和iv.length3. 检查JavaCipher.getInstance参数确保Java端key和iv字节数组长度为16且内容与Delphi端TEncoding.UTF8.GetBytes结果完全一致确认使用AES/CBC/PKCS5PaddingPHPopenssl_decrypt返回falseIV长度非16字节密钥被截断Base64解码失败1.var_dump(strlen($iv));必须为162.var_dump(base64_decode($encrypted_base64, true));若为false则Base64非法3.echo bin2hex($iv);与Delphi端对比PHP中$iv必须是16字节字符串非16字符base64_decode第二个参数设为true严格校验使用mb_strlen($iv, 8bit)检查字节长度Delphi加密结果Java能解但PHP解出来乱码PHP默认编码非UTF-8mb_convert_encoding参数错误1.echo mb_internal_encoding();应为UTF-82.echo mb_detect_encoding($plain_bytes);在PHP开头加mb_internal_encoding(UTF-8);mb_convert_encoding第三个参数指定为UTF-8Delphi测试工程显示加密成功但Base64结果与Java不一致Delphi版本导致TNetEncoding.Base64行为差异Edit.Text包含不可见字符1. 在Button1Click中Memo1.Lines.Add(Plain Hex: BytesToHex(PlainText));2. 在Java中打印Arrays.toString(plainBytes)使用TEncoding.UTF8.GetBytes(Edit1.Text.Trim)清除空格确认Delphi版本XE7用TNetEncoding旧版用EncodeString并确保无BOM5.2 独家避坑技巧来自三次深夜联调的真实经验技巧1永远用十六进制Hex而非字符串对比密钥和IV字符串看起来一样字节可能天差地别。在Delphi测试工程中点击“导出测试向量”按钮它会生成test_vectors.txt内容类似PLAIN: 68656C6C6F20776F726C64 # hello world UTF-8 hex KEY: 4D794170705365637265744B657932303234 # MyAppSecretKey2024 UTF-8 hex IV: 31323334353637383930313233343536 # 1234567890123456 UTF-8 hex CIPHER: 55324673644756656458312B2B2B2B2B...Java端用DatatypeConverter.printHexBinary(plainBytes)生成HexPHP用bin2hex($plain_bytes)。三方Hex完全一致才能断定加密逻辑无误。这是最可靠的“真相时刻”。技巧2在Delphi中启用{$WARNINGS ON}和{$HINTS ON}捕获隐式类型转换Delphi默认关闭部分警告。在ElAES.pas顶部添加{$WARNINGS ON} {$HINTS ON} {$WARN IMPLICIT_STRING_CAST OFF} // 禁止string到AnsiString隐式转换 {$WARN IMPLICIT_STRING_CAST_LOSS OFF}这能揪出string被意外转为AnsiString的隐患避免UTF-8编码被破坏。技巧3PHP端务必检查openssl扩展是否启用及版本运行php -m | grep openssl若无输出则未启用。在php.ini中取消;extensionopenssl的注释。某些旧版PHP7.1的openssl_decrypt对PKCS#7填充支持不完善强制升级到PHP 7.4可规避。技巧4Java端Cipher.doFinal()抛出IllegalBlockSizeException大概率是密文长度非16倍数这通常意味着Base64解码失败如传入了带空格的Base64字符串。在Java中加日志log.info(CipherText length: {}, cipherBytes.length); // 必须是16的倍数 log.info(CipherText hex: {}, DatatypeConverter.printHexBinary(cipherBytes).substring(0, 32));若长度非16倍数问题一定出在Base64解码环节。6. 工程实践与演进思考从“能用”到“可信”的跨越这套组件在我们团队已稳定运行两年支撑了5个Delphi客户端与3套Java微服务、2套PHP遗留系统的加密通信。它从“能用”走向“可信”经历了几个关键演进第一阶段解决“能不能通”初期只实现了EncryptString/DecryptString密钥硬编码IV写死。联调时靠人工比对Hex效率低下。痛点是每次后端升级Java版本都要重新验证Cipher行为。第二阶段构建“可验证”体系引入AesTest.dprUI工程增加“导出测试向量”功能生成标准test_vectors.txt。同时编写AESTest.java作为自动化验证桩。从此任何代码变更只需运行AESTest.java绿色通过即代表兼容性无损。这将回归测试时间从小时级压缩到秒级。第三阶段迈向“可审计”与“可迁移”Readme.txt从简单说明升级为联调手册明确列出密钥/IV/Base64的编码规范untTest.pas的多版本适配层让团队从Delphi 10.2升级到11 Alexandria时加密模块零修改JAVA/和Delphi/目录分离方便后端团队只关注Java部分前端只看Delphi。未来它不会盲目追加新特性如AES-GCM或SM4而是聚焦于-增强密钥管理集成Windows DPAPI或macOS Keychain避免密钥硬编码-完善错误诊断在ElAES.pas中增加LastError属性返回具体错误码如ERR_INVALID_KEY_LENGTH,ERR_IV_NOT_16_BYTES便于前端友好提示-提供轻量级CLI工具用AesTest.dpr编译出命令行版供运维人员在服务器上快速验证密文。加密不是炫技而是建立信任的基石。当Delphi客户端发出的密文能被Java后端和PHP服务毫无障碍地解开那一刻技术栈的鸿沟消失了剩下的只有高效协作。这套组件的价值不在于它写了多少行代码而在于它省下了多少次凌晨三点的联调会议以及多少份因加密失败而被退回的需求文档。它是一把沉默的钥匙专为打开跨语言协作之门而锻造。本文还有配套的精品资源点击获取简介这个Delphi AES加解密组件支持128/192/256位密钥用标准CBC模式和PKCS#7填充Delphi 10.1 Berlin的32位和64位都编译通过了。里面核心逻辑在ElAES.pas和JDAESExtend.pas两个单元里封装得比较干净调用简单也方便后续维护。配套带了一个带界面的测试工程AesTest.dpr可以手动输密钥、IV、明文实时看加密结果验证跨平台一致性特别方便。Java端给了AESTest.java参考实现跟常见Java后端比如Spring Boot用Cipher类能直接对接PHP那边也验证过openssl_encrypt/decrypt函数能解出来不用改算法参数。Readme.txt里写了常见问题、调用示例、密钥IV格式要求还有不同Delphi版本适配说明。untTest.pas这些单元做了多版本兼容处理从老版本迁移到新Delphi也不容易出错。目录里JAVA和Delphi文件夹分开整理.gitignore和.git相关文件也预留好了适合直接集成进团队项目。本文还有配套的精品资源点击获取