Java Web文件夹递归上传与SM4加密落盘：从JSP到Servlet完整实现-北京尧图网络

接到过几个类似的需求都是内网里的文件管理系统要求挺一致Java后台、JSP做页面、用户能直接在网页上选整个文件夹把里面多层级的目录结构和文件一次性传上来落盘后文件还不能是明文的。这个“文件夹递归上传服务端涉密加密”的组合看起来是两个独立问题做起来才会发现真正的难点全在边界上浏览器到底能给多少信息、目录结构怎么还原、文件流怎么边传边加密、密钥放哪里才算安全。这篇文章就按我实际趟过的路子把从JSP页面到Servlet再到加密落盘的整套实现拆开讲重点说清楚每一步为什么这么做以及哪些坑是文档里不会写的。1. 需求拆解这题到底在考什么1.1 文件夹上传的真实需求是什么先说一个最常见的误区很多人一听“文件夹上传”下意识就以为是在页面上放一个input让用户按住Ctrl把所有文件都选上。这不是文件夹上传这只是多选文件。文件夹上传的核心是“递归”两个字——用户选的是一棵目录树树上有文件夹、子文件夹、文件上传完成后服务端必须把这棵树的层级关系原样还原出来。也就是说传的不只是“内容”还包括“结构”。用业务场景来理解更直观一些。一个单位要做历史资料电子化归档整理好的资料在本地是这样的2024年档案/部门A/合同类/编号001/合同正文.pdf。如果只支持多选文件传到服务端就变成一堆无层级的散文件还得有人重新组织目录工作量巨大。而文件夹递归上传可以把部门A、合同类这些层级完整搬到服务器上配合权限体系还能按目录控制访问范围这才是管理系统的正经需求。从技术实现角度看这里涉及的不只是“传文件”还包括“传路径”。浏览器提供的文件对象里隐藏着一个相对路径字段前端拿到它之后要么把整棵目录树序列化成JSON交给后端要么在逐个上传时携带相对路径让后端动态建目录。这两种方案后面我会详细对比先记住结论在处理大量文件且目录层级很深时后者更稳。1.2 “涉密加密”在Web端落地时的设计约束标题里提到军工涉密加密这类场景对密码产品有严格合规要求。我在这篇文章里只讨论技术层面的普适设计不针对具体涉密项目给出所谓“标准答案”因为真正涉密系统的密码算法、密钥管理、审计方案都必须遵循国家密码管理部门的相关规定使用合规的密码产品和硬件设备。普通企业项目要做的是把加密能力设计得足够严密并预留合规对接入口。脱离开“涉密”这个限定词任何一个要求“文件传上去之后不能被直接拿走”的系统核心其实就三件事文件内容加密、密钥安全管理、密文完整性校验。文件内容加密的目的是即使硬盘被物理拿走也拿不到明文密钥管理的目的是让算法再强密钥泄露就等于白加密完整性校验的目的是防止密文被篡改或替换。这里有个原则必须前置说明加解密用的算法种子和主密钥绝不能硬编码在Java代码里也不能和密文放在同一个目录。常见的合理做法是主密钥独立存储系统运行时加载到内存密钥文件本身限制操作系统权限要求更高的场景则直接对接硬件加密机通过专用接口完成加解密运算密钥根本不进内存。后面我给的CryptoUtil是给普通项目兜底的实现方式涉密场景请在此基础上对接合规密码设备。2. 方案设计从浏览器到服务端的链路规划2.1 浏览器端文件夹选取一个属性解决大半问题HTML5提供了webkitdirectory属性给input[typefile]加上它之后用户点选的不再是多个文件而是整个文件夹。选择完成后浏览器会把文件夹内所有文件展开成一个文件数组每个File对象自带一个webkitRelativePath属性这个属性就是文件相对所选文件夹的路径比如2024年档案/部门A/合同类/编号001/合同正文.pdf。所以前端不需要自己递归去扫目录不需要任何额外处理只要把这个属性挂上去浏览器就免费送了我们一张完整的“目录快照”。Chrome和Edge对它的支持非常稳定新版本Firefox也支持Safari在新版本中也已经支持。但开发时我建议还是引导用户使用Chrome或Edge兼容性最稳。有了webkitRelativePath剩下的工作其实是两件事第一如何把文件数组队列化并控制上传并发第二如何把相对路径传给后端让后端能按路径动态重建目录。这里不需要生成中间层级的JSON树因为相对路径本身就携带了全部层级信息后端拿到路径字符串后按分隔符拆解即可。2.2 目录树的上传策略逐个携带路径更稳我见过两种实现思路也分别踩过坑。第一种是前端把目录树做成JSON比如[{name:部门A, children:[{name:合同类, children:[...]}]}]然后一次性POST给后端后端递归解析JSON、创建目录、再逐个上传文件。这种方案实现起来很“清醒”——目录树在逻辑上很完整前端展示也方便。但实际落地会发现文件一多JSON体积膨胀一次请求携带太多数据容易超时而且上传进度难以细化到单个文件用户看着一个转圈圈不知道传到哪里体验很差。第二种就是我现在推荐的前端遍历文件数组每个文件单独发一次上传请求在FormData里携带文件流和它的webkitRelativePath后端拿到路径后使用file.getParentFile().mkdirs()动态创建所有父目录再把文件写入。说白了目录结构不在“某一次请求”里传而是在“每一个文件”的相对路径里隐含地传递。上传一个500个文件的文件夹就是500个独立的请求每个请求自带一个子路径。这个方案的优势有两个。第一天然支持单文件维度的失败重试哪个文件传坏了就重传哪个不会因为一个文件失败导致整批作废第二后端是边收边建目录、边写边加密每一个文件落盘时都独立完成加密不需要把所有文件聚齐再统一处理内存压力小很多。2.3 加密体系设计对称加密与非对称加密的分工文件加密最头疼的问题不是“加个密”而是“密钥放哪儿”。如果所有文件都用同一个密钥加密那这个密钥一旦泄露所有文件全部失守如果每个文件都生成独立密钥那密钥的保存和传递又成了新问题。所以我推荐业内最常用的“信封加密”思路按角色分三层第一层主密钥。它是整个体系的根由系统初始化时生成不参与具体文件的加解密运算只负责保护下一层密钥。第二层文件密钥。每个文件上传成功后系统随机生成一个临时密钥专门给这个文件做SM4对称加密。文件被人拿走没有这个临时密钥解不开。第三层信封保护。文件密钥不直接明文存储而是用主密钥或主密钥体系下的公钥加密一次形成一个“信封”。需要解密文件时先解信封取出文件密钥再用文件密钥解文件。这样即使攻击者拿到数据库里的所有密钥字段看到的也都是密文。算法选型上普通商用项目推荐使用国密SM4做对称加密、SM3做摘要校验有条件的项目考虑SM2做密钥协商或信封保护。特别提醒一句如果项目实际是要对标涉密等级那么算法实现不能随便拿开源库就跑必须对接国家密码管理部门批准使用的密码产品合规问题不能靠开源代码解决。传输层面还有一道前置防线——整条HTTP链路必须启用TLS/HTTPS否则文件在网络上明文传输服务端再怎么加密也拦不住中间抓包。这个点太基础反而经常被忽略我在这里划个重点。2.4 并发控制不要一股脑把文件全发出去用户选了一个包含1000个文件的文件夹如果前端代码写的是for循环逐个发请求那浏览器会同时建立几十上百个连接服务端连接数瞬间被打满还可能触发中间件或操作系统的连接限制最后表现为大量请求超时、重试、甚至Tomcat连接池被拖垮。正确做法是维护一个“并发窗口”比如同时只允许3个文件在上传每个文件完成后再从队列里取下一个。这样既保证了吞吐又给服务端留了喘息空间。这个并行度不是越高越好常规内网环境下3到5路并行效果就比较理想如果文件都是几十MB的大文件可以再降一点2路并行也够。至于服务端Servlet默认是每请求一线程Tomcat的默认线程池也就200左右如果前端不做并发限制1000个文件同时进来直接就把线程池耗尽了。所以并发限制必须做在前端这是我在实际项目里反复强调的一点。3. 代码实现从JSP到Servlet的完整打通3.1 JSP页面与文件夹选择入口写法先看页面。下面这个JSP虽然文件扩展名是.jsp但页面里没有Java脚本片段因为渲染逻辑完全可以交给HTML和原生JS。JSP在这里的角色就是“视图模板”这样也为以后改成纯静态页面或Vue/React留下余地。% page contentTypetext/html;charsetUTF-8 languagejava % !DOCTYPE html html head meta charsetUTF-8 title目录结构递归上传/title /head body div h3选择要上传的文件夹/h3 !-- 核心属性webkitdirectory multiple -- input typefile idfolderInput namedirFiles webkitdirectory multiple / button typebutton idstartBtn onclickdoUpload()开始上传/button div idprogressArea/div /div script srcupload.js/script /body /html注意webkitdirectory和multiple这两个属性一个都不能少。webkitdirectory决定用户选择的是文件夹multiple决定可以一次性选多个文件夹如果不加multiple某些浏览器一次只能选一个文件夹。选完之后用户点击“开始上传”按钮触发上传逻辑。页面本身没什么玄机真正的核心在upload.js和Servlet里。3.2 前端递归队列文件列表处理与并发上传前端JS是整个方案里最关键的环节。文件选好之后fileInput.files里是浏览器扁平化之后的所有文件对象它们共享同一个相对路径前缀。我的处理策略是先把文件数组保存到全局变量点击“开始上传”后再建立并发队列。const fileInput document.getElementById(folderInput); const progressArea document.getElementById(progressArea); let fileArray []; fileInput.addEventListener(change, function(e) { // 浏览器已经帮我们完成了“递归展开”files本身就是平铺的文件列表 fileArray Array.from(e.target.files); progressArea.innerHTML 共选择 fileArray.length 个文件; }); const CONCURRENCY_LIMIT 3; let nextIndex 0; let successCount 0; let failCount 0; function doUpload() { if (fileArray.length 0) { alert(请先选择文件夹); return; } nextIndex 0; successCount 0; failCount 0; // 开CONCURRENCY_LIMIT个并发工人 for (let i 0; i CONCURRENCY_LIMIT; i) { launchWorker(); } } function launchWorker() { if (nextIndex fileArray.length) { return; // 队列中没有更多文件工人结束 } const currentIndex nextIndex; const file fileArray[currentIndex]; const formData new FormData(); formData.append(file, file); // 关键字段携带文件的相对路径 formData.append(relativePath, file.webkitRelativePath || file.name); fetch(/uploadServlet, { method: POST, body: formData }).then(function(response) { return response.text(); }).then(function(msg) { if (msg.startsWith(success)) { successCount; progressArea.innerHTML 成功: successCount | 失败: failCount | 当前: file.webkitRelativePath br/ msg; } else { failCount; progressArea.innerHTML 失败: file.webkitRelativePath -- msg; } }).catch(function(err) { failCount; progressArea.innerHTML 网络错误: file.webkitRelativePath -- err; }).finally(function() { // 无论成功失败都继续拉下一个文件 launchWorker(); }); }这个并发队列的思路很朴素维护一个全局索引nextIndex每个“工人”完成一个文件后立刻去拿下一个索引的文件。三个工人并发运行每个工人都是串行处理自己的任务整体上就形成了稳定的3路并发流。不需要第三方库不需要AsyncPool十几行原生JS就能解决问题。这里有个细节值得提醒file.webkitRelativePath在浏览器里的值是带目录层级的前缀字符串比如demo/2024年档案/部门A/a.pdf传给后端时后端需要从路径里把文件名拆出来路径部分则用来创建目录。可以直接用/分隔Windows兼容性这里不用过度担心因为webkitRelativePath统一使用/作为分隔符。3.3 Servlet接收路径还原、目录创建与存储服务端我用的原生Servlet没有引入Spring框架这样逻辑更聚焦。首先处理路径还原从请求里取出relativePath参数用File对象拼出目标路径并动态创建父目录。package com.example.upload; import javax.servlet.ServletException; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.Part; import java.io.File; import java.io.IOException; WebServlet(/uploadServlet) public class UploadServlet extends HttpServlet { // 文件存储根目录建议配置在外部文件或环境变量不要硬编码在代码里 private static final File STORAGE_ROOT new File(/data/secure_store/); Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { req.setCharacterEncoding(UTF-8); resp.setCharacterEncoding(UTF-8); Part filePart req.getPart(file); String relativePath req.getParameter(relativePath); if (filePart null || relativePath null || relativePath.trim().isEmpty()) { resp.getWriter().write(error: 缺少文件或路径参数); return; } // 防止目录穿越将路径规范化后再校验 File rootCanonical STORAGE_ROOT.getCanonicalFile(); File targetFile new File(STORAGE_ROOT, relativePath).getCanonicalFile(); if (!targetFile.getPath().startsWith(rootCanonical.getPath() File.separator)) { resp.getWriter().write(error: 非法路径); return; } // 动态创建父目录 File parentDir targetFile.getParentFile(); if (!parentDir.exists()) { parentDir.mkdirs(); } // 先落临时文件 File tempFile File.createTempFile(upload_, .tmp, STORAGE_ROOT); try { filePart.write(tempFile.getAbsolutePath()); // 加密并写入目标位置 CryptoUtil.encryptFile(tempFile, targetFile); resp.getWriter().write(success: relativePath); } catch (Exception e) { resp.getWriter().write(error: 加密失败 - e.getMessage()); } finally { if (tempFile.exists()) { tempFile.delete(); } } } }代码里必须先说明一个关键操作顺序“临时文件 → 加密 → 写入目标位置”。直接在Part流上做加密写入技术上可行但万一网络中断或加密过程异常目标路径会残留半截文件很难判断是完整的还是损坏的。先落临时文件再一次性加密写过去至少能保证目标位置只有两种状态不存在或者已完整加密。还有一个非常重要的安全校验目录穿越防护。伪造relativePath为../../etc/passwd这类路径如果不做校验攻击者可以直接写到存储根目录之外的任意位置。这里我用getCanonicalFile()拿到绝对规范化路径再校验目标路径是否以存储根路径为前缀从源头堵住这个漏洞。这一步对任何涉及文件上传的系统都适用不只是涉密场景。3.4 加密工具类SM4加密完整性校验的落地方式现在的加密工具类就干一件事把临时文件加密成目标文件。我选用SM4算法的CBC模式按PKCS5Padding补齐。下面给出一个面向普通商用项目的最小实现重点展示算法选型和文件头设计真正涉密项目请换成合规密码设备来做运算。package com.example.upload; import org.bouncycastle.jce.provider.BouncyCastleProvider; import javax.crypto.Cipher; import javax.crypto.CipherInputStream; import javax.crypto.CipherOutputStream; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.io.File; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.IOException; import java.security.SecureRandom; import java.security.Security; public class CryptoUtil { private static final String TRANSFORM SM4/CBC/PKCS5Padding; // 实际项目中密钥应从外部配置或密钥管理系统加载 private static byte[] masterKey KeyManager.loadMasterKey(); static { Security.addProvider(new BouncyCastleProvider()); } public static void encryptFile(File srcFile, File dstFile) throws Exception { try (FileInputStream fis new FileInputStream(srcFile); FileOutputStream fos new FileOutputStream(dstFile)) { // 每个文件单独生成随机IV增强安全性 byte[] iv new byte[16]; new SecureRandom().nextBytes(iv); // 自定义文件头前4字节写IV便于解密时还原 fos.write(iv); SecretKeySpec keySpec new SecretKeySpec(masterKey, SM4); IvParameterSpec ivSpec new IvParameterSpec(iv); Cipher cipher Cipher.getInstance(TRANSFORM, BouncyCastleProvider.PROVIDER_NAME); cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec); try (CipherOutputStream cos new CipherOutputStream(fos, cipher)) { byte[] buffer new byte[8192]; int len; while ((len fis.read(buffer)) ! -1) { cos.write(buffer, 0, len); } } } } }需要注意的一点代码里把IV直接写在密文文件开头这是为了解密时能取出来用。IV不是秘密它的作用只是让相同的明文块产生不同的密文所以可以跟随密文存储不需要单独保护。上面看到的是CBC模式实践里我其实更推荐GCM等带认证的模式因为它除了加密外还能同时校验完整性可以防止密文被篡改。但GCM在部分国密兼容环境里没有标准库支持需要额外引入依赖所以这里给出的是更基础的CBC版本。如果只是“防直接读明文”CBC够用如果还要“防篡改”就一定要在外面加一层SM3摘要或在算法层面换成带认证的模式。解密的过程是加密的逆操作读文件头取IV用主密钥构造同一个Cipher再用CipherInputStream把密文文件解密成明文流。业务侧读取文件时调用对应的decryptFile方法即可。我在后面的踩坑部分会补充“完整文件校验”的几行代码思路。4. 踩坑实录与安全加固清单4.1 中文文件名与路径的编码问题这个坑几乎每个人都会遇到。文件夹名称、文件名称里只要带上中文上传后服务端拿到名字就变乱码或者根本找不到文件。原因不复杂前端FormData的文本参数在现代浏览器里会按UTF-8编码但如果Servlet容器或操作系统层面的默认字符集不是UTF-8就会出现乱码。我的建议是三层都固定第一层前端在FormData.append时不做额外编码直接传原始路径交给浏览器处理第二层服务端req.setCharacterEncoding(UTF-8)必须在读取任何参数之前执行第三层如果File输出的中文文件名在Linux下乱码检查运行环境的file.encoding参数和启动参数里是否显式设置了-Dfile.encodingUTF-8。遇到过最诡异的情况是文件解压和目录创建都正常唯独某个带空格和特殊符号的目录名导致存储路径错乱。排查到最后发现是前端传来路径里包含URL编码后的%20中间某层没有解码。我的建议是如果前端是用fetch发送FormData尽量不要人为去encodeURIComponent路径让浏览器自己处理multipart格式的字段编码反而更省心。4.2 目录穿越与恶意路径必须服务端校验前端所有校验都可以被绕过这句话在安全设计里永远是第一定律。攻击者可以完全不经过你的页面直接构造一个POST请求把relativePath参数赋值为../../../../etc/passwd如果你的Servlet只做了new File(root, relativePath)而不加以约束文件就能被写到系统任意位置后果是灾难性的。防御办法就是我上文代码里的两步第一getCanonicalFile()把路径解析成绝对规范路径这样..和符号链接都会被解析掉第二判断最终路径是否以存储根目录的规范路径为前缀。注意判断前缀时结尾必须带上File.separator否则攻击者利用/data/secure_store_evil这种前缀相似路径也能绕过判断。另外建议服务端对上传文件扩展名做白名单过滤。即使文件已经加密存储也不代表扩展名没有意义。白名单之外的文件类型直接拒绝能大幅减少恶意文件上传面。4.3 并发上传冲突与恶意覆盖多人同时上传相同文件夹结构时两个请求可能在几乎同一时刻执行mkdirs()和写入文件造成互相覆盖或写入内容损坏。我在测试阶段就踩过这个坑两个用户各传一个同名文件夹最后服务器上混了一层文件数量对不上。解决思路有三个层面。第一存储目录按用户或批次隔离比如根目录下先按用户ID或上传批次ID建一层目录再把相对路径接到后面。第二写入目标文件时采用“临时文件校验 rename”机制保证目标文件的写入过程是原子的。第三如果同一路径下文件确实需要共存可以在文件名末尾追加随机序列避免直接硬碰硬。切记不要用File.exists()判断后再决定是否覆盖因为“判断”和“写入”之间不是原子操作。高并发下这个检查完全不可靠。4.4 涉密场景的补充加固建议我知道读这篇文章的人里肯定有部分真是要给涉密项目做的。我在这里多说几句技术之外的话涉密数据的防护从来不是单靠加密算法而是一整套管理和技术体系。物理层面要做到存储介质专盘专用、服务器与终端之间的网络隔离系统层面要关闭多余端口和服务、启用完整审计日志流程层面要确定什么人能传、什么人能看、什么人能导出必要时要做到双人操作。还有一点常被忽略加密系统上线后要定期演练解密恢复。存储设备老化、密钥更新、维护人员变动任何一个环节出问题都可能导致归档的加密文件永远解不开。我曾经见过备份库里存着一堆密文备份脚本跑了几年但没有人验证过解密流程是否还能走通。这个问题在涉密场景下尤其致命建议每三个月做一次抽样解密演练。上面这些代码和方案是我在实际项目里反复调过之后沉淀下来的。文件夹递归上传本身并不神秘webkitdirectory加相对路径就够了真正的复杂度在后端的路径还原、并发控制和文件完整性上加密部分也类似算法选型只是第一步密钥怎么保存、信封怎么写、认证怎么做才是决定体系是否经得起考验的关键。最后分享一个最直接的实操经验前端上传队列里的并发数一定不要拍脑袋定成10也别迷信“越大越快”。我曾经在千兆内网里测过并发3和并发10的最终总耗时几乎相同但并发10时服务端错误率明显上升。这个数字跟文件大小、平均带宽、服务器配置都相关最稳妥的办法是留一个配置项上线前用一批真实业务文件压一遍。再有就是所有路径参数的处理逻辑尽量集中在一个工具类里前端所有调用都走同一个入口一旦出现安全问题改一处就够不必满项目翻代码。

Java Web文件夹递归上传与SM4加密落盘：从JSP到Servlet完整实现

相关推荐

GD32资料下载全指南：从手册分类到固件库选型的工程实践

微博恶意用户识别：工业级机器学习闭环系统实战

机器学习模型评估落地 checklist：从数据切分到统计检验

更多资讯

关键路径法CPM完全指南：从原理到实战，彻底搞懂项目最短工期计算

Oracle 11g INS-30131错误根源与ACL权限修复指南

PB远程连接SQL Server：动态IP配置与排错指南

北理工数据库上机实验包：五阶能力闭环实战指南

三款免费游戏串流APP实测：PC到手机低延迟方案选型指南

Oracle 11g补丁预检失败？p6880880 OPatch替换与避坑指南

今日更新

PHP htmlentities()函数用法讲解

AI Agent工程实战：从七要素到七个决策点的系统设计指南

AI入局芯片设计验证：验证收敛50倍加速的真相与应对

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？