des解密失败主因是密钥/iv未对齐或填充不匹配；需确保8字节raw key/iv、显式设pkcs7/cbc、用convert.fromhexstring解析hex字符串、base64前清理空白和url编码、解密后按实际编码（如gbk）转字符串。
DES解密失败：CryptographicException 提示“填充无效且无法被移除”
这基本是密钥或初始化向量（IV）没对齐，或者加密端用了非标准填充方式。老旧系统常用 PKCS5Padding（实际等同于 PKCS7），但 .NET 的 DESCryptoServiceProvider 默认用 PKCS7，表面一致，实则可能因字节序、截断或手动补零导致错位。
- 务必确认对方提供的密钥和 IV 都是 8 字节（64 位），且是 raw bytes，不是 hex 字符串直接转 ASCII
- 如果对方给的是十六进制字符串（如
"A1B2C3D4E5F60708"），必须先用Convert.FromHexString()（.NET 5+）或手动解析成 byte[]，不能直接Encoding.UTF8.GetBytes() - 设置
Padding = PaddingMode.PKCS7，显式指定，别依赖默认值；Mode = CipherMode.CBC也必须明确，老旧系统极少用 ECB
如何安全复用 .NET Framework 的 DESCryptoServiceProvider（.NET Core/5+ 兼容写法）
.NET Core 3.0+ 已标记 DESCryptoServiceProvider 为 obsolete，但对接老系统时绕不开——它和旧 Java/C++ 实现的兼容性比 DES.Create() 更稳，尤其在 IV 处理和填充边界上。
- 用
new DESCryptoServiceProvider()而不是DES.Create()，后者在某些运行时会返回不兼容的实现 - 手动设置
KeySize = 64和BlockSize = 64，避免因策略限制被自动升级成 TripleDES - 解密前调用
Clear()清理内部状态，防止跨请求残留 IV 或密钥缓存（多线程下尤其重要）
using var des = new DESCryptoServiceProvider
{
Key = keyBytes,
IV = ivBytes,
Mode = CipherMode.CBC,
Padding = PaddingMode.PKCS7,
KeySize = 64,
BlockSize = 64
};
Base64 解密输入乱码？检查是否漏了 URL 安全变体或换行符
老系统接口返回的密文常是 Base64，但可能混入 +// 被 URL 编码成 %2B/%2F，或末尾带换行符、空格。.NET 的 Convert.FromBase64String() 对非法字符零容忍，直接抛 FormatException。
- 先
input.Trim().Replace("\r", "").Replace("\n", "")去空白 - 如果来自 HTTP 查询参数，需先
WebUtility.UrlDecode()，再处理 Base64 - 若对方用的是 “URL 安全 Base64”（
-替+，_替/），要手动替换回标准字符再解码
为什么解密结果开头有乱码或长度不对？关注字节 vs 字符编码
DES 解密输出是 byte[]，不是字符串。直接 Encoding.UTF8.GetString() 会出问题——对方可能用 GBK、ISO-8859-1 编码明文，甚至混合二进制字段（比如时间戳、校验和）。乱码不是解密失败，是解码方式错了。
- 先用
Convert.ToHexString(decryptedBytes)打印原始字节，和预期明文 hex 对照，确认解密本身正确 - 查清对方文档或样本数据：中文字段大概率是
Encoding.GetEncoding("GBK")，纯 ASCII 数字/字母可用Encoding.ASCII - 如果明文含二进制段（如 4 字节 int），别强转字符串，用
BitConverter.ToInt32()拆解
DES 对接老系统最耗时间的从来不是算法本身，而是对方文档里没写的隐式规则：比如 IV 固定用 8 个 0x00 却不说明，或者密钥字符串实际取前 8 字符而非全部 MD5。留一招：把对方给的“已知明文+密文+密钥+IV”组合，用 Python 的 pycryptodome 独立验证一遍，能快速定位是 C# 实现偏差，还是理解错了协议。
