.NET程序员的20G文件上传历险记
大家好,我是甘肃的一名苦逼.NET程序员,最近接了个外包项目,客户的需求简直是要我老命啊!来给大家扒一扒这个"价值连城"的项目需求:
项目需求:地狱级难度
- 大文件上传:20G!不是20M也不是2G,是20G!想想我的小水管服务器就瑟瑟发抖
- 兼容性要求:从IE8到现代浏览器全都要支持 - “总不能把业务机器扔掉吧”,客户原话
- 文件夹结构保留:用户上传的文件夹可能有1000个分类文件,还得保持层级
- 断点续传:关了浏览器、重启电脑都不能丢进度 - 这得用上黑魔法吧?
- 加密要求:SM4、AES全都要,传输存储都要加密
- 预算:100元以内!还要求7×24小时技术支持、源代码、打包部署一条龙…
技术选型:在夹缝中求生存
既然客户点名要WebUploader或原生JS,预算又这么"慷慨",我只能选择…
// 前端伪代码 - 用生命在兼容IE8varie8Flag=/*@cc_on!@*/false;// 判断IE8的黑魔法if(ie8Flag){alert("亲,您还在用IE8啊?给您磕头了!");// 这里要写一堆ActiveX和VBScript的兼容代码}else{// 现代浏览器可以用File API}文件夹上传的坑
网上找的代码大多只支持文件上传,文件夹上传保留层级结构?自己造轮子吧!
// 后端C#处理文件夹结构的伪代码publicvoidHandleFolderUpload(HttpPostedFilefile,stringrelativePath){// relativePath是前端传来的文件夹相对路径stringserverPath=Path.Combine("E:\\Uploads",relativePath);Directory.CreateDirectory(Path.GetDirectoryName(serverPath));file.SaveAs(serverPath);// 预算只够写伪代码了,真实项目这里还要处理各种异常}断点续传实现思路
- 前端分片计算文件哈希作为唯一标识
- 后端记录已上传的分片信息
- 用户中断后重新上传时,先查询已上传分片
// 前端断点续传逻辑functionresumeUpload(file){calculateFileHash(file).then(hash=>{$.get("/api/upload/progress?hash="+hash,function(data){// data返回已上传的分片列表uploadRemainingChunks(file,data.uploadedChunks);});});}加密传输方案
// C# SM4加密示例(简化版)publicstringSM4Encrypt(stringinput,stringkey){// 这里应该是复杂的SM4算法实现// 但预算只够写个伪代码...return"加密后的"+input+"(假装加密了)";}现实与理想的差距
客户:“这个功能很简单吧,几天能做完?”
我:(内心OS)几天?给我几个月还差不多…
表面:“这个…我需要评估一下技术可行性…”
给同行们的忠告
- 接单前一定要评估需求合理性
- IE8支持真的是个大坑,能推就推
- 文件夹上传保留层级不是那么简单
- 100元预算做这种需求…不如去要饭
最后说点掏心窝子的话:
各位同行啊,咱们程序员也要硬气一点。这种明显不合理的需求,要么加钱,要么拒绝。别为了接单把自己逼到绝路。
至于那个QQ群广告…咳咳,大家自己判断吧。反正我是不信什么"2万项目提成1万"的好事。真有这种好事,他们为什么不自己接单呢?
最后的最后:如果你真的非要做这个项目,我建议:
- 先和客户重新谈需求和预算
- 实在不行就用现成的商业解决方案(虽然超预算)
- 真要自己实现,做好加班到秃顶的准备
祝你好运吧,甘肃的程序员兄弟!
设置框架
安装.NET Framework 4.7.2
https://dotnet.microsoft.com/en-us/download/dotnet-framework/net472
框架选择4.7.2
添加3rd引用
编译项目
NOSQL
NOSQL无需任何配置可直接访问页面进行测试
SQL
使用IIS
大文件上传测试推荐使用IIS以获取更高性能。
使用IIS Express
小文件上传测试可以使用IIS Express
创建数据库
配置数据库连接信息
检查数据库配置
访问页面进行测试
相关参考:
文件保存位置,
效果预览
文件上传
文件刷新续传
支持离线保存文件进度,在关闭浏览器,刷新浏览器后进行不丢失,仍然能够继续上传
文件夹上传
支持上传文件夹并保留层级结构,同样支持进度信息离线保存,刷新页面,关闭页面,重启系统不丢失上传进度。
下载完整示例
下载完整示例