Cipher类：执行AES/DES变量加密与解密-java教程-PHP中文网

Cipher类是JCE核心组件，统一执行加解密；AES需严格匹配算法/模式/填充、密钥（16/24/32字节并用SecretKeySpec包装）、IV（CBC模式下16字节且必须与加密时完全相同），解密前须Base64解码、解密后按UTF-8转字符串。

cipher类：执行aes/des变量加密与解密

Java 中的 Cipher 类是 JCE（Java Cryptography Extension）的核心组件，用于统一执行对称加密（如 AES、DES）和非对称加密（如 RSA）的加解密操作。它不直接处理密钥生成或编码转换，但通过标准化的初始化和调用流程，让不同算法具备一致的使用方式。

AES 是当前主流的对称加密算法，推荐使用 128 位（16 字节）及以上密钥长度。实际使用中必须明确三要素：

算法/模式/填充：例如 "AES/CBC/PKCS5Padding"，其中 CBC 模式需配合初始化向量（IV），PKCS5Padding 保证明文长度适配分组要求（AES 分组固定为 128 位）
密钥规格：用 SecretKeySpec 包装字节数组，密钥长度必须为 16、24 或 32 字节（对应 AES-128/AES-192/AES-256）；若字符串密钥不足长度，不可简单截断或补空格，应通过 SHA-256 等哈希后取前 N 字节
初始化向量（IV）：CBC、CTR 等模式必需，长度必须等于分组大小（AES 为 16 字节）。IV 不需要保密，但每次加密应随机生成并随密文一起传输；解密时需使用**完全相同**的 IV

DES 已属淘汰算法，仅限兼容旧系统使用；3DES（Triple DES）作为过渡方案仍被部分金融系统支持。它们的 Cipher 配置逻辑类似，但参数约束更严格：

DES 密钥必须为 8 字节（56 位有效），且不能含弱密钥（如全 0、全 F）；JDK 默认策略限制密钥长度，如需使用 3DES（112 或 168 位密钥），需确认 JCE Unlimited Strength Policy 已启用（现代 JDK 8u161+ 及 JDK 9+ 默认支持）
工作模式推荐 CBC，避免使用 ECB —— 后者对相同明文块生成相同密文块，会暴露数据模式
填充方式常用 PKCS5Padding（与 PKCS7Padding 在 8 字节分组下等价），不可省略；若指定 NoPadding，则明文长度必须严格为分组长度整数倍

无论 AES 还是 DES，Cipher 实例的生命周期都遵循固定步骤，核心在于 init() 的参数匹配：

加密：先调用 cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec)，再传入原始字节数组执行 doFinal()
解密：使用**完全相同的** keySpec 和 ivSpec 初始化，传入 Base64 解码后的密文字节数组，doFinal() 返回明文字节
异常处理必须覆盖 InvalidKeyException、InvalidAlgorithmParameterException 和 BadPaddingException（后者常因密钥/IV 错误或填充损坏触发）
敏感操作如密钥构造、IV 生成建议使用 SecureRandom，而非 Random，防止可预测性风险

实际开发中最容易踩坑的地方集中在参数不一致和编码混乱：

密钥或 IV 使用字符串 getBytes() 时未指定字符集（如 UTF-8），导致不同环境字节序列不一致 → 始终显式传入 "UTF-8"
加密用 CBC 模式却在 init() 中漏掉 IvParameterSpec → 抛出 InvalidAlgorithmParameterException
Base64 编解码混用不同实现（如 Apache Commons Codec vs Java 8+ java.util.Base64）→ 结果无法互通，应统一使用标准 JDK 接口
将加密后的字节数组直接转成 String（如 new String(encrypted)）→ 产生乱码甚至截断，必须用 Base64 或 Hex 编码后再传输