AES 加解密（口令派生）
输入一个口令和一段文字，得到一串可复制的密文；把密文串和口令填回来，就能还原原文
① 加密：文字 + 口令 → 密文串
口令强度提示：长度与字符种类越多越难被暴力尝试（仅提示，不阻断使用）
迭代次数写在密文串里，解密时按密文串自身的记录执行，所以改这里只影响新加密的内容。手机上调太大（如 60 万）会明显变慢。
格式：QPS1.算法.迭代次数.base64(salt).base64(iv).base64(密文)。AES-GCM 的认证标签由 WebCrypto 附在密文末尾，所以不需要单独一段。这串密文自带全部参数，只要口令对、算法在，任何能跑本页的浏览器都能解开。
② 解密：密文串 + 口令 → 文字
密文串第二段写着用的是 AES-GCM 还是 AES-CBC、第三段是迭代次数，解密时不需要你再选一次；填错版本号或字段缺失会在下方就地报错。
只用 GCM 与 CBC 两个模式，口令错误与数据被篡改在两种模式下都表现为同一类失败：GCM 的认证标签校验不过、CBC 解出来不是有效文本，因此本页不会替你判定"是口令错了"还是"密文被动过"，只会如实说口令错误或数据被篡改。解密失败时结果区不会显示任何内容，绝不会把乱码当成功给你。
使用前请先看清楚：本页适合什么、不适合什么
① 这是本地、面向小数据的工具，不要用于生产密钥或敏感数据管理。适合把一段临时文本（配置片段、测试账号备注、一段要给同事的话）用口令加成一串密文发出去；不适合承载长期凭证、客户数据、私人证件信息。真要管理密钥与密码，请用专门的密码管理器。
② 安全性由口令强度决定，弱口令等于没加密。本页用 PBKDF2-SHA256 把口令派生成密钥（默认 15 万次迭代，可调高），迭代次数只能让暴力尝试变慢，不能补救"123456"这种口令。口令越短、字符种类越单一，被猜出来的代价就越低。
③ 加密算法来自浏览器（WebCrypto），不是我们自己写的密码学，但格式与参数由本页定义。AES、PBKDF2 都是浏览器内核实现的标准算法，本页只是按固定参数调用它们；而密文串的格式（QPS1 前缀与六段结构）是本页自己定的，所以与其它在线工具、命令行 openssl 生成的密文不一定互通——除非对方按同样的参数（PBKDF2-SHA256、同样的 salt/iv、GCM 标签 128 位）自己拼装。
④ 口令与明文不会上传，也不会留在本机。整页没有任何网络提交：口令与内容只作为 WebCrypto 的入参参与运算，不进网址、不写浏览器本地存储、不打印到控制台；密文串需要你自己复制带走。关掉页面，输入框里的东西就没有了。
关于"口令加密"这件事，你需要知道的几件事
口令不是密钥，中间必须有一次"派生"。AES-256 需要一把 32 字节、看起来完全随机的密钥，而人记得住的口令往往只有十几个字符，还常是词典里的词。直接把口令截断或填充当密钥用，会把密钥空间压缩到口令的规模——攻击者不用碰 AES，只要反复猜口令即可。所以本页先用 PBKDF2-SHA256 把口令"拉伸"成 256 位密钥：它把口令和一段随机 salt 一起做十多万次带哈希的迭代，每次猜测都要付出同样的计算代价。默认 15 万次是常见的折中（桌面端约几十毫秒），你可以调高到 30 万、60 万让每次尝试更贵，代价是自己也得等更久。迭代次数写在密文串里，解密时按它执行，因此调高不会让旧密文失效。
salt 与 iv 各自解决一个不同的问题，都不能省。salt 是给密钥派生用的随机数：没有它，同一个口令在任何地方都会派生出同一把密钥，攻击者可以预先算好"常见口令 → 密钥"的对照表（彩虹表），一次算好到处复用；有了随机 salt，同样的口令每次派生出不同密钥，预计算就失效了。本页每次加密都生成 16 字节随机 salt。iv（初始向量）是给 AES 分组加密用的：它保证同样的明文、同样的密钥，两次加密出来的密文也不同（本页每次生成 12 字节随机 iv）。如果 iv 固定，相同明文会产生相同密文，攻击者不用解密就能看出"这两段内容一样"，这在真实场景里经常直接泄漏信息。所以 salt 保护的是"口令 → 密钥"这一步，iv 保护的是"明文 → 密文"这一步，两者都在密文串里明文存着，公开它们不影响安全。
GCM 与 CBC 的区别是"认不认证"。AES-GCM 属于 AEAD（带关联数据的认证加密）：它在加密的同时算一个认证标签，解密时会先校验标签，只要密文、iv 或口令有任何一处不对，就整体拒绝并抛错——既解不出内容，也不会给你一段"看起来像明文"的垃圾。它还自带完整性保护，能挡住攻击者悄悄改动密文里的比特。AES-CBC 是更老的模式，只做加密、不做认证：它不校验任何东西，密文被改动一个字节，解密照样"成功"，只是解出来是乱码；攻击者还能利用这一点做 padding oracle 之类的攻击（服务端场景尤甚）。因此本页默认用 GCM，把 CBC 保留为兼容选项，并在选中时明确提示"不校验完整性、建议用 GCM"。另外，CBC 需要把明文补齐到 16 字节的整数倍，那部分填充规则也让它在面对篡改时更脆弱。
为什么这一页只做小数据，而不是当密码管理器用。把"加密/解密一个文本框"做得可靠，和"长期保管你的密码"是两件事。密码管理器要解决的是密钥怎么来（主密码 + 密钥文件）、条目怎么组织、怎么同步、怎么备份、设备丢了怎么办、主密码忘了怎么恢复——这些本页一个都没有：口令只存在你的脑子里，忘了就是真的打不开，密文串丢了也没有任何副本，浏览器一关输入框就清空。本页的价值在于"临时、一次性、小体积"的加密需求：给同事发一段配置片段、把一段笔记用口令包起来放进草稿箱、在共享文档里贴一段不希望被随手看到的文字。真要存长期凭证，请交给专业工具。
为什么加密不是"打开网页就算一遍"的事，而本页坚持不上传。任何"在线加密"服务，只要它把口令发到服务器，服务器就能在派生的那一刻拿到明文口令——加密就成了替别人保管秘密。浏览器内置的 crypto.subtle（WebCrypto）让我们可以完全在本地完成 AES 与 PBKDF2：口令与明文从输入框直接进入浏览器内核的加密例程，中间没有任何网络往返，也不会在浏览器本地存储里留下任何副本。这也带来一个必须说清的限制：WebCrypto 只在安全上下文（https 或 localhost）下可用，所以我们不会假装"http 也能用"，而是检测不到时直接告诉你换成 https 访问。至于"这段加密靠不靠得住"，请把它理解为：算法是浏览器厂商实现的成熟标准，参数与格式由本页定义并公开写在页面上，你可以自行核对；我们不对你的使用场景做任何安全承诺。
常见问题
不能。密文串里只有算法、迭代次数、salt、iv 和密文，没有口令的任何副本，也没有"找回口令"的通道——这正是它安全的原因。请把口令单独记住或存在你自己的密码管理器里，不要和密文串放在一起。
默认不能直接互通。密文串的六段格式是本页自定义的（QPS1 是版本号），别人至少要先按同样的规则拆出 salt 与 iv、用 PBKDF2-SHA256 派生同样的密钥、再以 GCM 与 128 位认证标签解密才能还原。本页不开这个兼容口子，是为了让"参数全部随密文走"这件事简单可核对：拿到密文串的人不需要猜参数。
我们不区分，也区分不了（如实说明，而不是编一个）。AES-GCM 校验失败时，浏览器抛出的都是同一个 OperationError：口令错、salt 被改、iv 被改、密文字节被改动，表现完全一样。CBC 更不可能区分：它不做校验，口令错时解出来是无效文本，我们只能据此判定失败。请依次自查：口令是否与加密时完全一致（大小写、空格、输入法全半角）；密文串是否被聊天软件自动换行、截断或替换过字符。
优先 GCM：它带完整性校验，密文被动过会直接报错，不会给你一段似是而非的乱码。只有当你需要与某个只支持 CBC 的旧系统对接时，才选 CBC，并接受"不校验完整性"的风险。迭代次数建议 15 万起步：台式机 15 万约几十毫秒，手机可能一两百毫秒；输 30 万或 60 万会更慢但更难被暴力尝试。同一段明文用同一口令加密两次会得到完全不同的密文，这是随机 salt 与 iv 的正常表现，两次都能解回原文。
因为本页依赖浏览器内置的 crypto.subtle，而浏览器只在安全上下文（https 或 localhost）下提供它，http 页面拿到的是 undefined。检测不到时页面会在顶部直接告诉你"请用 https 访问"，而不是让你点了没反应。老旧内核（IE、部分 App 内置浏览器）同样不提供该接口，换用较新的 Chrome / Edge / Firefox / Safari 即可。全过程在本机完成，检测失败时也不会偷偷降级成"把内容发到服务器加密"——本页根本没有这样的代码路径。