如果你在前端项目里搜过“加密插件”这类词大概率会撞上jsencrypt.js。这玩意不新但直到今天很多系统的登录接口、敏感字段提交用的都还是它。原因很简单RSA 非对称加密里在一堆可用方案中它属于“开箱即用、不管老的还是新的浏览器都能跑”的那一类。我见过不少人第一次用它写登录加密结果后端一解密就乱码或者长一点的文本直接返回 false然后愣是不知道问题出在哪。这篇文章我不打算从源码逐行讲算法而是以一个实际用过的过来人身份把 jsencrypt 的选型理由、密钥格式、跨语言联调、长文本处理、以及那些文档里不会写的坑一次性聊清楚。适合刚接手含加密需求的前端项目、或者前后端都在摸索 RSA 联调的读者。1. 为什么前端项目几乎都会用到 jsencrypt1.1 它到底解决什么问题前端加密最典型的场景是登录。一个账号密码输入框用户点完登录数据直接通过POST提交给后端。如果后端日志、网关、数据库里保存了明文的密码或身份证号你可以想象一旦日志泄露会是什么后果。于是大家想到在浏览器端就把密码加密让后端收到的是密文后端再用私钥解开。这时候 RSA 就被自然引出来了。RSA 是典型的非对称加密加密用公钥解密用私钥。公钥可以大大方方放在前端代码里私钥留在后端服务器。别人拿到公钥也没用因为只能加密、不能解密。这个特性让前端加密的“门槛”降低了很多你不需要设计一套密钥同步机制也不用担心中间人把加密方法逆向后偷走解密钥匙。jsencrypt 解决的正是这个场景它把 RSA 加密封装成了浏览器可用的 JavaScript 库你只需要引入文件、设置公钥、调一个encrypt方法就能把字符串加密成一段 Base64 密文。后端只要用标准 RSA 解密工具就能还原出原文。它还顺带支持私钥签名、公钥验签所以不仅在登录场景在一些需要防篡改的接口报文里也经常出场。1.2 RSA 密码学的入门理解想把 jsencrypt 用明白不需要啃完 RSA 的数学证明但至少得理解两个核心概念公钥加密、私钥解密以及私钥签名、公钥验签。你可以把 RSA 想成一个带锁的快递箱锁是公钥钥匙是私钥。任何人都能用这个锁把东西锁进箱子里公钥加密但只有拿着钥匙的人才能打开私钥解密。反过来如果一个人手上有钥匙他在箱子上贴了个自己的封印私钥签名其他人用锁就能确认这个封印确实是持钥匙的人贴的公钥验签。这种设计解决了一个很关键的问题不用提前在通信双方之间“同步密钥”。对称加密比如 AES需要双方都知道同一个密钥传输密钥本身就有风险RSA 则不同公钥本来就是公开的私钥只保存在服务器端这样整个系统的密钥分发压力小了很多。jsencrypt 库里encrypt方法对应公钥加密decrypt方法对应私钥解密sign和verify对应签名验签思路非常直观。1.3 为什么是 jsencrypt 而不是其他方案前端做 RSA 加密方案其实不少。原生 Web Crypto API 现在浏览器都支持node-forge 功能更全面crypto-js 也常被拿来用。但 jsencrypt 的优势在于三点第一老项目兼容性好对低版本浏览器的支持比原生 API 省心第二接口极简几行代码就能跑通适合业务开发而不是学术研究第三社区存量极大后端用什么语言解密都有现成资料这点对跨团队联调特别重要。如果你是全新项目我建议顺便看看原生 Web Crypto API毕竟浏览器原生性能好也不怕依赖库出问题。但如果你的项目里已经有一堆老代码或者你们后端长期用一段复制的 jsencrypt 解密逻辑那最省事的办法就是继续在 jsencrypt 上做。毕竟对一个业务系统来说稳定和团队熟悉度往往比框架先进重要得多。我也见过有人把 Web Crypto API 和 jsencrypt 混着用结果公钥格式互相不认调试到半夜才回退。所以我的建议是团队统一一种方案不要左右横跳。2. 密钥生成与格式第一个大坑2.1 用 openssl 一分钟生成密钥对先把工具链准备好。如果你电脑上有 OpenSSL直接用命令生成即可openssl genrsa -out private.pem 2048 openssl rsa -in private.pem -pubout -out public.pem第一条命令生成 2048 位的 RSA 私钥第二条命令从私钥里提取公钥。最终你会得到两个文件private.pem和public.pem。用文本编辑器打开它们长得像下面这样-----BEGIN PRIVATE KEY----- MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcw... -----END PRIVATE KEY----------BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... -----END PUBLIC KEY-----很多初学者会把这整段带BEGIN和END的字符串直接贴进前端代码这没问题。jsencrypt 的setPublicKey方法能识别这里面的 Base64 内容并解析出公钥。但踩坑的地方也经常出现在这里不同工具生成的公钥头部可能不一样而后端拿到的私钥格式也可能存在微妙的解析差异。2.2 公钥格式差异稍微留意过 PEM 文件的人会发现公钥有两种常见开头-----BEGIN PUBLIC KEY-----这是 PKCS#8 格式-----BEGIN RSA PUBLIC KEY-----这是 PKCS#1 格式OpenSSL 1.1 以上版本用rsa -pubout生成的默认是 PKCS#8 格式。但有些老系统、Java 代码、或者部分在线工具生成的可能是 PKCS#1 格式。jsencrypt 新版本对这两种格式做了兼容理论上都能解析。但我依然建议统一使用 PKCS#8 格式因为它的兼容面更广各种语言的标准库默认支持的也是这一种。如果你手里已经有了一个 PKCS#1 格式的公钥拿它加密一直失败可以用下面命令切换openssl rsa -RSAPublicKey_in -in rsa_pub_pkcs1.pem -pubout -out public_pkcs8.pem私钥这边也要注意。BEGIN RSA PRIVATE KEY是传统 PKCS#1 私钥BEGIN PRIVATE KEY是 PKCS#8 私钥。jsencrypt 对这两种也基本都支持但后端代码如果用 Java 标准库是能直接吃 PKCS#8 的如果拿到的是 PKCS#1需要转一下openssl pkcs8 -topk8 -nocrypt -in private_pkcs1.pem -out private_pkcs8.pem2.3 密钥长度的取舍密钥长度直接影响加密能力。jsencrypt 默认建议 2048 位这是目前在安全性和性能之间比较平衡的选择。1024 位的密钥已经被认为不够安全建议直接放弃4096 位虽然更难破解但密钥更长、运算更慢在浏览器端有明显的耗时增长。还有一点很实用RSA 加密的密文长度和密钥长度是强相关的。2048 位密钥加密后的密文 Base64 字符串长度基本固定在 344 个字符左右。如果你发现加密结果长度是动态变化的多半不是标准 RSA而是做了什么额外处理。这个特征在后端判断“是不是标准 RSA”时很有用。每个长度能加密的明文上限也跟密钥位数直接挂钩后面我会专门讲。这里先记住结论实际项目用 2048 位就够了并且不要随便把私钥传到前端代码里哪怕只是测试也不建议。公钥泄露没问题私钥一旦落到别人手里整个加密就成了摆设。3. 加密、解密、签名的完整实操3.1 引入与初始化jsencrypt 的引入方式很简单可以直接在 HTML 里引脚本script srchttps://cdn.jsdelivr.net/npm/jsencrypt3.3.2/bin/jsencrypt.min.js/script也可以走 npmnpm install jsencrypt前端代码里最基础的用法是这样import JSEncrypt from jsencrypt; const publicKey -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... -----END PUBLIC KEY-----; const crypt new JSEncrypt(); crypt.setPublicKey(publicKey); const encrypted crypt.encrypt(hello jsencrypt); console.log(encrypted); // Base64 密文如果你喜欢一次性构造完也可以这样写const crypt new JSEncrypt({ default_key: publicKey }); const encrypted crypt.encrypt(hello);注意encrypt方法返回的是 Base64 字符串。如果失败返回的可能是false或者空字符串false在 JSON 序列化后甚至会变成false这种字符串后端收到会非常莫名其妙。所以调用之后最好判断一下。3.2 后端联调跨语言解密不踩雷前端加密不是自己加密完事后端得能解密才叫联调成功。这里最容易出的问题有三个密文编码、填充方式、密钥格式。jsencrypt 加密后的密文默认是 Base64 编码后端拿到后要先Base64Decode再解密而不是直接拿字符串丢给 RSA 解密函数。如果后端犯了这个错一定会报“数据格式不正确”。填充方式上jsencrypt 使用标准的 RSA_PKCS1_PADDING也就是 PKCS#1 v1.5 填充。后端的解密库设置的时候必须指定成一样的否则解密出来的数据会不对。拿 Java 来说标准写法是Cipher.getInstance(RSA/ECB/PKCS1Padding)千万不能写成OAEPPadding。Node.js 里则要明确设置const crypto require(crypto); const fs require(fs); const privateKey fs.readFileSync(./private.pem, utf8); const ciphertext 前端传过来的Base64密文; const decrypted crypto.privateDecrypt( { key: privateKey, padding: crypto.constants.RSA_PKCS1_PADDING }, Buffer.from(ciphertext, base64) ); console.log(decrypted.toString(utf8)); // 原文Python 后端用rsa库解密时同样要保证padding是 PKCS1v15不能用 OAEP。很多报错“RSA_padding_check_PKCS1_type_2 error”本质就是填充方式不统一。3.3 不只是加密还能签名验签RSA 不止能做加密还能做签名。签名的作用是证明“这段数据确实是拥有私钥的一方发出来的”同时保证数据没有被篡改。在业务里最常见的用法是后端签名返回数据前端验签确认来源可信或者前端给关键参数签名后端验证完整性。jsencrypt 的签名方法长这样// 引入 CryptoJS 用于摘要算法 const CryptoJS require(crypto-js); const privateKey -----BEGIN PRIVATE KEY----- ... -----END PRIVATE KEY-----; const signer new JSEncrypt(); signer.setPrivateKey(privateKey); const signature signer.sign(待签名内容, CryptoJS.SHA256, sha256);验签对应const verifier new JSEncrypt(); verifier.setPublicKey(publicKey); const isValid verifier.verify(待签名内容, signature, CryptoJS.SHA256);这里有一个容易被忽略的点签名前要保证前后两端对“待签名内容”的定义完全一致包括拼接顺序、字段名、换行符多一个空格验签都会失败。我见过一个项目前端签名时用的是对象序列化后的字符串后端验签时又自己重新拼了一遍字段结果总是对不上最后才发现是字段顺序问题。签名这种事约定清楚比什么都重要。4. 两个高频翻车点长文本和中文乱码4.1 一次最多能加密多少字很多人第一次用 jsencrypt加密一个很短的密码没问题一加密长文本encrypt直接返回 false或者返回一段解密后完全不认识的内容。原因很简单RSA 对明文长度有严格限制。对于 PKCS#1 v1.5 填充理论最大明文长度为maxBytes keySize / 8 - 112048 位密钥也就是 2048 / 8 - 11 245 字节。中文在 UTF-8 编码下通常占 3 字节所以大约只能加密 81 个汉字。如果明文里还有英文、数字、符号还要具体按字节算。超过这个长度RSA 就无能为力了。所以在设计接口时先想清楚这个字段要传多长的数据。登录密码那几十个字节完全没压力但如果直接拿它去加密一笔几百字的备注文本妥妥会踩坑。4.2 长文本解决方案AESRSA 混合加密先看一段用于生成随机 AES 密钥并加密的代码结构import CryptoJS from crypto-js; import JSEncrypt from jsencrypt; // 1. 生成随机 AES 密钥16 字节 - 128 位 const aesKey CryptoJS.lib.WordArray.random(16).toString(); // 比如 a1b2c3d4e5f6a7b8 // 2. 用 AES 加密长文本 const encryptedData CryptoJS.AES.encrypt(longText, aesKey, { mode: CryptoJS.mode.ECB, padding: CryptoJS.pad.Pkcs7 }).toString(); // 3. 用 RSA 加密 AES 密钥 const rsa new JSEncrypt(); rsa.setPublicKey(publicKey); const encryptedKey rsa.encrypt(aesKey); // 4. 同时传给后端 const payload { encryptedData: encryptedData, encryptedKey: encryptedKey };后端 Node.js 解密const crypto require(crypto); const privateKey fs.readFileSync(./private.pem, utf8); // 1. RSA 解密出 AES 密钥 const aesKey crypto.privateDecrypt( { key: privateKey, padding: crypto.constants.RSA_PKCS1_PADDING }, Buffer.from(payload.encryptedKey, base64) ).toString(utf8); // 2. AES 解密出真正的数据 const decipher crypto.createDecipheriv(aes-128-ecb, aesKey, null); decipher.setAutoPadding(true); let decrypted Buffer.concat([ decipher.update(Buffer.from(payload.encryptedData, base64)), decipher.final() ]).toString(utf8);这里为了示例清晰使用了 ECB 模式但它不是最推荐的生产模式优先级上 CBC/GCM 会更安全。不过无论如何思路是一致的RSA 只负责加密一把临时生成的对称密钥真正的大数据量交给 AES。这样既绕开了 RSA 的长度限制又不需要在后端持久化任何对称密钥。每次请求生成新的 AES 密钥安全性也说得通。如果你不想自己管理 AES 密钥还有另一个思路把长文本在前端分片每片用同一个公钥加密后端按顺序解。但分片加密会让密文长度暴涨、还要协调切片顺序和边界相比 AESRSA 混合方案并不划算。我在实际项目里基本只推荐混合加密。4.3 中文乱码和兼容性问题中文乱码是 jsencrypt 老版本的一大痛点。老版本加密时对中文字符串的处理存在编码问题加密完传给后端解密出来是一团乱码或者后端解密直接报错。解决方法是升级到 jsencrypt 3.x 版本并且前后端都统一用 UTF-8 编码。如果你无法升级版本也可以在加密前手动转一次编码const encrypted crypt.encrypt(unescape(encodeURIComponent(str)));后端再逆操作decodeURIComponent(escape(decrypted))。这是一种兼容老环境的土办法能跑但不优雅。有条件还是直接升级依赖新版对 Unicode 的支持已经好很多了。另外一个常见兼容坑是公钥字符串里的换行。复制 PEM 公钥时如果格式化工具把换行去掉了比如变成一整行纯 Base64jsencrypt 可能解析失败。稳妥的办法是保留原始 PEM 格式让代码里直接使用带换行符的字符串模板。如果你从环境变量里读公钥记得检查字符串里有没有\n的转义问题。5. 常见问题速查与排查实录5.1 一张表解决 90% 的报错问题现象可能原因解决办法加密返回 false 或为空公钥格式不对、密钥与长度不匹配、明文过长检查公钥首尾标记减少明文长度改用混合加密方案密文长度莫名其妙变化使用了非标准 RSA 实现确认加密方法是否来自 jsencrypt查看密文是否为固定长度后端解密报 PKCS1_type_2 error填充方式不一致、密文被截断、公私钥不匹配统一使用 RSA_PKCS1_PADDING检查密文完整性核对密钥对中文解密乱码版本过老、前后端编码不一致升级 jsencrypt 3.x统一 UTF-8必要时用转码兼容签名验证失败待签名内容格式不一致签名参数顺序不同前后端固化签名串格式统一字段顺序和拼接规则setPublicKey 后仍然加密失败公钥字符串被去掉换行或丢失部分字符检查 PEM 字符串完整性保留换行符不要截取过长前缀这些内容看起来是零散问题实际上全都指向一个核心RSA 是一个格式极其敏感的工具参与方少了任何一个约定都会出岔子。不要觉得后端能自适应前后端必须提前对好密钥格式、编码和填充方式。5.2 一次线上问题的定位过程有一个项目我记得很清楚前端用 jsencrypt 加密登录密码后端是 Java 接口上线前联调一切正常上线后用户反馈“某些账号登录报错”。我打开页面一看encrypt返回了 false说明问题出在前端。排查步骤大致如下在控制台手动调用一次crypt.setPublicKey(publicKey)和crypt.encrypt(test)发现仍然是 false说明不是输入数据问题。打印 publicKey 变量发现字符串开头是-----BEGIN PUBLIC KEY-----但结尾被截断成了-----END PUBLI明显是配置中心下发密钥时把换行符丢了导致字符串被截断。修复配置中心转义把\n改成真实换行再测加密恢复正常。这个问题的教训不是 jsencrypt 自身而是密钥在系统间流转的过程中容易被“熵减”。公钥从后端到配置中心、再到前端环境变量中间任何一步在换行、缩进、转义上做了文章加密就挂。以后再遇到加密失败第一件事就是打印公钥字符串确认它从头到尾完整无损。6. 顺带聊聊“猪圈密码”的热点最近“猪圈密码在线加密解密”这个词搜的人不少正好跟加密解密话题高度相关我也简单说两句。猪圈密码Pigpen Cipher是一种非常古老的替换密码核心做法是把字母映射到一组网格和交叉符号里。比如 A 映射成┌┐这种格子形状I 就是中间的格子J-R 放进 X 形图案里S-Z 放进十字形图案里。在线工具网站上你输入一段英文它马上能给你输出一堆像“小方块”“拐角线”组合出来的符号看着很神秘其实就是一张映射表在来回替换。这类密码和 RSA 有本质区别替换密码的密钥空间很小几十种可能就枚举完了而且英文文本里字母频率分布明显哪怕没有密钥靠统计也能猜个七八成。所以猪圈密码只能用在游戏谜题、寻宝活动、桌面彩蛋这种娱乐场景没有任何真实的保密能力。如果哪天你在项目里看到有人用这种逻辑做安全校验还是劝他尽早换掉。我倒是觉得这类古典密码在技术上有个潜在用途做前端彩蛋或者活动文案的“隐藏关卡”。比如在页面上放一段看似乱码的符号用户解码成功后获得一个优惠码这种轻量玩法不需要引入重量级加密反而能提升趣味性。现代安全场景该用 RSA、AES 还是用它们没必要用古典密码硬扛。总结的话我不写了最后说点我个人的习惯。前端加密做久了我现在对 RSA 的态度是它有用但别神化。它解决的是“传输过程中不裸奔”的问题替代不了 HTTPS也不能弥补后端的权限漏洞。我一般把公钥放在前端一份私钥只在后端保留所有涉及签名的内容前后端严格统一串格式。能用 AES 加密大数据量就别死磕 RSA 的长度。每次接新项目先把密钥格式和填充方式定好再开写代码可以省一整个加班的调试时间。