1. 项目概述：为什么我们需要可逆加密？
在C#项目开发里，数据安全是个绕不开的话题。无论是保存用户的敏感配置、保护网络传输的通信内容，还是对数据库中的某些字段进行脱敏存储，加密都是最直接有效的手段。而“可逆加密”这个概念，听起来有点矛盾——既然要加密保护，为什么还要能“解密”回来？这恰恰是它与哈希算法的核心区别。哈希是单向的，像把牛奶做成奶酪，你没法把奶酪变回原来的牛奶，常用于密码存储和完整性校验。而可逆加密，更像是给信息上了一把锁，拥有正确钥匙的人可以随时打开它，恢复原始信息，这适用于那些未来需要被读取的敏感数据，比如用户的身份证号、银行卡号、通信报文等。
我接手过不少项目，从桌面应用到Web服务，都遇到过需要可逆加密的场景。比如一个医疗管理系统，病人的诊断报告在数据库里不能是明文，但医生需要时可以解密查看；再比如一个配置管理工具，数据库连接字符串总不能写死在配置文件里吧？用可逆加密存起来，运行时再解密，安全性就高多了。所以，掌握几种靠谱的、能在C#里轻松实现的可逆加密算法，是每个C#开发者工具箱里的必备技能。今天，我就结合自己踩过的坑和积累的经验，带你彻底搞懂在C#中实现可逆加密的几种主流方案，从最经典的对称加密AES，到非对称加密RSA，再到一些实际开发中的组合拳和避坑指南。
2. 核心加密算法选型与原理剖析
选择哪种加密算法，首先得明白它们的“脾气”。在C#的System.Security.Cryptography命名空间下，我们主要打交道的是两大类：对称加密和非对称加密。
2.1 对称加密：AES的统治地位
对称加密，顾名思义，加密和解密用的是同一把钥匙。它的优点是速度快，适合加密大量数据。在众多对称算法中，AES（Advanced Encryption Standard）是目前无可争议的王者，早已取代了老旧的DES和3DES。
AES的核心在于“块加密”和“加密模式”。它把数据分成固定大小的块（AES是128位，即16字节）进行处理。单纯的分块加密（ECB模式）不安全，因为相同的明文块会产生相同的密文块，容易暴露模式。因此，我们通常需要配合一个初始化向量（IV）和加密模式来增加安全性。
- CBC模式（Cipher Block Chaining）：这是我个人最常用，也是推荐新手首选的模式。每个明文块在加密前，会先与前一个密文块进行异或操作。第一个块没有前一个密文块怎么办？就用IV来代替。这意味着，即使完全相同的明文，只要IV不同，产生的密文就完全不同。IV不需要保密，但必须不可预测（通常随机生成），且每次加密都应使用新的IV。
- 密钥（Key）：这是秘密所在。AES支持128位、192位和256位三种密钥长度。越长越安全，但计算也稍慢。对于绝大多数应用，128位（16字节）已足够安全。密钥必须妥善保存，比如放在服务器的环境变量或硬件安全模块中，绝不能硬编码在代码里。
为什么选AES？因为它经过了全球密码学家的严格审查，速度快、安全性高，且被.NET框架原生良好支持。在C#中，我们使用Aes类（或历史遗留的RijndaelManaged，但推荐用Aes.Create()）来操作。
2.2 非对称加密：RSA的公私钥哲学
非对称加密使用一对密钥：公钥和私钥。公钥可以公开，用于加密数据；私钥必须严格保密，用于解密。它的优点是解决了密钥分发问题，但速度比对称加密慢得多，通常只用于加密少量数据，比如加密一个对称加密的密钥。
RSA是最常用的非对称算法。在C#中，我们使用RSACryptoServiceProvider或更新的RSA类。它的一个关键参数是密钥长度，常见的有1024、2048、4096位。现在1024位已被认为不够安全，至少使用2048位。需要注意的是，RSA加密的明文长度受密钥长度限制。例如，一个2048位的RSA密钥，最多只能加密245字节左右的数据（因为需要填充）。所以，直接用RSA加密大文件是不可行的。
在实际应用中，RSA常与对称加密结合，形成“混合加密”系统：用RSA加密随机生成的对称密钥（如AES密钥），再用这个对称密钥去加密实际的数据。这样既利用了对称加密的速度，又利用了非对称加密的安全密钥交换。
2.3 算法选择速查与场景匹配
怎么选？我总结了一个简单的决策表：
| 场景 | 推荐算法 | 关键理由 | 注意事项 |
|---|---|---|---|
| 加密数据库字段、配置文件 | AES (CBC模式) | 速度快，适合结构化数据，密文长度固定可控。 | 必须安全管理密钥，每次加密使用随机IV。 |
| 加密网络通信报文 | AES (GCM模式) | 除了加密，还提供完整性认证，防止密文被篡改。 | .NET Core 3.0+ 支持更好，需要处理认证标签。 |
| 安全传输对称密钥 | RSA (2048位以上) | 解决密钥分发问题。 | 仅用于加密密钥等短数据，性能差。 |
| 数字签名、身份验证 | RSA | 用私钥签名，公钥验证，确保数据来源和完整性。 | 注意区分加密和签名操作。 |
| 简单、快速的字符串加密（非最高安全） | AES或三重DES | 实现简单，满足基本安全需求。 | 三重DES已过时，仅用于兼容旧系统。 |
注意：绝对不要使用ECB模式或自己发明加密算法。ECB模式不安全，而自创的算法几乎必然存在未知漏洞。
3. 实战：使用AES实现可逆加密
理论说再多，不如一行代码。我们直接上手，用C#和AES-CBC模式实现一个完整的加密解密工具类。这是你在项目中可以直接“抄作业”的部分。
3.1 核心工具类封装
首先，我们创建一个AesHelper类。好的封装能让代码更安全、更易用。
using System; using System.IO; using System.Security.Cryptography; using System.Text; public class AesHelper { // 密钥，必须是16（AES-128）, 24（AES-192）, 或 32（AES-256）字节 private readonly byte[] _key; public AesHelper(string key) { if (string.IsNullOrEmpty(key)) throw new ArgumentException("密钥不能为空", nameof(key)); // 这里简单地将字符串转换为字节，实际项目应从安全位置读取二进制密钥 _key = Encoding.UTF8.GetBytes(key.PadRight(32, '0').Substring(0, 32)); // 示例：固定为256位 } /// <summary> /// 使用AES-CBC模式加密字符串，返回Base64格式的密文 /// </summary> public string Encrypt(string plainText) { if (string.IsNullOrEmpty(plainText)) return plainText; using (Aes aesAlg = Aes.Create()) { aesAlg.Key = _key; aesAlg.GenerateIV(); // 关键：每次加密生成随机IV ICryptoTransform encryptor = aesAlg.CreateEncryptor(aesAlg.Key, aesAlg.IV); using (MemoryStream msEncrypt = new MemoryStream()) { // 先将IV写入流的前端 msEncrypt.Write(aesAlg.IV, 0, aesAlg.IV.Length); using (CryptoStream csEncrypt = new CryptoStream(msEncrypt, encryptor, CryptoStreamMode.Write)) { using (StreamWriter swEncrypt = new StreamWriter(csEncrypt)) { swEncrypt.Write(plainText); } } byte[] encryptedBytes = msEncrypt.ToArray(); return Convert.ToBase64String(encryptedBytes); } } } /// <summary> /// 解密AES-CBC模式加密的Base64密文 /// </summary> public string Decrypt(string cipherText) { if (string.IsNullOrEmpty(cipherText)) return cipherText; byte[] fullCipher = Convert.FromBase64String(cipherText); using (Aes aesAlg = Aes.Create()) { aesAlg.Key = _key; // 从密文前端提取IV（AES的IV固定为16字节） byte[] iv = new byte[16]; byte[] cipherBytes = new byte[fullCipher.Length - 16]; Buffer.BlockCopy(fullCipher, 0, iv, 0, 16); Buffer.BlockCopy(fullCipher, 16, cipherBytes, 0, fullCipher.Length - 16); aesAlg.IV = iv; ICryptoTransform decryptor = aesAlg.CreateDecryptor(aesAlg.Key, aesAlg.IV); using (MemoryStream msDecrypt = new MemoryStream(cipherBytes)) { using (CryptoStream csDecrypt = new CryptoStream(msDecrypt, decryptor, CryptoStreamMode.Read)) { using (StreamReader srDecrypt = new StreamReader(csDecrypt)) { return srDecrypt.ReadToEnd(); } } } } } }3.2 关键代码解析与避坑点
这段代码有几个至关重要的细节，直接关系到安全性和正确性：
- IV的处理：这是新手最容易栽跟头的地方。代码中
aesAlg.GenerateIV()用于生成一个随机的16字节IV。加密时，必须将IV和密文一起保存或传输。这里我们采用了最常见的方式：将IV拼接在密文字节数组的前面。解密时，再从前16字节把IV读出来。绝对不要使用固定的IV，那会让你的加密形同虚设。 - 密钥管理：示例中密钥来自字符串输入，这极不安全，仅用于演示。在生产环境中，密钥应该：
- 从安全的配置源读取（如Azure Key Vault, AWS Secrets Manager）。
- 或由系统在首次运行时生成并保存在受保护的位置（如使用
ProtectedData类在Windows上加密存储）。 - 绝不能出现在版本控制（如Git）的代码或配置文件中。
- 使用
using语句：所有继承自IDisposable的加密对象（Aes,CryptoStream,MemoryStream等）都必须包裹在using语句中，以确保加密相关的敏感内存被及时清理。 - Base64编码：加密产生的是二进制字节数组，为了便于在文本环境（如JSON、配置文件、URL）中传输和存储，我们将其转换为Base64字符串。解密时再做反向转换。
3.3 实际使用示例
class Program { static void Main(string[] args) { // 警告：此密钥仅为示例，生产环境必须从安全位置获取！ string secretKey = "MySuperSecretKey1234567890123456"; // 32字符，对应256位 AesHelper aesHelper = new AesHelper(secretKey); string originalText = "这是一条需要加密的敏感信息，比如身份证号：110101199001011234"; Console.WriteLine($"原始文本: {originalText}"); string encryptedText = aesHelper.Encrypt(originalText); Console.WriteLine($"加密后 (Base64): {encryptedText}"); string decryptedText = aesHelper.Decrypt(encryptedText); Console.WriteLine($"解密后: {decryptedText}"); Console.WriteLine($"解密是否成功: {originalText == decryptedText}"); } }运行后，你会看到每次加密的结果（Base64字符串）都不同，这正是因为IV是随机的。但用同一把钥匙，总能正确解密回原文。
4. 进阶：结合RSA与AES的混合加密实践
当你的应用涉及客户端与服务端通信，且需要安全地交换数据时，单纯的AES会遇到密钥如何安全传给对方的问题。这时，混合加密就派上用场了。思路是：用RSA加密随机的AES密钥，再用该AES密钥加密实际数据。
4.1 混合加密流程拆解
- 服务端：生成RSA密钥对，私钥自己保存，公钥下发给客户端。
- 客户端：
- 随机生成一个AES密钥（Session Key）和IV。
- 使用服务端的公钥，加密这个AES密钥。
- 使用生成的AES密钥和IV，加密实际要发送的敏感数据。
- 将加密后的AES密钥、IV和加密数据一起发送给服务端。
- 服务端：
- 使用自己的私钥解密，得到AES密钥。
- 使用AES密钥和收到的IV解密数据。
这样，AES密钥本身通过安全的RSA通道传输，而大数据则由高效的AES处理。
4.2 C# 混合加密实现示例
这里展示一个简化的模拟流程，重点在RSA加密AES密钥这部分。
using System; using System.Security.Cryptography; using System.Text; public class HybridEncryptionDemo { // 模拟服务端：生成RSA密钥对 public static (string publicKey, string privateKey) GenerateRsaKeys() { using (RSACryptoServiceProvider rsa = new RSACryptoServiceProvider(2048)) // 使用2048位密钥 { // 导出公钥和私钥（为方便演示，用XML格式。实际应考虑更安全的格式如PEM） string publicKey = rsa.ToXmlString(false); string privateKey = rsa.ToXmlString(true); return (publicKey, privateKey); } } // 模拟客户端：用服务端公钥加密AES密钥 public static byte[] EncryptAesKeyWithRsa(string publicKeyXml, byte[] aesKey) { using (RSACryptoServiceProvider rsa = new RSACryptoServiceProvider()) { rsa.FromXmlString(publicKeyXml); // RSA加密，使用OAEP填充（更安全） return rsa.Encrypt(aesKey, true); } } // 模拟服务端：用私钥解密得到AES密钥 public static byte[] DecryptAesKeyWithRsa(string privateKeyXml, byte[] encryptedAesKey) { using (RSACryptoServiceProvider rsa = new RSACryptoServiceProvider()) { rsa.FromXmlString(privateKeyXml); return rsa.Decrypt(encryptedAesKey, true); } } public static void Demo() { // 1. 服务端准备 var keys = GenerateRsaKeys(); Console.WriteLine("服务端生成RSA密钥对完成。"); // 2. 客户端准备数据 string sensitiveData = "这是要传输的机密合同内容..."; byte[] dataToEncrypt = Encoding.UTF8.GetBytes(sensitiveData); // 客户端生成随机的AES密钥和IV using (Aes aes = Aes.Create()) { aes.GenerateKey(); aes.GenerateIV(); byte[] aesKey = aes.Key; byte[] iv = aes.IV; Console.WriteLine($"客户端生成AES密钥（长度：{aesKey.Length * 8}位）和IV。"); // 3. 客户端用服务端公钥加密AES密钥 byte[] encryptedAesKey = EncryptAesKeyWithRsa(keys.publicKey, aesKey); Console.WriteLine($"AES密钥经RSA加密后长度：{encryptedAesKey.Length} 字节"); // 4. 客户端用AES加密实际数据（此处省略具体加密过程，参考上一节的AesHelper） byte[] encryptedData; // 假设这里调用AesHelper.EncryptBytes得到 // ... 实际AES加密操作 ... // 模拟将 encryptedAesKey, iv, encryptedData 发送给服务端 Console.WriteLine("客户端将加密的AES密钥、IV和加密数据发送至服务端。"); // 5. 服务端接收并解密 // 服务端用私钥解密AES密钥 byte[] decryptedAesKey = DecryptAesKeyWithRsa(keys.privateKey, encryptedAesKey); Console.WriteLine($"服务端解密得到AES密钥，与客户端原始密钥一致：{BitConverter.ToString(aesKey) == BitConverter.ToString(decryptedAesKey)}"); // 服务端用解密出的AES密钥和收到的IV解密数据 // ... 实际AES解密操作 ... // string decryptedData = ...; // Console.WriteLine($"解密出的数据：{decryptedData}"); } } }4.3 混合加密的注意事项
- 性能：RSA加密解密非常耗时，所以务必只用于加密密钥（通常几十字节），而不是整个数据包。
- 密钥管理：服务端的RSA私钥是安全的核心，必须用最高级别保护。可以考虑使用硬件安全模块或云服务商的密钥管理服务。
- 填充模式：RSA加密时，务必使用OAEP填充（如上例中
rsa.Encrypt(data, true)），它比旧的PKCS#1 v1.5填充更安全。 - 密钥格式：示例中使用XML字符串格式是为了方便演示。在生产环境中，尤其是跨平台场景，考虑使用PEM格式或直接处理密钥的字节数组/参数。
5. 生产环境中的关键问题与排查指南
即使代码写对了，在实际部署和运行中，你依然会遇到各种“坑”。下面是我从真实项目里总结出来的常见问题清单和解决方法。
5.1 常见异常与解决方案速查表
| 异常信息 | 可能原因 | 解决方案 |
|---|---|---|
CryptographicException: Padding is invalid and cannot be removed. | 最常见错误。1. 密钥错误。2. IV错误或与加密时不一致。3. 密文在传输/存储中被损坏或篡改。4. 加密和解密使用的算法、模式、填充方式不匹配。 | 1. 双重检查密钥来源是否一致。2. 确认IV是否正确地从密文头部读取并设置。3. 检查Base64解码或网络传输是否有误。4. 确保Aes实例的所有属性（Mode,Padding）在加解密时完全相同。 |
CryptographicException: Bad Key. | 提供的密钥长度不符合算法要求。AES密钥不是16/24/32字节。 | 检查密钥生成或加载逻辑，确保字节数组长度正确。 |
ArgumentNullException | 传递给加密方法的明文或密钥为null。 | 在方法开始处增加参数校验。 |
FormatException: The input is not a valid Base-64 string. | 尝试解密的字符串不是有效的Base64格式。 | 检查密文是否被意外修改（如空格、换行）。使用Convert.FromBase64String前可先Trim()。 |
| 解密结果乱码或部分正确 | 可能使用了错误的字符编码进行GetBytes/GetString转换。 | 在加密解密流程中，对字符串的操作统一使用Encoding.UTF8。对于二进制数据，避免不必要的字符串转换。 |
| 性能问题（大量数据加密慢） | 1. 错误地使用了RSA加密大量数据。2. 没有使用流式处理大文件。 | 1. 遵循“RSA加密密钥，AES加密数据”的原则。2. 对于文件，使用CryptoStream链接FileStream，避免将整个文件读入内存。 |
5.2 密钥管理：最大的安全挑战
“密钥在哪存？”这是安全审计时必问的问题。硬编码在代码里是自杀行为，写在appsettings.json里也好不到哪去。
- 开发/测试环境：可以使用用户机密（User Secrets）或环境变量。在Visual Studio中右键项目->“管理用户机密”，可以存储开发用的密钥，它不会进入源代码库。
- 生产环境（云）：
- Azure: 使用Azure Key Vault。你的代码只需一个身份（如Managed Identity）去访问Key Vault获取密钥。
- AWS: 使用AWS Secrets Manager或AWS KMS。
- GCP: 使用Google Cloud Secret Manager或KMS。
- 生产环境（本地/混合）：
- 使用受保护的配置文件（如通过
aspnet_regiis加密web.config特定段落）。 - 使用Windows的DPAPI（Data Protection API），通过
ProtectedData类来加密存储密钥。注意这依赖于机器或用户账户。 - 使用硬件安全模块（HSM），这是最高安全等级的选择。
- 使用受保护的配置文件（如通过
核心原则：密钥本身不应该出现在你的应用程序代码或普通配置文件中，而应该从受信的安全服务中在运行时动态获取。
5.3 加密数据与数据库的协作
在数据库中存储加密数据，除了字段类型要设为varbinary或blob外，还要注意：
- 索引失效：加密后的数据是随机的，无法基于其内容创建有效索引。如果你需要按加密字段查询，这是一个巨大挑战。解决方案之一是使用“确定性加密”（如使用固定的IV，但这不安全），或者只在应用层解密后过滤（性能差）。更专业的做法是使用支持“可搜索加密”的数据库或特定加密方案，但这非常复杂。
- 模糊查询：
LIKE '%部分内容%'这样的查询在加密数据上完全无法工作。 - 数据迁移：如果未来需要更换密钥，需要对所有已加密数据进行“密钥轮换”——即用旧密钥解密，再用新密钥加密。这需要设计专门的、可回滚的迁移脚本，并在业务低峰期执行。
因此，在设计阶段就要想清楚：这个字段真的需要加密吗？如果需要，它是否需要被查询？如果必须查询，能否通过关联其他未加密的索引字段（如ID、哈希值）来间接实现？
5.4 版本兼容性与算法过时
密码学算法不是一成不变的。今天安全的算法，明天可能就被破解。
- 避免使用已废弃的算法：如
DES、RC2、MD5（用于加密）、SHA1（用于签名）。在C#中，使用Aes代替RijndaelManaged，使用SHA256等更安全的哈希函数。 - 关注框架更新：.NET Core/.NET 5+ 引入了一些新的、更安全的API，如
AesGcm用于认证加密。及时更新你的目标框架，并使用推荐的API。 - 为算法升级留后路：在存储密文时，可以附带一个简短的“版本标识”或“算法标识”。例如，在密文前加上
AES256CBC_V1:前缀。这样，当未来需要升级到AES256GCM_V2时，你的解密代码可以根据标识来选择对应的算法和逻辑，平滑过渡。
6. 调试与单元测试：确保加密可靠
加密代码的bug往往难以调试，因为输入输出都是乱码。建立完善的单元测试是保证其正确性的唯一途径。
6.1 编写单元测试
使用xUnit、NUnit或MSTest为你的加密工具类编写测试。
using Xunit; public class AesHelperTests { private const string TestKey = "ThisIsATestKeyForUnitTesting123"; // 测试专用密钥 private readonly AesHelper _aesHelper = new AesHelper(TestKey); [Fact] public void Encrypt_Decrypt_ShouldReturnOriginalText() { // Arrange string original = "Hello, 可逆加密世界！@123"; // Act string encrypted = _aesHelper.Encrypt(original); string decrypted = _aesHelper.Decrypt(encrypted); // Assert Assert.Equal(original, decrypted); Assert.NotEqual(original, encrypted); // 确保确实加密了 } [Fact] public void Encrypt_WithSameText_ProducesDifferentCipherText_DueToRandomIV() { // Arrange string text = "重复加密测试"; // Act string cipher1 = _aesHelper.Encrypt(text); string cipher2 = _aesHelper.Encrypt(text); // Assert Assert.NotEqual(cipher1, cipher2); // IV不同，密文必须不同 } [Fact] public void Decrypt_WithWrongKey_ShouldThrowOrReturnGibberish() { // Arrange string original = "敏感数据"; string encrypted = _aesHelper.Encrypt(original); AesHelper wrongKeyHelper = new AesHelper("WrongKeyWrongKeyWrongKeyWrongKey"); // 错误密钥 // Act & Assert // 使用错误密钥解密，应抛出异常或得到乱码 // 这里期望抛出 CryptographicException Assert.Throws<System.Security.Cryptography.CryptographicException>(() => wrongKeyHelper.Decrypt(encrypted)); } [Theory] [InlineData("")] // 空字符串 [InlineData("a")] // 短字符串 [InlineData("很长的字符串很长的字符串很长的字符串很长的字符串很长的字符串很长的字符串")] // 长字符串 [InlineData("特殊字符 ~!@#$%^&*()_+{}|:\"<>?`-=[]\\;',./")] // 特殊字符 public void Encrypt_Decrypt_ShouldHandleVariousInputs(string input) { // Act string encrypted = _aesHelper.Encrypt(input); string decrypted = _aesHelper.Decrypt(encrypted); // Assert Assert.Equal(input, decrypted); } }6.2 调试技巧
当加密解密出错时，按以下步骤排查：
- 隔离问题：首先写一个最简单的控制台程序，用固定的明文和密钥测试你的加密解密函数，排除业务逻辑干扰。
- 检查二进制：在加密后和解密前，分别输出关键字节数组（Key, IV, 密文）的十六进制字符串（用
BitConverter.ToString(byteArray)）。对比加密端和解密端的这些值是否完全一致。99%的问题出在这里。 - 逐步调试：在解密代码中，在调用
Convert.FromBase64String和aes.CreateDecryptor之前设置断点，检查每一个中间变量。 - 日志记录：在生产代码中，谨慎地记录异常和错误信息（切勿记录密钥或明文），可以帮助你定位是哪个环节的配置出了问题。
7. 性能考量与最佳实践
在性能敏感的场景（如高频API、实时数据处理）中使用加密，需要关注以下几点：
- 对象复用：创建
Aes或RSA实例是比较耗时的。如果你的应用需要频繁加密，考虑将这些对象实例化一次并复用（但要注意线程安全）。对于Aes，可以创建一个线程安全的Encryptor/Decryptor池。 - 流式处理大文件：加密大文件时，千万不要
File.ReadAllBytes把整个文件读进内存。一定要用CryptoStream包裹FileStream进行流式处理。using (FileStream inputFile = new FileStream("largefile.bin", FileMode.Open)) using (FileStream outputFile = new FileStream("encrypted.bin", FileMode.Create)) using (Aes aes = Aes.Create()) { // ... 设置aes.Key, aes.IV ... using (CryptoStream cryptoStream = new CryptoStream(outputFile, aes.CreateEncryptor(), CryptoStreamMode.Write)) { inputFile.CopyTo(cryptoStream); } } - 异步支持：.NET的加密流（
CryptoStream）支持异步方法，在高并发IO场景下，使用CopyToAsync等方法可以提升吞吐量。 - 算法硬件加速：现代CPU（如Intel AES-NI）对AES算法有专门的指令集加速。.NET Framework/Core 在支持时会自动利用这些指令，无需额外配置。确保你的服务器环境支持即可。
加密是安全与性能的平衡。没有绝对的安全，只有相对于威胁模型足够的安全。对于绝大多数内部业务系统，使用AES-256-CBC配合安全的密钥管理，已经能抵御非常强大的攻击。而对于金融、政务等超高安全要求场景，则需要引入更完整的体系，包括硬件安全模块、定期密钥轮换、完整的审计日志等。希望这篇从原理到实战、从代码到运维的指南，能帮你把C#中的可逆加密这件武器用得得心应手。
