迁移至.NET 5后AESManaged解密报“输入数据不是完整块”错误

核心报错根因 #

这个报错本质是解密流程中，传给加密转换组件的输入字节长度，没有达到对称加密算法要求的块大小整数倍（比如AES要求输入长度必须是16字节的整数倍）。跨框架兼容场景下出现该问题，绝大多数都和编码行为差异、密文字符串转换方式错误有关。

具体排查与修复步骤 #

• 第一步：排查两端Encoding.Default的行为差异
  .NET Framework 和 .NET Core/.NET 5+ 对Encoding.Default的定义完全不同：前者默认返回当前系统的ANSI代码页编码（比如中文Windows下是GB2312/GBK，代码页936），后者默认返回UTF-8编码。
  原代码全程用Encoding.Default做字节和字符串的转换，两端编码不匹配时，密文字符串转回字节数组的长度会和原始加密时的密文字节长度不一致，直接导致块长度不满足要求。
  验证方式：在.NET 5项目启动时通过Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)注册Windows代码页提供程序，把编码行为对齐到老框架，再测试解密是否正常。如果测试通过，就把代码里所有用到Encoding.Default的地方，显式指定固定编码（比如Encoding.GetEncoding("GB2312")），不要依赖Default的隐式行为，才能正常读取老项目历史存储的密文。
• 第二步：修复密文的字符串转换逻辑缺陷
  原代码的核心设计缺陷是：加密得到的密文是任意范围的二进制字节，却直接用文本编码把密文字节转成字符串存储/传输。这种方式本身就存在字节丢失问题——很多二进制字节序列在文本编码规则下是不合法的，转换时会被替换为特殊替换字符，等解密时再把字符串转回字节数组，长度必然不满足块大小要求。
  长期优化建议：加密完成后，密文字节转字符串使用Convert.ToBase64String()，输出可安全存储、传输的Base64格式字符串；解密时，第一步先把输入的密文字符串用Convert.FromBase64String()转成原始密文字节数组，再传入CryptoStream解密，从根源避免字节丢失问题。
• 第三步：显式对齐加密算法的固定参数
  不要依赖框架对加密算法的默认配置，把原.NET Framework项目里的算法参数全部在.NET 5项目中显式声明：包括块大小、密钥长度、加密模式（如CBC/ECB）、填充模式（如PKCS7）。避免因为框架版本迭代调整默认参数导致解密失败。
• 第四步：快速定位问题的调试方法
  临时在Transform方法里加日志，打印传入解密流程的输入字节数组长度。如果长度不是加密算法块大小的整数倍，说明问题一定出在前面的字符串转字节环节，顺着排查编码、Base64转换的逻辑即可，不需要在CryptoStream本身的逻辑上浪费时间。

同步修复原代码的遗留问题 #

• 修正代码里的变量名拼写错误（原代码里的texto是笔误，和定义的入参text不一致，会导致传参错乱）
• 异常捕获时不要用throw ex，这种写法会重置原始调用堆栈，直接写throw;保留完整堆栈即可

内容的提问来源于stack exchange，提问作者Davi GN