AES Encryption Online：浏览器加密安全流程

AES 加密看起来像是输入文字、点一下按钮，但真正关键的不是按钮，而是那一组配置：key、IV、mode、padding 和输出编码。只要其中一个不一致，密文看起来仍然像一段正常字符串，但另一端可能完全解不开。

你可以用 AES Encrypt 做浏览器里的测试数据、配置样例、学习和兼容性排查。不要把生产 secret、客户记录、私钥、恢复码或长期凭证粘贴进任何在线加密工具。

先用非敏感样例文本

加密真实内容前，先准备一段形状相似的假数据。例如假 token、假 JSON 片段，或者 `hello from staging` 这种短文本。这样可以验证 AES 配置，而不会暴露真实材料。

这一步很重要。即使工具在浏览器本地处理，安全流程也应该默认避免粘贴敏感内容，除非你完全理解运行环境和风险。

有意识地匹配 key 和 IV

AES 加密需要 key。很多浏览器工具还会在部分模式下要求 IV。IV 不是装饰字段，它会影响同样明文在某些模式下生成密文的方式。

在这个工具里，ECB 模式不使用 IV，CBC、CFB、OFB、CTR 等模式可以使用 IV。如果你后续要解密，必须同时记录 mode、padding、输出编码、key 和 IV。只保存密文本身，排查问题时通常不够。

mode 要按兼容性选，不要猜

如果对接系统已经给了明确的 AES 设置，先照着它来。CBC 和 CTR 不同，PKCS7 和 NoPadding 也不同。key 正确但模式或 padding 错了，解密照样失败。

做快速浏览器检查时，CBC 加 PKCS7 是常见起点，但这不等于它天然适合生产。生产加密应该跟随平台或服务商文档，能用认证加密模式时优先按官方方案做。

Base64 和 hex 取决于下一步系统

密文本质上是字节。工具通常把它显示成 Base64 或 hex，方便复制和存储。这两者只是表示方式，不代表加密强度不同。

如果配置项、API 或库要求 Base64，就用 Base64。对方明确要求 hex，就用 hex。有时两个系统只是输出表示方式不一致，转换编码就能解决，不需要改 AES 设置。

如果只是想单独检查编码，可以用 Base64 Encoder。不要把 Base64 当成加密；Base64 只是让字节变成可打印文本。

分清 hash 和 encryption

AES 加密是可逆的，只要 key 和配置正确就能解密。hash 不可逆。如果你要保存或比较摘要，用 Hash Generator。如果你需要把明文变成后续可解密的密文，才用 AES。

把这两件事混在一起会制造很难解释的 bug。hash 不能用 AES 解密，AES 密文也不应该当成密码 hash 使用。

一套实用 AES 加密流程

只做浏览器端 AES 检查时，可以按这个顺序走：

• 准备和真实值形状相似的假文本。
• 选择需要的 mode、padding 和输出编码。
• 输入测试 key，模式需要 IV 时也输入 IV。
• 用 AES Encrypt 加密样例。
• 复制密文，并马上用同一组配置解密测试。
• 把配置和样例输出一起记录下来。
• 只有安全策略允许时，才考虑处理真实数据。

目标是可复现。如果你说不清解密需要哪些设置，这段密文就还不适合交给别人联调。

常见错误

最常见的错误，是加密和解密中间改了某个设置。第二个错误，是本来用假样例就够，却粘贴了生产数据。第三个错误，是看到 Base64 输出就以为只是编码；实际上它可能是先 AES 加密，再用 Base64 表示。

还有一种问题来自文本编码。如果输入里有 emoji、中文或转义 JSON，比较结果前要确认接收方使用的是同样的文本编码。

FAQ

AES 加密和 Base64 编码一样吗？

不一样。AES 会用 key 改变数据，Base64 只是把字节表示成文本，方便复制或放进文本字段。

为什么能加密，但解密失败？

通常是 key、IV、mode、padding 或输出编码有一个不一致。先用很小的样例，确保同一组设置能完成加密和解密。

可以把真实 secret 粘贴进在线 AES 工具吗？

尽量不要。调试时优先用假样例。任何真实 secret 都应先按你的安全策略确认是否允许在浏览器工具里处理。