基于Web和二维码的文件传输服务

在工作中难免需要对外提供一些我们抓取的log或者操作视频之类的资料,但由于工作环境日渐规范和严格,公司的网络环境和客户的网络环境是被独立开来的。这样做的好处不必多说,但同时也给我们工作带来的诸多不便。客户的网络无法访问万维网,就无法对外输出资料。但程序员们是不会被困难打到的,于是就有了下面这个对外输出资料的流程:

1.将资料push进手机

2.在手机端下载网盘并登录

3.上传资料

4.在公司的内网登录网盘

5.从网盘下载资料

6.对外输出资料

完美。使用这六个步骤完全解决了对外输出资料的难题,但随着时间的推移我们慢慢会发现,手里的手机经常要刷机,每次一刷机,之前装的网盘工具就没有了。于是我们会重复做第【2】个步骤,这种重复就跟被罚抄写单词一样乏味。

记得曾经听过这么一句话“一切输入都是罪恶的”。意思就是在软件设计和开发当中,尽量避免让用户做输入操作而多让用户做选择操作。重复的输入操作会让用户产生疲惫。而在上述六个步骤中【2】【4】都有登录操作。

灵感来源

支付宝有一个功能就是在当前的浏览器端不支持支付宝的插件的情况下,只需要扫描页面上的二维码便可以使用手机端支付,手机端支付完成后浏览器端的页面会自动刷新并显示付款成功。

那么支付宝的这个功能能给我们带来怎么样的启示呢?是否有这么一种情形:我们在手机浏览器上上传一份资料,接着不需要我们做任何事情,那份资料自动出现在另一个浏览器的页面上,我们只需要下载下来便可。

具体实现

在手机浏览器上传一个文件A后会暂存在了服务器的磁盘上,这时另一个浏览器端要如何得知它所需要A文件已经存在于服务器磁盘上了?如果不需要用户登录,也不需要用户输入什么信息的话怎么去唯一识别和定位这个文件呢?这里我想到了二维码,将二维码作为服务器,手机端,PC端浏览器之间信息交流的“信使”。

“信使”飞行流程如下:

基于Web和二维码的文件传输服务

1.浏览器请求www.contentshell.com

2.服务器会根据当前请求返回一个唯一的ID(信使),然后将这个ID信息存储进二维码并返回给PC端的浏览器

3.PC端浏览器接受到响应后将二维码显示在屏幕上并通过ID信息不间断的查询server是否存在这个文件,如果存在则将该文件的下载链接显示到浏览器上。

4.手机端扫描二维码,通过二维码获得该唯一ID

5.选择指定文件并且将该文件同【4】中获得的ID一并上传给server,server接收到mobile传递上来的文件后会根据ID来给文件命名

6.当【5】完成后,PC端浏览器就能成功从server查询到ID对应的文件并将该文件的下载链接显示在网页上。

技术堆栈

1.bootstrap框架搭建前台页面

2.node js编写后台服务器代码

最终设计效果

基于Web和二维码的文件传输服务

使用contentshell上传文件步骤:

1.将资料push进手机

2.扫描二维码

3.上传资料

4.下载资料

5.对外输出资料

可扩展内容

1.使用数据库进行文件数据保存。

2.支持文件持久保存和文件一次性使用即毁。

3.支持文件分享功能。

4.支持大文件断点上传。

上一篇:Centos7.2 yum配置


下一篇:基于TCP协议的大文件传输(粘包问题处理)