简介这份源码资源面向需要实现前后端安全通信的Web开发者重点解决前端敏感数据在传输过程中易被截取的问题。资源以RSA非对称加密为核心前端借助jsencrypt库完成公钥加密后端通过Java的RSAUtils类用私钥解密形成一套可直接参考的加密解密闭环方案适合具备一定JavaScript与Java基础、希望快速落地安全传输逻辑的开发者。压缩包共4个文件约54KB包含2个js脚本jsencrypt加密库与jQuery辅助库、1个html页面和1个java工具类分别承担前端加密调用、DOM与Ajax交互、页面展示及后端解密职责。目前已有3167人学习下载说明该方案在实际项目中具有较高的参考价值。读者可从中获取完整的加密解密实现思路、公钥私钥的Base64解析方式、Cipher解密流程以及前后端数据交互的代码组织方式便于直接移植到登录、支付等需要保护敏感字段的业务场景中。1. 前后端 RSA 加解密为什么 jsencrypt 配 Java 总在联调时翻车做过登录模块的人大概率都遇到过这个场景前端用 jsencrypt 把密码加密成一长串 Base64后端 Java 用Cipher.getInstance(RSA)一解抛BadPaddingException或者直接解出乱码。明明两边都是 RSA密钥也是同一对为什么就是不通问题往往不在算法本身而在填充模式、密钥格式、编码方式这三处细节没对齐。这套源码要解决的就是这件事前端用 jsencrypt 做公钥加密后端用 Java 做私钥解密把「前端加密传输、后端解密验签」这条链路完整跑通。它适合正在做登录、支付、敏感字段提交的开发者尤其是那种「前端已经引了 jsencrypt后端不想大改」的存量项目。下面我按实际拆包的顺序把密钥怎么生成、前端怎么调、后端怎么接、坑在哪一条条讲清楚。2. 密钥对生成与格式对齐PKCS#1 和 PKCS#8 别搞混2.1 为什么密钥格式是第一个坑RSA 的密钥有两种常见封装PKCS#1 和 PKCS#8。PKCS#1 的私钥头是-----BEGIN RSA PRIVATE KEY-----PKCS#8 的头是-----BEGIN PRIVATE KEY-----。jsencrypt 对公钥的容忍度比较高PKCS#1 和 PKCS#8 的公钥它都能读但 Java 这边默认的KeyFactory.getInstance(RSA)走的是 PKCS#8 规范你直接喂 PKCS#1 的私钥进去它会报InvalidKeySpecException。很多教程让你用openssl genrsa -out private.pem 1024生成密钥这条命令出来的是 PKCS#1 格式。前端能用后端一加载就炸。所以第一步不是写代码是把格式统一。2.2 用 openssl 生成一对可用的密钥我一般直接用下面这组命令生成 2048 位的密钥对并且把私钥转成 PKCS#8# 生成 PKCS#1 格式的私钥2048 位 openssl genrsa -out private_pkcs1.pem 2048 # 从私钥中提取公钥 openssl rsa -in private_pkcs1.pem -pubout -out public.pem # 把 PKCS#1 私钥转成 PKCS#8 格式Java 才能直接读 openssl pkcs8 -topk8 -inform PEM -in private_pkcs1.pem -outform PEM -nocrypt -out private_pkcs8.pem三条命令各管一件事第一条生成原始私钥第二条导出公钥给前端用第三条做格式转换。-nocrypt表示私钥不加密方便后端直接读取生产环境如果要用带密码的私钥去掉这个参数但后端加载时得额外传密码。提示1024 位密钥现在很多安全扫描会直接判不合格新项目一律上 2048 位。密钥长度翻倍加解密耗时大概增加 3 到 5 倍但登录这种低频操作完全无感。2.3 前端拿公钥后端拿私钥生成完之后public.pem里的内容去掉头尾的-----BEGIN PUBLIC KEY-----和-----END PUBLIC KEY-----再把换行去掉拼成一整行字符串这就是前端 jsencrypt 要的公钥。私钥文件private_pkcs8.pem整个交给后端放在配置文件或者密钥管理服务里不要硬编码在代码里。这里有个容易忽略的点公钥字符串里的换行符。jsencrypt 的setPublicKey对带换行的 PEM 格式其实也能处理但如果你是从配置文件读出来又经过某些框架的 trim 处理换行可能被吃掉导致公钥解析失败。稳妥做法是前端直接用一行式公钥后端用完整 PEM 文件。3. 前端 jsencrypt 加密从引入到拿到 Base64 密文3.1 引入方式和初始化jsencrypt 的引入很直接npm 装完 import 就行或者用 script 标签引 CDN 版本。初始化的时候把公钥塞进去import JSEncrypt from jsencrypt; // 公钥是一整行字符串不要带 PEM 头尾和换行 const PUBLIC_KEY MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...; const encryptor new JSEncrypt(); encryptor.setPublicKey(PUBLIC_KEY); // 加密返回 Base64 字符串 const plainText myPassword123; const cipherText encryptor.encrypt(plainText); console.log(cipherText); // 类似 hK8s... 的 Base64setPublicKey接收的字符串必须是纯 Base64 内容不能带-----BEGIN PUBLIC KEY-----这些标记。如果你从后端接口拿到的公钥带了头尾前端要先做一次字符串清洗。encrypt方法返回的是 Base64 编码的密文如果返回false说明公钥格式有问题或者明文太长超出了密钥能加密的长度。3.2 明文长度限制RSA 不是想加多长就加多长RSA 2048 位密钥用 PKCS#1 v1.5 填充单次最多加密 245 字节。jsencrypt 默认用的就是 PKCS#1 v1.5。如果你要加密的字段超过这个长度encrypt会返回false不会抛异常很容易被忽略。常见做法是敏感字段短密码、手机号、身份证号直接 RSA 加密长文本整个表单、大段 JSON用「RSA 加密 AES 密钥AES 加密正文」的混合方案。这套源码聚焦的是短字段场景长文本方案不在讨论范围但心里要有这个边界。3.3 编码问题UTF-8 中文别踩坑jsencrypt 内部对字符串的处理默认按 Latin1 走如果明文里有中文加密后再解密可能变成乱码。解决办法是在加密前先做一次 UTF-8 编码转换// 处理中文先转成 UTF-8 字节再加密 function utf8ToBase64(str) { return btoa(unescape(encodeURIComponent(str))); } const plainText 中文密码测试; const cipherText encryptor.encrypt(utf8ToBase64(plainText));不过更常见的做法是前端加密的字段本来就是密码、token 这类 ASCII 字符中文场景少。如果你的业务确实要加密中文记得在后端解密后做对应的 UTF-8 解码否则解出来是乱码。4. 后端 Java 解密Cipher 的填充模式必须和前端一致4.1 加载 PKCS#8 私钥Java 这边第一步是把 PKCS#8 私钥读进来生成PrivateKey对象import java.nio.file.Files; import java.nio.file.Paths; import java.security.KeyFactory; import java.security.PrivateKey; import java.security.spec.PKCS8EncodedKeySpec; import java.util.Base64; public class RsaDecryptor { public static PrivateKey loadPrivateKey(String pemFilePath) throws Exception { // 读取 PEM 文件内容 String pem new String(Files.readAllBytes(Paths.get(pemFilePath))); // 去掉头尾标记和换行 String privateKeyPem pem .replace(-----BEGIN PRIVATE KEY-----, ) .replace(-----END PRIVATE KEY-----, ) .replaceAll(\\s, ); // Base64 解码 byte[] keyBytes Base64.getDecoder().decode(privateKeyPem); // 用 PKCS8EncodedKeySpec 构造私钥 PKCS8EncodedKeySpec spec new PKCS8EncodedKeySpec(keyBytes); KeyFactory keyFactory KeyFactory.getInstance(RSA); return keyFactory.generatePrivate(spec); } }PKCS8EncodedKeySpec是专门用来处理 PKCS#8 格式的如果你拿的是 PKCS#1 私钥这个类会直接报错。replaceAll(\\s, )把所有制表符、换行、空格都清掉因为 Base64 解码器不认这些字符。4.2 解密方法填充模式写 RSA/ECB/PKCS1Padding拿到PrivateKey之后解密的核心就是Cipherimport javax.crypto.Cipher; import java.util.Base64; public static String decrypt(String cipherTextBase64, PrivateKey privateKey) throws Exception { // 注意这里必须写 RSA/ECB/PKCS1Padding和 jsencrypt 默认填充对齐 Cipher cipher Cipher.getInstance(RSA/ECB/PKCS1Padding); cipher.init(Cipher.DECRYPT_MODE, privateKey); byte[] cipherBytes Base64.getDecoder().decode(cipherTextBase64); byte[] plainBytes cipher.doFinal(cipherBytes); return new String(plainBytes, UTF-8); }关键在Cipher.getInstance(RSA/ECB/PKCS1Padding)这一行。如果你只写RSAJava 会按 provider 的默认值来不同 JDK 版本默认值可能不一样有的走RSA/ECB/PKCS1Padding有的走RSA/ECB/OAEPWithSHA-1AndMGF1Padding。一旦默认值变成 OAEP和 jsencrypt 的 PKCS#1 v1.5 就对不上解密直接抛BadPaddingException。所以填充模式必须显式写死。4.3 完整调用示例把加载和解密串起来一个最小的可运行类长这样public class RsaDemo { public static void main(String[] args) throws Exception { PrivateKey privateKey RsaDecryptor.loadPrivateKey(private_pkcs8.pem); String cipherFromFrontend hK8s...; // 前端传来的 Base64 密文 String plain RsaDecryptor.decrypt(cipherFromFrontend, privateKey); System.out.println(解密结果: plain); } }跑通之后你会看到前端加密的原始字符串。如果这里抛BadPaddingException九成是填充模式没对齐如果抛IllegalBlockSizeException多半是密文长度不对检查前端是不是把 Base64 字符串做了额外处理。5. 避坑排查五个让联调卡半天的真实问题5.1 解密报 BadPaddingException现象后端doFinal抛javax.crypto.BadPaddingException: Decryption error。原因最常见的是填充模式不一致。jsencrypt 用 PKCS#1 v1.5Java 如果没显式指定可能走了 OAEP。其次是密钥不匹配前端用的公钥和后端用的私钥不是同一对。解决确认Cipher.getInstance里写的是RSA/ECB/PKCS1Padding用 openssl 重新核对公私钥是否配对openssl rsa -in private_pkcs8.pem -pubout输出的公钥应该和前端用的一致。5.2 前端 encrypt 返回 false现象encryptor.encrypt(text)返回false不是字符串。原因公钥格式不对或者明文超长。公钥带了 PEM 头尾、有换行、或者 Base64 内容被截断都会导致setPublicKey失败。明文超过 245 字节也会返回 false。解决打印公钥字符串长度2048 位公钥的 Base64 内容大概 392 个字符明显短了就是被截断。明文超长就改用混合加密方案。5.3 解密出来是乱码现象解密成功但结果是????或者乱码字符。原因编码不一致。前端加密前如果对中文做了 UTF-8 转换后端解密后要用 UTF-8 构造字符串如果前端没转后端用 UTF-8 解出来也可能乱。解决统一约定前端加密前做encodeURIComponentbtoa后端解密后用new String(bytes, UTF-8)。或者干脆约定加密字段只用 ASCII 字符。5.4 JDK 版本导致的默认行为差异现象同样的代码在开发机跑通部署到服务器就报错。原因不同 JDK 版本或者不同安全 provider 对Cipher.getInstance(RSA)的默认填充实现可能不同。有的环境默认 PKCS#1有的默认 OAEP。解决永远显式写全RSA/ECB/PKCS1Padding不要依赖默认值。这条规则在加密相关代码里是铁律。5.5 密文传输过程中被 URL 编码破坏现象前端把密文拼在 URL 参数里传给后端后端解出来报错。原因Base64 密文里包含、/、这些字符放在 URL 里会被转义或截断。在 URL 解码时会变成空格导致 Base64 解码失败。解决密文用 POST body 传或者前端做一次encodeURIComponent后端对应URLDecoder.decode。更稳妥的做法是前端把 Base64 里的换成-、/换成_用 URL-safe Base64后端用Base64.getUrlDecoder()解。6. 进阶技巧用混合加密突破长度限制并做完整性校验RSA 单次加密长度有限实际项目里更常见的是「RSA AES」混合方案。思路很简单前端随机生成一个 AES 密钥用 AES 加密业务数据再用 RSA 公钥加密这个 AES 密钥两者一起传给后端。后端先用 RSA 私钥解出 AES 密钥再用 AES 解密业务数据。// 前端混合加密示意 import CryptoJS from crypto-js; // 1. 随机生成 AES 密钥 const aesKey CryptoJS.lib.WordArray.random(16).toString(); // 2. AES 加密业务数据 const encryptedData CryptoJS.AES.encrypt(JSON.stringify(payload), aesKey).toString(); // 3. RSA 加密 AES 密钥 const encryptedKey encryptor.encrypt(aesKey); // 4. 两个一起传给后端 fetch(/api/submit, { method: POST, body: JSON.stringify({ key: encryptedKey, data: encryptedData }) });后端对应地先用 RSA 解出aesKey再用 AES 解data。这样业务数据长度不受 RSA 限制AES 的加解密速度也远快于 RSA。另一个值得加的是完整性校验。RSA 加密本身不保证密文没被篡改PKCS#1 v1.5 填充在解密时会做一定校验但不够。常见做法是在明文里拼一个时间戳或者随机 nonce后端解密后校验时间戳在有效期内防止重放攻击。我一般会在明文 JSON 里加timestamp和nonce两个字段后端解密后先验时间戳超过 5 分钟的直接拒绝。验证整套链路是否可靠我的习惯是写一个最小的联调脚本前端加密固定字符串test_123后端解密后打印结果两边对上了再往业务里接。从那以后我每次接加密相关的需求都强制先跑一遍这个最小闭环确认填充模式、密钥格式、编码三件事都对齐了再动业务代码。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/19 12:19:24 · 阅读 1.2k 前后端RSA加解密实战：jsencrypt与Java联调避坑指南
简介这份源码资源面向需要实现前后端安全通信的Web开发者重点解决前端敏感数据在传输过程中易被截取的问题。资源以RSA非对称加密为核心前端借助jsencrypt库完成公钥加密后端通过Java的RSAUtils类用私钥解密形成一套可直接参考的加密解密闭环方案适合具备一定JavaScript与Java基础、希望快速落地安全传输逻辑的开发者。压缩包共4个文件约54KB包含2个js脚本jsencrypt加密库与jQuery辅助库、1个html页面和1个java工具类分别承担前端加密调用、DOM与Ajax交互、页面展示及后端解密职责。目前已有3167人学习下载说明该方案在实际项目中具有较高的参考价值。读者可从中获取完整的加密解密实现思路、公钥私钥的Base64解析方式、Cipher解密流程以及前后端数据交互的代码组织方式便于直接移植到登录、支付等需要保护敏感字段的业务场景中。1. 前后端 RSA 加解密为什么 jsencrypt 配 Java 总在联调时翻车做过登录模块的人大概率都遇到过这个场景前端用 jsencrypt 把密码加密成一长串 Base64后端 Java 用Cipher.getInstance(RSA)一解抛BadPaddingException或者直接解出乱码。明明两边都是 RSA密钥也是同一对为什么就是不通问题往往不在算法本身而在填充模式、密钥格式、编码方式这三处细节没对齐。这套源码要解决的就是这件事前端用 jsencrypt 做公钥加密后端用 Java 做私钥解密把「前端加密传输、后端解密验签」这条链路完整跑通。它适合正在做登录、支付、敏感字段提交的开发者尤其是那种「前端已经引了 jsencrypt后端不想大改」的存量项目。下面我按实际拆包的顺序把密钥怎么生成、前端怎么调、后端怎么接、坑在哪一条条讲清楚。2. 密钥对生成与格式对齐PKCS#1 和 PKCS#8 别搞混2.1 为什么密钥格式是第一个坑RSA 的密钥有两种常见封装PKCS#1 和 PKCS#8。PKCS#1 的私钥头是-----BEGIN RSA PRIVATE KEY-----PKCS#8 的头是-----BEGIN PRIVATE KEY-----。jsencrypt 对公钥的容忍度比较高PKCS#1 和 PKCS#8 的公钥它都能读但 Java 这边默认的KeyFactory.getInstance(RSA)走的是 PKCS#8 规范你直接喂 PKCS#1 的私钥进去它会报InvalidKeySpecException。很多教程让你用openssl genrsa -out private.pem 1024生成密钥这条命令出来的是 PKCS#1 格式。前端能用后端一加载就炸。所以第一步不是写代码是把格式统一。2.2 用 openssl 生成一对可用的密钥我一般直接用下面这组命令生成 2048 位的密钥对并且把私钥转成 PKCS#8# 生成 PKCS#1 格式的私钥2048 位 openssl genrsa -out private_pkcs1.pem 2048 # 从私钥中提取公钥 openssl rsa -in private_pkcs1.pem -pubout -out public.pem # 把 PKCS#1 私钥转成 PKCS#8 格式Java 才能直接读 openssl pkcs8 -topk8 -inform PEM -in private_pkcs1.pem -outform PEM -nocrypt -out private_pkcs8.pem三条命令各管一件事第一条生成原始私钥第二条导出公钥给前端用第三条做格式转换。-nocrypt表示私钥不加密方便后端直接读取生产环境如果要用带密码的私钥去掉这个参数但后端加载时得额外传密码。提示1024 位密钥现在很多安全扫描会直接判不合格新项目一律上 2048 位。密钥长度翻倍加解密耗时大概增加 3 到 5 倍但登录这种低频操作完全无感。2.3 前端拿公钥后端拿私钥生成完之后public.pem里的内容去掉头尾的-----BEGIN PUBLIC KEY-----和-----END PUBLIC KEY-----再把换行去掉拼成一整行字符串这就是前端 jsencrypt 要的公钥。私钥文件private_pkcs8.pem整个交给后端放在配置文件或者密钥管理服务里不要硬编码在代码里。这里有个容易忽略的点公钥字符串里的换行符。jsencrypt 的setPublicKey对带换行的 PEM 格式其实也能处理但如果你是从配置文件读出来又经过某些框架的 trim 处理换行可能被吃掉导致公钥解析失败。稳妥做法是前端直接用一行式公钥后端用完整 PEM 文件。3. 前端 jsencrypt 加密从引入到拿到 Base64 密文3.1 引入方式和初始化jsencrypt 的引入很直接npm 装完 import 就行或者用 script 标签引 CDN 版本。初始化的时候把公钥塞进去import JSEncrypt from jsencrypt; // 公钥是一整行字符串不要带 PEM 头尾和换行 const PUBLIC_KEY MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...; const encryptor new JSEncrypt(); encryptor.setPublicKey(PUBLIC_KEY); // 加密返回 Base64 字符串 const plainText myPassword123; const cipherText encryptor.encrypt(plainText); console.log(cipherText); // 类似 hK8s... 的 Base64setPublicKey接收的字符串必须是纯 Base64 内容不能带-----BEGIN PUBLIC KEY-----这些标记。如果你从后端接口拿到的公钥带了头尾前端要先做一次字符串清洗。encrypt方法返回的是 Base64 编码的密文如果返回false说明公钥格式有问题或者明文太长超出了密钥能加密的长度。3.2 明文长度限制RSA 不是想加多长就加多长RSA 2048 位密钥用 PKCS#1 v1.5 填充单次最多加密 245 字节。jsencrypt 默认用的就是 PKCS#1 v1.5。如果你要加密的字段超过这个长度encrypt会返回false不会抛异常很容易被忽略。常见做法是敏感字段短密码、手机号、身份证号直接 RSA 加密长文本整个表单、大段 JSON用「RSA 加密 AES 密钥AES 加密正文」的混合方案。这套源码聚焦的是短字段场景长文本方案不在讨论范围但心里要有这个边界。3.3 编码问题UTF-8 中文别踩坑jsencrypt 内部对字符串的处理默认按 Latin1 走如果明文里有中文加密后再解密可能变成乱码。解决办法是在加密前先做一次 UTF-8 编码转换// 处理中文先转成 UTF-8 字节再加密 function utf8ToBase64(str) { return btoa(unescape(encodeURIComponent(str))); } const plainText 中文密码测试; const cipherText encryptor.encrypt(utf8ToBase64(plainText));不过更常见的做法是前端加密的字段本来就是密码、token 这类 ASCII 字符中文场景少。如果你的业务确实要加密中文记得在后端解密后做对应的 UTF-8 解码否则解出来是乱码。4. 后端 Java 解密Cipher 的填充模式必须和前端一致4.1 加载 PKCS#8 私钥Java 这边第一步是把 PKCS#8 私钥读进来生成PrivateKey对象import java.nio.file.Files; import java.nio.file.Paths; import java.security.KeyFactory; import java.security.PrivateKey; import java.security.spec.PKCS8EncodedKeySpec; import java.util.Base64; public class RsaDecryptor { public static PrivateKey loadPrivateKey(String pemFilePath) throws Exception { // 读取 PEM 文件内容 String pem new String(Files.readAllBytes(Paths.get(pemFilePath))); // 去掉头尾标记和换行 String privateKeyPem pem .replace(-----BEGIN PRIVATE KEY-----, ) .replace(-----END PRIVATE KEY-----, ) .replaceAll(\\s, ); // Base64 解码 byte[] keyBytes Base64.getDecoder().decode(privateKeyPem); // 用 PKCS8EncodedKeySpec 构造私钥 PKCS8EncodedKeySpec spec new PKCS8EncodedKeySpec(keyBytes); KeyFactory keyFactory KeyFactory.getInstance(RSA); return keyFactory.generatePrivate(spec); } }PKCS8EncodedKeySpec是专门用来处理 PKCS#8 格式的如果你拿的是 PKCS#1 私钥这个类会直接报错。replaceAll(\\s, )把所有制表符、换行、空格都清掉因为 Base64 解码器不认这些字符。4.2 解密方法填充模式写 RSA/ECB/PKCS1Padding拿到PrivateKey之后解密的核心就是Cipherimport javax.crypto.Cipher; import java.util.Base64; public static String decrypt(String cipherTextBase64, PrivateKey privateKey) throws Exception { // 注意这里必须写 RSA/ECB/PKCS1Padding和 jsencrypt 默认填充对齐 Cipher cipher Cipher.getInstance(RSA/ECB/PKCS1Padding); cipher.init(Cipher.DECRYPT_MODE, privateKey); byte[] cipherBytes Base64.getDecoder().decode(cipherTextBase64); byte[] plainBytes cipher.doFinal(cipherBytes); return new String(plainBytes, UTF-8); }关键在Cipher.getInstance(RSA/ECB/PKCS1Padding)这一行。如果你只写RSAJava 会按 provider 的默认值来不同 JDK 版本默认值可能不一样有的走RSA/ECB/PKCS1Padding有的走RSA/ECB/OAEPWithSHA-1AndMGF1Padding。一旦默认值变成 OAEP和 jsencrypt 的 PKCS#1 v1.5 就对不上解密直接抛BadPaddingException。所以填充模式必须显式写死。4.3 完整调用示例把加载和解密串起来一个最小的可运行类长这样public class RsaDemo { public static void main(String[] args) throws Exception { PrivateKey privateKey RsaDecryptor.loadPrivateKey(private_pkcs8.pem); String cipherFromFrontend hK8s...; // 前端传来的 Base64 密文 String plain RsaDecryptor.decrypt(cipherFromFrontend, privateKey); System.out.println(解密结果: plain); } }跑通之后你会看到前端加密的原始字符串。如果这里抛BadPaddingException九成是填充模式没对齐如果抛IllegalBlockSizeException多半是密文长度不对检查前端是不是把 Base64 字符串做了额外处理。5. 避坑排查五个让联调卡半天的真实问题5.1 解密报 BadPaddingException现象后端doFinal抛javax.crypto.BadPaddingException: Decryption error。原因最常见的是填充模式不一致。jsencrypt 用 PKCS#1 v1.5Java 如果没显式指定可能走了 OAEP。其次是密钥不匹配前端用的公钥和后端用的私钥不是同一对。解决确认Cipher.getInstance里写的是RSA/ECB/PKCS1Padding用 openssl 重新核对公私钥是否配对openssl rsa -in private_pkcs8.pem -pubout输出的公钥应该和前端用的一致。5.2 前端 encrypt 返回 false现象encryptor.encrypt(text)返回false不是字符串。原因公钥格式不对或者明文超长。公钥带了 PEM 头尾、有换行、或者 Base64 内容被截断都会导致setPublicKey失败。明文超过 245 字节也会返回 false。解决打印公钥字符串长度2048 位公钥的 Base64 内容大概 392 个字符明显短了就是被截断。明文超长就改用混合加密方案。5.3 解密出来是乱码现象解密成功但结果是????或者乱码字符。原因编码不一致。前端加密前如果对中文做了 UTF-8 转换后端解密后要用 UTF-8 构造字符串如果前端没转后端用 UTF-8 解出来也可能乱。解决统一约定前端加密前做encodeURIComponentbtoa后端解密后用new String(bytes, UTF-8)。或者干脆约定加密字段只用 ASCII 字符。5.4 JDK 版本导致的默认行为差异现象同样的代码在开发机跑通部署到服务器就报错。原因不同 JDK 版本或者不同安全 provider 对Cipher.getInstance(RSA)的默认填充实现可能不同。有的环境默认 PKCS#1有的默认 OAEP。解决永远显式写全RSA/ECB/PKCS1Padding不要依赖默认值。这条规则在加密相关代码里是铁律。5.5 密文传输过程中被 URL 编码破坏现象前端把密文拼在 URL 参数里传给后端后端解出来报错。原因Base64 密文里包含、/、这些字符放在 URL 里会被转义或截断。在 URL 解码时会变成空格导致 Base64 解码失败。解决密文用 POST body 传或者前端做一次encodeURIComponent后端对应URLDecoder.decode。更稳妥的做法是前端把 Base64 里的换成-、/换成_用 URL-safe Base64后端用Base64.getUrlDecoder()解。6. 进阶技巧用混合加密突破长度限制并做完整性校验RSA 单次加密长度有限实际项目里更常见的是「RSA AES」混合方案。思路很简单前端随机生成一个 AES 密钥用 AES 加密业务数据再用 RSA 公钥加密这个 AES 密钥两者一起传给后端。后端先用 RSA 私钥解出 AES 密钥再用 AES 解密业务数据。// 前端混合加密示意 import CryptoJS from crypto-js; // 1. 随机生成 AES 密钥 const aesKey CryptoJS.lib.WordArray.random(16).toString(); // 2. AES 加密业务数据 const encryptedData CryptoJS.AES.encrypt(JSON.stringify(payload), aesKey).toString(); // 3. RSA 加密 AES 密钥 const encryptedKey encryptor.encrypt(aesKey); // 4. 两个一起传给后端 fetch(/api/submit, { method: POST, body: JSON.stringify({ key: encryptedKey, data: encryptedData }) });后端对应地先用 RSA 解出aesKey再用 AES 解data。这样业务数据长度不受 RSA 限制AES 的加解密速度也远快于 RSA。另一个值得加的是完整性校验。RSA 加密本身不保证密文没被篡改PKCS#1 v1.5 填充在解密时会做一定校验但不够。常见做法是在明文里拼一个时间戳或者随机 nonce后端解密后校验时间戳在有效期内防止重放攻击。我一般会在明文 JSON 里加timestamp和nonce两个字段后端解密后先验时间戳超过 5 分钟的直接拒绝。验证整套链路是否可靠我的习惯是写一个最小的联调脚本前端加密固定字符串test_123后端解密后打印结果两边对上了再往业务里接。从那以后我每次接加密相关的需求都强制先跑一遍这个最小闭环确认填充模式、密钥格式、编码三件事都对齐了再动业务代码。希望帮到你。本文还有配套的精品资源点击获取