简介本资源是一份面向前端开发者与跨端应用工程师的RSA加密解密实践方案特别适配uni-app等基于JavaScript的跨平台框架解决项目中敏感数据如登录凭证、支付信息需前端加密传输的核心安全需求。资源包共3个文件含2个关键JS脚本经定制修改的jsencrypt.js与封装好的rsa.js及1个说明文本总大小仅37KB轻量易集成其中jsencrypt.js已适配uni-app运行时环境规避了原版在Vue编译阶段报错的问题rsa.js则统一导出rsaEncrypt/rsaDecrypt方法大幅降低调用门槛。目前已有2805人学习下载资源附带公私钥在线生成指引与完整使用路径说明读者可直接复用加密逻辑、快速验证加解密流程并掌握uni-app环境下第三方加密库的兼容性改造思路。1. 前端 RSA 加密不是“配个公钥就完事”jsencrypt 在 uniapp 中跑通加密解密链路的真实门槛你是不是也试过在 uniapp 里用 jsencrypt填了公钥、调了 encrypt()结果后端死活解不开或者更玄学的是——本地 H5 能通真机调试却返回空字符串这不是你代码写错了而是前端做 RSA 加密时密钥格式、填充方式、字符编码、跨平台 JS 运行时差异这四座大山一座没翻过去整条链路就断在 request body 之前。这个资源不是教你怎么npm install jsencrypt而是把某跨平台系统中真实跑通的完整加解密闭环拆给你看从服务端生成兼容前端的 PEM 公钥开始到 uniapp 中处理中文、特殊符号、base64 换行、iOS/Android JSCore 差异再到后端能原样解密的完整参数对齐。它适合正在联调登录注册、支付签名、敏感字段上报的 uniapp 开发者尤其适合被“前端加密后端解不开”卡住超过半天的人——别再查 MDN 了问题根本不在文档里而在密钥生成那一刻的 openssl 参数选择上。2. 密钥生成与格式转换为什么你粘贴的公钥在 jsencrypt 里 parse 失败jsencrypt 对 PEM 格式极其敏感它不接受带-----BEGIN RSA PUBLIC KEY-----的传统 PKCS#1 格式只认-----BEGIN PUBLIC KEY-----的 PKCS#8它会因换行符\r\nvs\n、多余空格、末尾换行缺失而静默失败它甚至对 base64 编码块长度超 64 字符时是否换行都有强校验。很多开发者直接复制 OpenSSL 生成的公钥就往setPublicKey()里塞结果encrypt()返回null却无任何报错——这是 jsencrypt 的黑匣子式设计缺陷也是第一个必须亲手掰开的环节。2.1 服务端生成兼容前端的 PKCS#8 公钥Linux/macOS 终端实操# 第一步生成 2048 位 RSA 私钥务必用 -aes256 加密保护生产环境不可省 openssl genrsa -aes256 -out private_key.pem 2048 # 第二步从私钥导出 PKCS#8 格式公钥关键不是 rsa -pubout openssl rsa -in private_key.pem -pubout -out public_key_pkcs8.pem # 第三步清理公钥文件——删除所有空行、统一换行为 \n、确保首尾无空格 sed -i /^$/d public_key_pkcs8.pem # macOS sedLinux 用 sed -i /^$/d sed -i s/\r$// public_key_pkcs8.pem # 清除 Windows 换行残留提示openssl rsa -pubout输出的是 PKCS#1BEGIN RSA PUBLIC KEYjsencrypt 会 parse 失败必须用openssl rsa -pubout配合-outform PEM默认输出 PKCS#8BEGIN PUBLIC KEY。这是血泪经验——某导师曾因用错命令在测试环境反复重装密钥三次才定位到根源。2.2 将 PEM 公钥转为 jsencrypt 可直读的单行字符串jsencrypt 的setPublicKey()接口实际接收的是字符串但若你传入含换行的多行 PEM它会在内部 base64 解码时因\n截断而失败。正确做法是预处理为无换行 base64 字符串并手动补全 PEM 头尾// Node.js 环境下预处理部署前执行一次非运行时 const fs require(fs); const publicKeyPem fs.readFileSync(./public_key_pkcs8.pem, utf8); // 提取 base64 主体去掉头尾行 合并所有行 const base64Body publicKeyPem .split(\n) .filter(line !line.trim().startsWith(-----) line.trim().length 0) .join(); // 重新包裹为标准 PEM 字符串注意必须含换行但传给 jsencrypt 时要去掉 const cleanPem -----BEGIN PUBLIC KEY-----\n${base64Body}\n-----END PUBLIC KEY-----; console.log(cleanPem for jsencrypt:, cleanPem.replace(/\n/g, )); // 输出单行字符串参数说明cleanPem.replace(/\n/g, )输出形如-----BEGIN PUBLIC KEY-----MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...-----END PUBLIC KEY-----的单行字符串。此字符串可安全传入jsencrypt.setPublicKey()。注意-----BEGIN PUBLIC KEY-----和-----END PUBLIC KEY-----必须保留否则 jsencrypt 认不出格式。2.3 uniapp 中加载公钥的两种可靠方式方式一静态资源内联推荐用于固定公钥将上一步生成的单行字符串直接写入 JS 模块避免网络请求引入不确定性// utils/rsa.js import JSEncrypt from jsencrypt; export const getEncryptor () { const encryptor new JSEncrypt(); // ✅ 正确单行 PEM 字符串无换行符 const PUB_KEY -----BEGIN PUBLIC KEY-----MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoY3...-----END PUBLIC KEY-----; encryptor.setPublicKey(PUB_KEY); return encryptor; };方式二动态加载需服务端配合返回 clean PEM若公钥需动态更新如轮换机制服务端 API 必须返回已清洗的单行 PEM 字符串禁止返回原始多行 PEM// api/auth.js export const fetchPublicKey () { return $u.http.get(/api/v1/public-key).then(res { // 后端已保证返回 clean PEM单行含头尾标记 const cleanPem res.data.key; // e.g. -----BEGIN PUBLIC KEY-----...-----END PUBLIC KEY----- const encryptor new JSEncrypt(); encryptor.setPublicKey(cleanPem); // ✅ 直接传入 return encryptor; }); };逻辑说明uniapp 的uni.request返回数据默认为 JSON因此服务端需将 clean PEM 作为字符串字段返回如{ key: -----BEGIN... }而非直接返回 PEM 文件流。若走文件下载需用uni.downloadFileuni.getFileSystemManager().readFile但增加复杂度且易出错静态内联或 API 返回字符串是更稳的选择。3. jsencrypt 加密实战处理中文、emoji、长文本与 uniapp 特有陷阱前端加密不是encrypt(123456)就完事。真实业务场景中你要加密的是用户手机号、身份证号、地址、甚至带 emoji 的昵称。jsencrypt 底层用的是 JavaScript 的btoa()它只接受 Latin-1 编码字符串对 UTF-16JS 字符串默认中的中文、emoji 会直接乱码。更致命的是uniapp 的uni.getSystemInfoSync().platform返回ios/android/devtools而 iOS 的 JavaScriptCore 对btoa()的实现与 V8 有细微差异导致同一段中文在不同平台加密结果不一致——后端收到的密文永远解不开。3.1 中文与 emoji 安全加密UTF-8 编码预处理jsencrypt 不处理编码必须由你手动将 JS 字符串转为 UTF-8 byte array再转为 Latin-1 字符串供btoa()使用// utils/utf8.js export const stringToUtf8Bytes (str) { const encoder new TextEncoder(); // Web APIuniapp 支持 return encoder.encode(str); // Uint8Array }; export const utf8BytesToString (bytes) { const decoder new TextDecoder(); return decoder.decode(bytes); }; // utils/rsa.js续 export const encryptWithUtf8 (text, encryptor) { if (!text) return ; // Step 1: 转 UTF-8 bytes const utf8Bytes stringToUtf8Bytes(text); // Step 2: 将每个 byte 转为对应 Latin-1 字符0-255 → charCode 0-255 let latin1Str ; for (let i 0; i utf8Bytes.length; i) { latin1Str String.fromCharCode(utf8Bytes[i]); } // Step 3: 交给 jsencrypt 加密 return encryptor.encrypt(latin1Str) || ; }; // 使用示例 const encryptor getEncryptor(); const encrypted encryptWithUtf8(张三❤️138****1234, encryptor); console.log(Encrypted base64:, encrypted); // ✅ 可被后端标准 RSA 私钥解密参数说明TextEncoder.encode()将字符串按 UTF-8 编码为字节数组String.fromCharCode(byte)将每个字节映射为 Latin-1 字符byte 值 0-255 正好对应 charCode 0-255这样btoa()才能正确编码。此方案在 iOS/Android/H5 全平台一致彻底解决 emoji 乱码问题。3.2 长文本分块加密RSA 2048 的 245 字节硬限制RSA 加密有严格长度限制2048 位密钥最多加密 245 字节PKCS#1 v1.5 填充。若你直接传入 500 字符的地址encrypt()会静默返回null。不能靠 try-catch 捕获因为 jsencrypt 内部不抛错。必须提前切片// utils/rsa.js续 export const encryptLongText (text, encryptor, maxChunk 245) { if (!text) return ; const utf8Bytes stringToUtf8Bytes(text); const chunks []; // 按 maxChunk 字节切分 for (let i 0; i utf8Bytes.length; i maxChunk) { const chunk utf8Bytes.slice(i, i maxChunk); let latin1Str ; for (let j 0; j chunk.length; j) { latin1Str String.fromCharCode(chunk[j]); } const encryptedChunk encryptor.encrypt(latin1Str); if (!encryptedChunk) { throw new Error(RSA encryption failed at chunk ${i}, length ${chunk.length}); } chunks.push(encryptedChunk); } // 用特殊分隔符连接后端需按此规则解包 return chunks.join(||); // 自定义分隔符避开 base64 字符 }; // 使用示例加密长地址 const longAddr 北京市朝阳区建国路87号华贸中心3号写字楼12层1201室附近有星巴克和地铁10号线; const encryptedLong encryptLongText(longAddr, encryptor); console.log(Encrypted long text:, encryptedLong);逻辑说明maxChunk 245是 2048 位 RSA 的安全上限256 - 11 245。切片必须在 UTF-8 字节层面进行而非字符串字符数——因为一个中文占 3 字节一个 emoji 可能占 4 字节。||是自定义分隔符后端解密时用split(||)拆分再逐段用私钥解密后拼接 UTF-8 字节最后TextDecoder.decode()还原字符串。3.3 uniapp 真机调试的隐藏雷区iOS WKWebView 的 btoa 兼容性在 iOS 真机上btoa()对某些字节序列如连续多个 0x00可能返回undefined导致encrypt()返回null。这不是 jsencrypt 的 bug而是 WKWebView 的实现缺陷。解决方案是加一层 fallback// utils/rsa.js续 export const safeBtoa (str) { try { return btoa(str); } catch (e) { // WKWebView fallback手动实现 base64 编码仅针对 latin1 字符串 const chars ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789/; let result ; for (let i 0; i str.length; i 3) { const a str.charCodeAt(i) || 0; const b i 1 str.length ? str.charCodeAt(i 1) : 0; const c i 2 str.length ? str.charCodeAt(i 2) : 0; const byte1 a 2; const byte2 ((a 3) 4) | (b 4); const byte3 ((b 15) 2) | (c 6); const byte4 c 63; result chars.charAt(byte1) chars.charAt(byte2) (i 1 str.length ? : chars.charAt(byte3)) (i 2 str.length ? : chars.charAt(byte4)); } return result; } }; // 替换 jsencrypt 内部的 btoa需 patch // 注意此操作需在 new JSEncrypt() 前执行且仅影响当前实例 JSEncrypt.prototype.btoa safeBtoa;提示此 patch 仅在检测到 iOS 平台时启用uni.getSystemInfoSync().platform ios避免影响其他平台性能。这是某跨平台系统在线上灰度时发现的偶发失败原因——日志显示encrypt()返回null但控制台无报错最终定位到 WKWebView 的btoa异常。4. 常见问题排查五个让开发者重启 IDE 三次的 jsencrypt 翻车现场前端 RSA 加密失败90% 的问题不在算法本身而在环境、格式、编码这些“看不见的管道”。以下是某跨平台系统联调期间记录的真实踩坑清单每一条都附带复现路径和验证方法。4.1 现象encrypt()返回null控制台无任何错误原因公钥字符串含不可见字符如 BOM、零宽空格、Windows\r\n混入、或未包含-----BEGIN PUBLIC KEY-----头尾标记解决用 VS Code 打开公钥文件 →CtrlShiftP→ 输入 “Toggle Render Whitespace” 显示所有空格/换行确认首行是-----BEGIN PUBLIC KEY-----无空格无 BOM末行是-----END PUBLIC KEY-----无换行在 JS 中打印PUB_KEY.length和PUB_KEY.charCodeAt(0)确认首字符是-ASCII 45非BOM4.2 现象H5 正常iOS 真机返回空字符串Android 正常原因iOS WKWebView 的btoa()对特定字节序列如\0\0\0返回undefinedjsencrypt 未做容错解决复现加密字符串\0\0\0abc三个 null 字节验证console.log(btoa(\0\0\0abc))在 iOS 真机返回undefined方案按 3.3 节实现safeBtoa并 patch jsencrypt4.3 现象后端解密后得到乱码如޿但 base64 解密正常原因前端未做 UTF-8 → Latin-1 转换直接传入中文字符串btoa()将 UTF-16 码点当 Latin-1 编码解决验证console.log(张.charCodeAt(0))→ 24352UTF-16但btoa()期望 0-255方案必须用TextEncoder转 UTF-8 字节再String.fromCharCode(byte)映射4.4 现象加密长文本时部分 chunk 返回null但utf8Bytes.length显示未超 245原因切片在字符串层面而非字节层面进行例如‍emoji 组合占 4 字节若按字符切片会截断字节流解决用stringToUtf8Bytes(text).length获取真实字节数切片必须基于Uint8Array而非text.substring()验证console.log(new TextEncoder().encode(‍).length)→ 44.5 现象uniapponLoad中调用加密返回nullsetTimeout(() {}, 0)后调用正常原因jsencrypt 初始化依赖window对象而 uniapp 的onLoad生命周期中window可能未完全就绪尤其在分包加载时解决避免在onLoad/onShow等生命周期钩子中立即使用new JSEncrypt()改为按需初始化const encryptor getEncryptor()封装在工具函数中首次调用时创建实例或加简单检查if (typeof window ! undefined) { new JSEncrypt() } else { console.warn(JSEncrypt not available in this context) }5. 后端解密验证与联调技巧用 OpenSSL 命令行秒级定位加解密断点别等后端同学改完代码再测——你手头的终端就是最准的解密验证器。只要拿到服务端私钥和前端传来的 base64 密文三行命令就能确认问题出在前端加密、网络传输、还是后端解密。这是某跨平台系统每次上线前必做的“后悔药”步骤。5.1 从 base64 密文还原原始加密字节验证前端输出前端encrypt()返回的是 base64 字符串但 OpenSSL 解密需要二进制文件。先将其转为 DER 格式# 假设前端返回密文MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... echo MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... | \ tr -d \n | \ base64 -d encrypted.bin参数说明tr -d \n删除 base64 字符串中的换行jsencrypt 输出可能含\nbase64 -d将 base64 解码为原始加密字节存入encrypted.bin。此文件即 RSA 加密后的二进制数据大小应为 256 字节2048 位 / 8。5.2 用私钥解密并查看明文定位是否前端加密错误# 使用服务端私钥解密需输入私钥密码 openssl rsautl -decrypt -in encrypted.bin -inkey private_key.pem -passin pass:your_password decrypted.txt # 查看解密结果应为 UTF-8 文本 cat decrypted.txt | hexdump -C # 查看十六进制确认是否 UTF-8 编码 # 若显示乱码但 hexdump 显示 0xE4 0xB8 0xAD中的 UTF-8说明解密成功前端编码正确 # 若 hexdump 显示 0x00 0x00 0x00大量零字节说明前端未做 UTF-8 转换传入了错误字符串逻辑说明openssl rsautl -decrypt是最底层的 RSA 解密命令绕过所有后端框架封装。若此处解密失败100% 是前端加密问题若解密成功但内容乱码则是前端未做 UTF-8 → Latin-1 转换若解密成功且hexdump显示标准 UTF-8 字节如中文为E4 B8 AD则问题一定在后端代码如用了错误的字符集解码。5.3 模拟前端加密流程反向验证公钥是否可用当你怀疑公钥有问题可完全模拟前端流程用 OpenSSL 生成“应该被前端加密出”的密文再与前端实际输出比对# 准备明文UTF-8 编码的文本 echo -n 张三138****1234 plain.txt # 用公钥加密PKCS#1 v1.5 填充与 jsencrypt 一致 openssl rsautl -encrypt -pubin -inkey public_key_pkcs8.pem -in plain.txt -out encrypted_by_openssl.bin # 转为 base64与前端输出对比 base64 encrypted_by_openssl.bin | tr -d \n # 输出应与前端 jsencrypt.encrypt(...) 结果完全一致提示-pubin表示输入是公钥-inkey指定公钥文件-in plain.txt是明文文件-n避免 echo 添加换行-out输出二进制密文。此命令生成的密文就是 jsencrypt 在相同公钥、相同明文下应该输出的结果。若不一致说明公钥格式或填充方式不匹配。5.4 uniapp 联调黄金 checklist每次提测前必过检查项验证方法不通过表现修复动作公钥格式head -n1 public_key.pem显示-----BEGIN RSA PUBLIC KEY-----重生成openssl rsa -in priv.pem -pubout -out pub.pem前端编码console.log(encryptor.encrypt(a))返回null检查setPublicKey()传入的字符串是否含换行/BOM中文处理加密中后用 OpenSSL 解密解出 确认使用stringToUtf8Bytes()String.fromCharCode()长文本切片加密 300 字符文本返回null或部分null检查切片是否基于Uint8Array.length非text.lengthiOS 兼容性真机运行btoa(\0\0\0)返回undefined启用safeBtoapatch从那以后我每次交付 RSA 加密模块都强制走一遍这个 checklist先用 OpenSSL 解密前端密文确认内容再用 OpenSSL 加密明文反向比对最后在 iOS/Android/H5 三端各跑一次 emoji 加密。少一次就可能多一次凌晨三点的线上故障排查。希望帮到你。本文还有配套的精品资源点击获取