上传文件的方法有哪些?

时间:2015-07-06 06:00:10

标签: file-upload upload

我已经阅读了几种将文件上传到服务器的方法。

还有其他选择吗?我正在研究的项目需要这样的功能。我上传的文件可以达到几千吉比特。我想对不同方法进行全面评估。

ADD 1

  

感谢您的回复。这些天我忙于其他一些事情,直到我看到SO通知才能回到这个问题。   我很想为奖金即将到期而添加细节而道歉。

在我的方案中,有1 web serverfile server和许多agents。整个画面看起来像这样:

enter image description here

  • 用户通过浏览器与Web服务器进行日常操作。
  • 用户通过浏览器将文件上传到文件服务器。 (我希望一切都在浏览器中发生,让客户生活更轻松。)
  • 代理是与Web服务器和文件服务器通信的桌面应用程序。
  • 代理从Web服务器获取例行信息。
  • 代理从文件中提取文件并将文件推送到文件服务器。并通知Web服务器所有内容。
  • Web服务器从文件服务器提取文件,以便在浏览器中将其呈现给客户。

以及一些编码背景:

  • 爪哇
  • 弹簧
  • 的Netty

5 个答案:

答案 0 :(得分:10)

将文件上传到服务器的其他方法(摘要):

最后,以下链接显示了经典 ASP 的HTTP上传实现方法: https://support.microsoft.com/en-us/kb/299692

这是一些技术或方法的摘要,但有很多解决方案。

答案 1 :(得分:5)

您没有明确指定要定位的平台/语言。 我担心它不是一个Web应用程序,因为您提到的两个选项最广泛应用于Web应用程序。

好吧,上传与您提到的文件一样大的文件需要非常仔细地设计。 在上传过程中,您的连接可能会中断,某些数据包可能会损坏,甚至上传终端系统也可能会出现故障。

如果是我,那么安全可靠的文件上传最好的选择是将文件分解为更小的块并应用多线程程序来处理这些块的上传。在接收端,类似的功能重新启动 - 需要组装。这种方法的优点是:

  1. 能够跟踪进度。
  2. 可以实现恢复功能。
  3. 通过校验和进行验证可确保免于腐败。
  4. 然而,为了获得精确的解决方案,请扩展您的描述。如果您必须提供赏金,说明中肯定缺少某些内容!!!

答案 2 :(得分:4)

我同意@Ayelis评论(主要帖子)这个问题太抽象了。不过我想加两分钱。

实际上,您有两种选择:

  1. 您希望将上传过程与网站集成,用户不仅可以向您发送文件,还可以创建订单/案例/记录(即此文件应与某些数据库条目和用户相关联)。 / LI>
  2. 即使没有网站,您也需要让用户能够将文件传输到您的公司。
  3. 在第一种情况下,唯一的选择是使用基于HTTP的解决方案。在第二种情况下,您可以尝试使用FTP,云存储系统(Dropbox,...)等。当然,您也可以在第一种情况下使用FTP,但只有在数量有限的情况下它才可行。用户(例如只有员工)。

    所以我假设您正在研究将上传集成到网站中的第一个场景。

    您提到的重要限制是需要上传多个GB文件。如果您只是在页面中添加<input type="file">元素,则可能会遇到许多问题(客户端内存,服务器端内存,安全性,可靠性等 - 这取决于技术的选择)。要解决这些问题,最好的方法是创建一个JavaScript上传器,将您的文件拆分为较小的部分(例如5MB)并将其作为单个文件上传。在服务器上,您可以将所有这些文件放在一起并将其组装回完整文件。结果:

    • 无需准备和接收非常大的POST请求(可能是内存密集型) - 从技术角度来看,它将相当于上传数百个常规小文件。
    • 让它变得可靠并不是一个问题(如果上传的2GB文件中断为90%,则用户不必从头开始重新上传)。
    • 无需关闭服务器上的POST请求验证规则

    它需要在客户端和服务器端编写大量代码。但是,如果您的团队中有一个完整的堆栈开发人员,那么这不是问题。此外,您可以搜索此问题的第三方解决方案。

    如果您不想使用HTTP(例如,第二种情况离您更近),并且认为Dropbox / Google Drive /等是一种诱人的方法,请注意,对于非常大的文件,它可能是糟糕的解决方案(由于带宽和成本)。我建议看看像Seafile或者ownCloud这样的解决方案,至少它们是免费的。

    希望这有帮助。

答案 3 :(得分:4)

[回复原因我发现这在哲学层面上很有趣!]

这是一个公平的问题,我认为给出了几个千兆位&#34;。我不认为您尝试实现这种语言的重要性,但是,体系结构和系统要求非常重要(与@Ayelis一致)。我会将解决方案分为以下几类:

  1. 传统的客户端 - 服务器上传 - 我认为这不会起作用,因为用户必须离开他的标签/浏览器,直到上传完成

  2. 中间阶段/人:基于中间阶段解耦上传和存储/下载的解决方案(即:Dropbox,Google驱动器等......)。在这种情况下,您的网络应用程序接受一个URL,以便从&#34;获取文件。问题是:你的服务器可以&#34;拉&#34;从一个位置?您的客户是否需要在某处公开/可访问地上传文件?您如何显示转移的进度?

  3. 基于Intranet的同步/挂载文件系统的解决方案(rsync,内部git repo,共享cifs / nfs挂载驱动器)

  4. 更多关于P2P方面...本机客户端(除了网络之外的任何东西),它能够上传,暂停和恢复到给定的远程位置。在这个类别中,我还放置了众所周知的P2P / torrent应用程序。一种可能的情况是:客户端上传(合法)洪流,将磁铁链接注册到正在排队下载的网络服务器(有点像ktorrent web界面用于工作......不确定它是否仍然存在)

  5. 再次像@Ayelis所说,更多信息将帮助您获得更好的答案......我发现这是一个具有挑战性的问题!

答案 4 :(得分:4)

如果你需要一个严格的基于浏览器的大型文件解决方案,你将不得不依赖JavaScript(我可以说Java Applets或 - gasp - Flash,但我不推荐它,它是实际上是伪装的桌面应用程序 - 但它们是一种选择。)

话虽如此,对于大型文件,使用File API的选项非常窄。那里有很好的解决方案,但我喜欢Blueimp的jQuery文件上传。

https://github.com/blueimp/jQuery-File-Upload

您应该查看他们的Chunked File Upload以获取可恢复的上传内容:

https://github.com/blueimp/jQuery-File-Upload/wiki/Chunked-file-uploads

这应该允许您通过片状连接处理非常大的文件。

- 如果您没有浏览器限制,那么答案中会讨论很多选项。

<强>更新 您有一个服务于浏览器和桌面应用的网络服务器。为了避免为每个服务器编写服务器代码,请为浏览器方案编写,这是最严格的(沙盒,有限访问本地设备)。桌面应用程序应该很容易适应浏览器强加的任何场景。

如果您能够为浏览器编写解决方案,则代理应用程序应该是 breeze

<强> UPDATE2

您的图表在浏览器和文件服务器之间有一行。这不太正确。浏览器将仅连接到Web服务器,这将存储在您拥有的任何后端(自己的服务器,数据库,其他文件服务器等)。

代理与文件服务器的连接可能可能有效,但是您可能会通过网络协议工作(例如编写一个可以通过常规共享网络驱动器操作文件的桌面应用程序)

但是,如果您希望您的代理与浏览器一样具有移动性,则应将其视为用于文件上载和服务器通信的浏览器(因此代理和文件服务器之间没有线路)