AES明文整一块，为何还填充？

AES明文恰好占满一个分组时，采用PKCS7仍会补上完整填充分组。这让解密端能按确定规则识别并移除填充，而不必猜测明文尾部是否本来就是某些字节。判断输出长度时还要区分密文字节与Base64字符数，不能把编码后的字符长度直接当作分组长度。

2026年11月7日，www.kkce.com 实操截图。主图为16字节对齐明文的NoPadding结果；下图为同参数PKCS7结果。Base64输出44字符对应32字节；对照主图24字符对应16字节。

固定参数比较两种填充

在快快测AES加解密使用CBC及公开教学参数，明文为16个ASCII字符0123456789ABCDEF。NoPadding输出24个Base64字符，对应16字节；切到PKCS7得到44个字符，对应32字节。两图记录填充选择，长度变化符合多出一个分组的预期。

完整填充块解决尾部歧义

PKCS7按所需补入的字节数写入相同数值；对于AES的16字节分组，已对齐时补入16个相应字节。若对齐时不补，而又要求接收端照常去填充，就无法稳定区分某些真实尾部与填充。因此双方必须使用一致的约定。

别通过关闭填充绕过协议差异

NoPadding要求输入满足相应分组条件，并不会自动解决双方数据边界问题。联调时还要核对密钥字节、模式、初始向量与传输编码，不能只看到结果更短就认为更正确。真正的输出长度比较应先还原Base64，再计数字节。

教学对照不等于生产加密方案

本页固定密钥与初始向量仅用于复现长度差异，不可照抄为线上配置。CBC本身不提供完整性认证，实际方案需按协议配置可靠认证或选择恰当的认证加密方式。KKCE便于观察参数效果，不能用“能解开”替代安全设计。