CN111327694B - 文件上传方法、装置、存储介质及电子设备 - Google Patents

Abstract

本公开关于一种文件上传方法、装置、存储介质及电子设备，属于互联网技术领域，方法包括：接收终端通过浏览器发送的文件上传请求；若文件上传请求中携带分片总数且分片总数大于第一阈值，则获取文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，分片总数用于指示目标文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值；根据用户标识和当前上传的分片数据的分片标识，缓存当前上传的分片数据；循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与分片总数一致。本公开避免了在上传大文件时可能出现的浏览器被卡死现象，提高了文件上传的成功率，效果较佳。

Description

文件上传方法、装置、存储介质及电子设备

技术领域

本公开涉及互联网技术领域，尤其涉及一种文件上传方法、装置、存储介质及电子设备。

背景技术

用户对信息需求的爆炸式增长，为浏览器的诞生和兴起提供了强大的动力，即浏览器是互联网时代的产物，它联合作为服务端的网络服务器为用户提供服务，比如，用户可以通过浏览器向网络服务器上传文件。

示例性地，nodejs作为可以在服务端运行的脚本语言，目前被广泛地应用到网页开发中。即，网络服务器可以是以nodejs作为服务端开发语言的web(网络)平台。针对以nodejs作为服务端开发语言的web平台，终端在通过浏览器上传文件时，通常是直接上传整个文件。

然而，在通过浏览器上传大文件时，很可能会出现浏览器被卡死的现象，进而导致网络服务器无法接收数据，文件上传失败，因此该种文件上传方式的效果较差。

发明内容

本公开提供一种文件上传方法、装置、存储介质及电子设备，以至少解决相关技术中存在的在通过浏览器上传大文件时可能出现的浏览器被卡死现象，提高了文件上传的成功率，该种文件上传方式的效果较佳。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种文件上传方法，包括：

接收终端通过浏览器发送的文件上传请求；

若所述文件上传请求中携带分片总数且所述分片总数大于第一阈值，则获取所述文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，所述分片总数用于指示目标文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值；

根据所述用户标识和当前上传的分片数据的分片标识，缓存当前上传的分片数据；

循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与所述分片总数一致。

在一种可能的实现方式中，所述文件上传请求中还携带所述目标文件的文件标识；在已上传的分片数据的数量达到所述分片总数之后，还包括：

以所述目标文件的文件标识作为文件名称进行新文件创建；

循环读取已缓存的分片数据，并将读取到的分片数据写入到创建好的新文件中，直至读取完毕所述已缓存的分片数据；

若至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中，则向所述终端返回第一通知消息；

若每个分片数据均被成功读取且均被成功写入到创建好的新文件中，则向所述终端返回第二通知消息。

在一种可能的实现方式中，在接收终端通过浏览器发送的文件上传请求之后，还包括：创建缓存文件数组；

所述根据所述用户标识和当前上传的分片数据的分片标识，缓存当前上传的分片数据，包括：

根据所述用户标识和当前上传的分片数据的分片标识，将当前上传的分片数据写入到所述缓存文件数组中。

在一种可能的实现方式中，各个分片数据以流数据的形式缓存在所述缓存文件数组中；

所述循环读取已缓存的分片数据，并将读取到的分片数据写入到创建好的新文件中，直至读取完毕所述已缓存的分片数据，包括：

循环读取所述缓存文件数组中的流数据，并将读取到的流数据写入到创建好的新文件中，直至读取完毕所述缓存文件数组中的流数据。

根据本公开实施例的第二方面，提供一种文件上传方法，包括：

获取待上传的目标文件，若所述目标文件的大小大于第二阈值，则对所述目标文件进行分割处理，得到至少两个分片数据；

通过浏览器向网络服务器发送文件上传请求，所述文件上传请求中携带分片总数、用户标识、当前上传的分片数据以及所述分片数据的分片标识，所述分片总数用于指示所述目标文件被分割处理为分片数据的数量，每个分片数据的大小均不大于所述第二阈值；

其中，所述文件上传请求用于指示所述网络服务器在确定所述文件上传请求中携带所述分片总数且所述分片总数大于第一阈值后，获取所述用户标识和当前上传的分片数据的分片标识，并根据所述用户标识和所述分片标识缓存当前上传的分片数据；

循环执行上述向所述网络服务器发送文件上传请求的步骤，直至遍历每个分片数据。

在一种可能的实现方式中，所述文件上传请求中还携带所述目标文件的文件标识；

其中，所述文件标识用于指示所述网络服务器以所述文件标识作为文件名称进行新文件创建，并将循环接收到的分片数据写入到创建好的新文件中。

在一种可能的实现方式中，在发送所述文件上传请求之后，所述方法还包括：

接收所述网络服务器返回的第一通知消息，所述第一通知消息由所述网络服务器在确定至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中后，向所述终端发送；或，

接收所述网络服务器返回的第二通知消息，所述第二通知消息由所述网络服务器在确定每个分片数据均被成功读取且均被成功写入到创建好的新文件中后，向所述终端发送。

根据本公开实施例的第三方面，提供一种文件上传装置，包括：

接收模块，被配置为接收终端通过浏览器发送的文件上传请求；

获取模块，被配置为若所述文件上传请求中携带分片总数且所述分片总数大于第一阈值，则获取所述文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，所述分片总数用于指示目标文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值；

缓存模块，被配置为根据所述用户标识和当前上传的分片数据的分片标识，缓存当前上传的分片数据；

所述接收模块和所述缓存模块，还被配置为循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与所述分片总数一致。

在一种可能的实现方式中，所述文件上传请求中还携带所述目标文件的文件标识；所述装置还包括：

第一创建模块，被配置为以所述目标文件的文件标识作为文件名称进行新文件创建；

读取模块，被配置为循环读取已缓存的分片数据；

写入模块，被配置为将读取到的分片数据写入到创建好的新文件中，直至读取完毕所述已缓存的分片数据；

发送模块，被配置为若至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中，则向所述终端返回第一通知消息；若每个分片数据均被成功读取且均被成功写入到创建好的新文件中，则向所述终端返回第二通知消息。

在一种可能的实现方式中，所述装置还包括：

第二创建模块，被配置为创建缓存文件数组；

所述缓存模块，还被配置为根据所述用户标识和当前上传的分片数据的分片标识，将当前上传的分片数据写入到所述缓存文件数组中。

在一种可能的实现方式中，各个分片数据以流数据的形式缓存在所述缓存文件数组中；

所述读取模块，还被配置为循环读取所述缓存文件数组中的流数据；

所述写入模块，还被配置为将读取到的流数据写入到创建好的新文件中，直至读取完毕所述缓存文件数组中的流数据。

根据本公开实施例的第四方面，提供一种文件上传装置，包括：

获取模块，被配置为获取待上传的目标文件；

分割模块，被配置为若所述目标文件的大小大于第二阈值，则对所述目标文件进行分割处理，得到至少两个分片数据；

发送模块，被配置为通过浏览器向网络服务器发送文件上传请求，所述文件上传请求中携带分片总数、用户标识、当前上传的分片数据以及所述分片数据的分片标识，所述分片总数用于指示所述目标文件被分割处理为分片数据的数量，每个分片数据的大小均不大于所述第二阈值；

其中，所述文件上传请求用于指示所述网络服务器在确定所述文件上传请求中携带所述分片总数且所述分片总数大于第一阈值后，获取所述用户标识和当前上传的分片数据的分片标识，并根据所述用户标识和所述分片标识缓存当前上传的分片数据；

所述发送模块，还被配置为循环执行上述向所述网络服务器发送文件上传请求的步骤，直至遍历每个分片数据。

在一种可能的实现方式中，所述文件上传请求中还携带所述目标文件的文件标识；

其中，所述文件标识用于指示所述网络服务器以所述文件标识作为文件名称进行新文件创建，并将循环接收到的分片数据写入到创建好的新文件中。

在一种可能的实现方式中，所述装置还包括：

接收模块，被配置为接收所述网络服务器返回的第一通知消息，所述第一通知消息由所述网络服务器在确定至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中后，向所述终端发送；或，接收所述网络服务器返回的第二通知消息，所述第二通知消息由所述网络服务器在确定每个分片数据均被成功读取且均被成功写入到创建好的新文件中后，向所述终端发送。

根据本公开实施例的第五方面，提供一种电子设备，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如第一方面所述的文件上传方法；或，如第二方面所述的文件上传方法。

根据本公开实施例的第六方面，提供一种计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如第一方面所述的文件上传方法；或，如第二方面所述的文件上传方法。

根据本公开实施例的第七方面，提供一种计算机程序产品，所述计算机程序产品中的指令由电子设备的处理器执行时，使得电子设备能够执行如第一方面所述的文件上传方法；或，如第二方面所述的文件上传方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

在上传大文件时，终端会将大文件分割处理为至少两个分片数据，其中，分片总数用于指示大文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值；之后，终端会循环地通过浏览器向服务端发送文件上传请求。对于任意一个文件上传请求，若该文件上传请求中携带分片总数且分片总数大于第一阈值，则服务端会获取该文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，并根据用户标识和分片标识，缓存当前上传的分片数据；服务端循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与分片总数一致。

基于以上描述可知，终端在通过浏览器上传文件时，会先判断文件大小，并在待上传的文件为大文件时，会对大文件进行分割处理形成多个分片数据，循环地向服务端上传分片数据，而服务端负责缓存分片数据，直至最后一个分片数据，该种文件上传方式避免了在通过浏览器上传大文件时可能出现的浏览器被卡死现象，提高了文件上传的成功率，因此该种文件上传方式的效果较佳。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种文件上传方法涉及的实施环境的示意图。

图2是根据一示例性实施例示出的一种文件上传方法的流程图。

图3是根据一示例性实施例示出的一种文件上传方法的流程图。

图4是根据一示例性实施例示出的一种文件上传方法的流程图。

图5是根据一示例性实施例示出的一种浏览器端的执行方法的流程图。

图6是根据一示例性实施例示出的一种服务端的执行方法的流程图。

图7是根据一示例性实施例示出的一种文件上传装置的框图。

图8是根据一示例性实施例示出的一种文件上传装置的框图。

图9是根据一示例性实施例示出的一种电子设备的框图。

图10是根据一示例性实施例示出的另一种电子设备的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

本公开所涉及的用户信息可以为经用户授权或者经过各方充分授权的信息。

在对本公开实施例进行详细地解释说明之前，先对本公开实施例涉及的一些名词术语或缩略语进行介绍。

浏览器：是指用来显示在万维网或局域网等内的文字、图像及其他信息的应用软件，浏览器还可以让用户与这些信息进行交互操作。即，浏览器是用户通过终端上网时经常使用到的应用软件之一。

nodejs：是一个基于ChromeV8引擎的JavaScript(脚本)运行环境。其中，node是一个让JavaScript运行在服务端的开发平台。即，nodejs作为可在服务端运行的脚本语言，被广泛地应用到web网页开发中。

大文件：在本公开实施例中，大文件指代大小大于一定阈值的文件。示例性地，该阈值的取值可以为180M(兆)，本公开实施例对此不进行具体限定。

分片数据：在本公开实施例中，大文件会被分割处理为至少两个分片数据，即分片数据来源于大文件，属于大文件的子集。

下面对本公开实施例提供的一种音频处理方法涉及的实施环境进行介绍。

参见图1，该实施环境包括：网络服务器110和终端120。在本公开实施例中，网络服务器110也可称之为web平台、服务端或web网页平台。

其中，终端120上安装有浏览器，终端120的类型包括但不限于：移动式终端和固定式终端。作为一个示例，移动式终端包括但不限于：智能手机、平板电脑、笔记本电脑、电子阅读器、MP3播放器(Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器等；固定式终端包括但不限于台式电脑，本公开实施例对此不进行具体限定。

示例性地，图1仅是以终端120为智能手机进行举例说明。其中，网络服务器110既可以是一个独立的服务器，也可以是由多个服务器组成的服务器集群，本公开实施例对此同样不进行具体限定。示例性地，nodejs可以作为在网络服务器110端运行的脚本语言，被广泛地应用到web网页开发中。即，本公开实施例提供的方法可以应用于以nodejs作为服务端开发语言的web项目中。

综上，基于以上实施环境，本公开实施例提出了一种文件上传方法，应用在基nodejs作为服务端开发语言的场景下，能够解决进行大文件上传时出现的浏览器卡死现象。

下面通过以下实施方式对本公开实施例提供的音频处理方法进行详细地解释说明。

图2是根据一示例性实施例示出的一种文件上传方法的流程图，如图2所示，该方法用于网络服务器中，包括以下步骤。

在步骤201中，接收终端通过浏览器发送的文件上传请求。

在步骤202中，若该文件上传请求中携带分片总数且分片总数大于第一阈值，则获取该文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，其中，分片总数用于指示目标文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值。

在步骤203中，根据用户标识和当前上传的分片数据的分片标识，缓存当前上传的分片数据。

在步骤204中，循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与分片总数一致。

本公开实施例提供的方法，在上传大文件时，终端会将大文件分割处理为至少两个分片数据，其中，分片总数用于指示大文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值；之后，终端会循环地通过浏览器向服务端发送文件上传请求。对于任意一个文件上传请求，若该文件上传请求中携带分片总数且分片总数大于第一阈值，则服务端会获取该文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，并根据用户标识和分片标识，缓存当前上传的分片数据；服务端循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与分片总数一致。

基于以上描述可知，终端在通过浏览器上传文件时，会先判断文件大小，并在待上传的文件为大文件时，会对大文件进行分割处理形成多个分片数据，循环地向服务端上传分片数据，而服务端负责缓存分片数据，直至最后一个分片数据，该种文件上传方式避免了在通过浏览器上传大文件时可能出现的浏览器被卡死现象，提高了文件上传的成功率，因此该种文件上传方式的效果较佳。

在一种可能的实现方式中，所述文件上传请求中还携带所述目标文件的文件标识；在已上传的分片数据的数量达到所述分片总数之后，还包括：

以所述目标文件的文件标识作为文件名称进行新文件创建；

循环读取已缓存的分片数据，并将读取到的分片数据写入到创建好的新文件中，直至读取完毕所述已缓存的分片数据；

若至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中，则向所述终端返回第一通知消息；

若每个分片数据均被成功读取且均被成功写入到创建好的新文件中，则向所述终端返回第二通知消息。

在一种可能的实现方式中，在接收终端通过浏览器发送的文件上传请求之后，还包括：创建缓存文件数组；

所述根据所述用户标识和当前上传的分片数据的分片标识，缓存当前上传的分片数据，包括：

根据所述用户标识和当前上传的分片数据的分片标识，将当前上传的分片数据写入到所述缓存文件数组中。

在一种可能的实现方式中，各个分片数据以流数据的形式缓存在所述缓存文件数组中；

所述循环读取已缓存的分片数据，并将读取到的分片数据写入到创建好的新文件中，直至读取完毕所述已缓存的分片数据，包括：

循环读取所述缓存文件数组中的流数据，并将读取到的流数据写入到创建好的新文件中，直至读取完毕所述缓存文件数组中的流数据。

上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。

图3是根据一示例性实施例示出的一种文件上传方法的流程图，如图2所示，该方法用于终端中，包括以下步骤。

在步骤301中，获取待上传的目标文件，若目标文件的大小大于第二阈值，则对目标文件进行分割处理，得到至少两个分片数据。

在步骤302中，通过浏览器向网络服务器发送文件上传请求，该文件上传请求中携带分片总数、用户标识、当前上传的分片数据以及分片数据的分片标识，分片总数用于指示目标文件被分割处理为分片数据的数量，每个分片数据的大小均不大于第二阈值。

其中，该文件上传请求用于指示网络服务器在确定文件上传请求中携带分片总数且分片总数大于第一阈值后，获取用户标识和当前上传的分片数据的分片标识，并根据用户标识和分片标识缓存当前上传的分片数据；

在步骤303中，循环执行上述向网络服务器发送文件上传请求的步骤，直至遍历每个分片数据。

本公开实施例提供的方法，在上传大文件时，终端会将大文件分割处理为至少两个分片数据，其中，分片总数用于指示大文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值；之后，终端会循环地通过浏览器向服务端发送文件上传请求。对于任意一个文件上传请求，若该文件上传请求中携带分片总数且分片总数大于第一阈值，则服务端会获取该文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，并根据用户标识和分片标识，缓存当前上传的分片数据；服务端循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与分片总数一致。

基于以上描述可知，终端在通过浏览器上传文件时，会先判断文件大小，并在待上传的文件为大文件时，会对大文件进行分割处理形成多个分片数据，循环地向服务端上传分片数据，而服务端负责缓存分片数据，直至最后一个分片数据，该种文件上传方式避免了在通过浏览器上传大文件时可能出现的浏览器被卡死现象，提高了文件上传的成功率，因此该种文件上传方式的效果较佳。

在一种可能的实现方式中，所述文件上传请求中还携带所述目标文件的文件标识；

其中，所述文件标识用于指示所述网络服务器以所述文件标识作为文件名称进行新文件创建，并将循环接收到的分片数据写入到创建好的新文件中。

在一种可能的实现方式中，在发送所述文件上传请求之后，所述方法还包括：

接收所述网络服务器返回的第一通知消息，所述第一通知消息由所述网络服务器在确定至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中后，向所述终端发送；或，

接收所述网络服务器返回的第二通知消息，所述第二通知消息由所述网络服务器在确定每个分片数据均被成功读取且均被成功写入到创建好的新文件中后，向所述终端发送。

上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。

图4是根据一示例性实施例示出的一种文件上传方法的流程图，交互主体为终端和网络服务器。示例性地，交互主体可以为终端上安装的浏览器和网络服务器，其中，网络服务器也可称之为服务端，浏览器也可称之为浏览器端。参见图4，以交互主体为浏览器端和服务端为例，则该文件上传方法包括以下步骤。

在步骤401中，浏览器端获取待上传的目标文件。

在本公开实施例中，目标文件指代浏览器端待上传至服务端的文件。

其中，目标文件可以是用户在本地存储的文件中主动选取的文件。另外，目标文件的类型可以是音频文件、文本文件、图像文件或视频文件等，或者，还可以是前述几种文件类型的结合，本公开实施例对此不进行具体限定。

在步骤402中，若目标文件的大小大于第二阈值，则浏览器端对目标文件进行分割处理，得到至少两个分片数据。

为了避免因上传大文件而导致浏览器被卡死的现象出现，本公开实施例会对大文件进行分割处理，处理为至少两个分数数据。

在一种可能的实现方式中，大文件指代大小大于一定阈值的文件。其中，该阈值在本文中也被称之为第二阈值。示例性地，第二阈值的取值可以为180M(兆)，即在对大文件进行分割时，以180M大小为分割单位，使得每个分片数据的大小均不大于180M。

参见图5，以第二阈值的取值为180M为例，则浏览器端在获取到目标文件后，首先会判断目标文件的大小是否大于180M；如果大于180M，还需将其分割处理为大小不超过180M的至少两个分片数据，详细过程为：计算目标文件以180M为分割单位的分片总数，记录为参数count；循环count次对目标文件进行分割处理。其中，分片总数即用于指示目标文件被分割处理为分片数据的数量。

在步骤403中，浏览器端循环地向服务端发送文件上传请求，直至遍历每个分片数据。

其中，在得到至少两个分片数据后，浏览器端会依次上传得到的分片数据，并同时附带分片总数、用户标识、目标文件的文件标识以及当前上传的分片数据的分片标识。即，浏览器端会在文件上传请求中携带分片总数、用户标识、当前上传的分片数据、目标文件的文件标识以及当前上传的分片数据的分片标识。

作为一个示例，用户标识可以为用户登录账号，目标文件的文件标识可以为文件名称，分片数据的分片标识(session id)可以用于指示当前上传的是第几个分片数据。

举例来说，假设目标文件被分割处理为5个分片数据，则这5个分片数据的sessionid可依次为1_5、2_5、3_5、4_5和5_5。

另外，如果目标文件的大小小于第二阈值，则浏览器端可以直接上传整个文件。

在步骤404中，服务端循环地接收浏览器端发送的文件上传请求；对于任意一个文件上传请求，若该文件上传请求中携带分片总数且分片总数大于第一阈值，则创建缓存文件数组。

示例性地，考虑到大文件的上传时间较长，如果浏览器端和服务端基于HTTP(HyperText Transfer Protocol,超文本传输协议)进行通信，可能会出现超时问题。为了避免这一问题，在本公开实施例中，浏览器端和服务端基于websocket通信机制进行数据传输。即，参见图6，服务端会开启websocket服务。

其中，websocket是一种在单个TCP(Transmission Control Protocol，传输控制协议)连接上进行全双工通信的协议。websocket使得client(客户端)和server(服务端)之间的数据交换变得更加简单，允许server主动向client推送数据。

示例性地，浏览器端和服务端仅需完成一次握手(handshaking)，两者之间便直接可以创建持久性的连接，并进行双向数据传输。

作为一个示例，为了建立一个websocket连接，浏览器端首先要向服务端发起一个HTTP请求，这个请求和通常的HTTP请求不同，包含了一些附加头信息，其中，附加头信息"upgrade:websocket"表明这是一个申请协议升级的HTTP请求，服务端解析这些附加的头信息，然后产生应答信息返回给浏览器端，浏览器端和服务端的websocket连接便建立起来。双方可以通过这个连接通道自由地传递数据，并且这个连接会持续存在直到浏览器端或者服务端中的某一方主动关闭连接。

示例性地，浏览器端可以通过send()方法向服务端发送数据，并通过onmessage事件接收服务端返回的通知消息，本公开实施例对此不进行具体限定。

如图6所示，服务端会循环地接收到浏览器端发送的文件上传请求，对于任意一个文件上传请求，服务端会首先判断该文件上传请求中携带的参数是否包括count字段；如果不包括count字段，即表示该次上传的文件为非分片上传，直接接收该文件，并通过websocket方式向浏览器端返回上传成功的通知消息；如果包括count字段且参数count的取值大于第一阈值，则表示该文件上传请求用于上传分片数据，服务端会创建一个缓存文件数组。其中，第一阈值的取值通常为1。

在步骤405中，服务端根据该文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，将当前上传的分片数据写入到缓存文件数组中。

在本公开实施例中，服务端在创建完毕缓存文件数组后，会以该文件上传请求中携带的用户标识(用户id)和当前上传的分片数据的分片标识(session id)作为唯一标志，将当前上传的分片数据写入到缓存文件数组中。而通过使用用户id和session id作为唯一标志进行分片数据缓存，可以有效避免因同时存在多人进行文件上传时产生错乱，也可以避免一人同时开启多个浏览器页面进行文件上传时造成的错乱。针对后一种情况，比如每个分片数据的session id中可以携带相应文件的文件标识，本公开实施例对此不进行具体限定。

在步骤406中，服务端循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已缓存的分片数据的数量与分片总数一致。

在本公开实施例中，服务端会循环地将接收到的分片数据写入到创建好的缓存文件数组中，直至目标文件的最后一个分片数据。即，如果当前上传的分片数据的分片标识与分片总数相等，则说明浏览器端已经上传完毕目标文件的最后一个分片数据，服务端还需将之前上传的并缓存在缓存数组文件中的分片数据进行合并，详见下述步骤406。

在步骤407中，服务端以目标文件的文件标识作为文件名称进行新文件创建；循环读取缓存文件数组中的分片数据，并将读取到的分片数据写入到创建好的新文件中，直至读取完毕缓存文件数组中的分片数据。

在本公开实施例中，服务端会以目标文件的文件上传请求中携带的文件标识来创建一个新文件，以供写入缓存在缓存文件数组中的目标文件的分片数据。

在一种可能的实现方式中，目标文件的各个分片数据可以以流数据的形式缓存在缓存文件数组中；相应地，循环读取已缓存的分片数据，并将读取到的分片数据写入到创建好的新文件中，直至读取完毕已缓存的分片数据，包括但不限于采取下述方式：

循环读取缓存文件数组中的流数据，并将读取到的流数据写入到创建好的新文件中，直至读取完毕缓存文件数组中的流数据。

示例性地，服务端可以异步循环处理缓存文件数组filePathCache，并依次读取缓存数组文件中存储的流数据，比如可以使用fs.createReadStream方式进行流数据读取，在缓存文件数组中的流数据读取结束时，以流数据的形式写入到以目标文件的文件标识命名的已创建好的新文件中。

需要说明的是，在上传大文件时，本公开实施例还包括服务端对浏览器端的用户进行通知提醒的步骤，以提醒用户大文件是否上传成功，参见下述步骤408和步骤409。

在步骤408中，若至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中，则服务端向终端返回第一通知消息。

针对该步骤，如果服务端对任意一个缓存文件数组中的流数据读取或者写入新文件失败，则服务端确定目标文件上传失败。示例性地，服务端可以websocket形式向浏览器端发送第一通知消息，其中，第一通知消息用于指示目标文件上传失败。

在步骤409中，若每个分片数据均被成功读取且均被成功写入到创建好的新文件中，则服务端向终端返回第二通知消息。

针对该步骤，如果服务端对所有缓存文件数组中的流数据均读取和写入新文件成功，则服务端确定目标文件上传成功。示例性地，服务端可以websocket形式向浏览器端发送第二通知消息，其中，第二通知消息用于指示目标文件上传成功。

本公开实施例提供的方法至少具有以下有益效果：

在上传大文件时，终端会将大文件分割处理为至少两个分片数据，其中，分片总数用于指示大文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值；之后，终端会循环地通过浏览器向服务端发送文件上传请求。对于任意一个文件上传请求，若该文件上传请求中携带分片总数且分片总数大于第一阈值，则服务端会获取该文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，并根据用户标识和分片标识，缓存当前上传的分片数据；服务端循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与分片总数一致后合并成为一个完整的文件。

基于以上描述可知，终端在通过浏览器上传文件时，会先判断文件大小，并在待上传的文件为大文件时，会对大文件进行分割处理形成多个分片数据，循环地向服务端上传分片数据，而服务端负责缓存分片数据，直至最后一个分片数据，该种文件上传方式避免了在通过浏览器上传大文件时可能出现的浏览器被卡死现象，提高了文件上传的成功率，因此该种文件上传方式的效果较佳。

图7是根据一示例性实施例示出的一种文件上传装置的框图。参照图7，该装置包括：接收模块701，获取模块702和缓存模块703。

接收模块701，被配置为接收终端通过浏览器发送的文件上传请求；

获取模块702，被配置为若所述文件上传请求中携带分片总数且所述分片总数大于第一阈值，则获取所述文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，所述分片总数用于指示目标文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值；

缓存模块703，被配置为根据所述用户标识和当前上传的分片数据的分片标识，缓存当前上传的分片数据；

接收模块701和缓存模块703，还被配置为循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与所述分片总数一致。

本公开实施例提供的装置，在上传大文件时，终端会将大文件分割处理为至少两个分片数据，其中，分片总数用于指示大文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值；之后，终端会循环地通过浏览器向服务端发送文件上传请求。对于任意一个文件上传请求，若该文件上传请求中携带分片总数且分片总数大于第一阈值，则服务端会获取该文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，并根据用户标识和分片标识，缓存当前上传的分片数据；服务端循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与分片总数一致。

基于以上描述可知，终端在通过浏览器上传文件时，会先判断文件大小，并在待上传的文件为大文件时，会对大文件进行分割处理形成多个分片数据，循环地向服务端上传分片数据，而服务端负责缓存分片数据，直至最后一个分片数据，该种文件上传方式避免了在通过浏览器上传大文件时可能出现的浏览器被卡死现象，提高了文件上传的成功率，因此该种文件上传方式的效果较佳。

在一种可能的实现方式中，所述文件上传请求中还携带所述目标文件的文件标识；该装置还包括：

第一创建模块，被配置为以所述目标文件的文件标识作为文件名称进行新文件创建；

读取模块，被配置为循环读取已缓存的分片数据；

写入模块，被配置为将读取到的分片数据写入到创建好的新文件中，直至读取完毕所述已缓存的分片数据；

发送模块，被配置为若至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中，则向所述终端返回第一通知消息；若每个分片数据均被成功读取且均被成功写入到创建好的新文件中，则向所述终端返回第二通知消息。

在一种可能的实现方式中，该装置还包括：

第二创建模块，被配置为创建缓存文件数组；

所述缓存模块，还被配置为根据所述用户标识和当前上传的分片数据的分片标识，将当前上传的分片数据写入到所述缓存文件数组中。

在一种可能的实现方式中，各个分片数据以流数据的形式缓存在所述缓存文件数组中；所述读取模块，还被配置为循环读取所述缓存文件数组中的流数据；

所述写入模块，还被配置为将读取到的流数据写入到创建好的新文件中，直至读取完毕所述缓存文件数组中的流数据。

上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。

图8是根据一示例性实施例示出的一种文件上传装置的框图。参照图8，该装置包括：获取模块801，分割模块802和发送模块803。

获取模块801，被配置为获取待上传的目标文件；

分割模块802，被配置为若所述目标文件的大小大于第二阈值，则对所述目标文件进行分割处理，得到至少两个分片数据；

发送模块803，被配置为通过浏览器向网络服务器发送文件上传请求，所述文件上传请求中携带分片总数、用户标识、当前上传的分片数据以及所述分片数据的分片标识，所述分片总数用于指示所述目标文件被分割处理为分片数据的数量，每个分片数据的大小均不大于所述第二阈值；

其中，所述文件上传请求用于指示所述网络服务器在确定所述文件上传请求中携带所述分片总数且所述分片总数大于第一阈值后，获取所述用户标识和当前上传的分片数据的分片标识，并根据所述用户标识和所述分片标识缓存当前上传的分片数据；

发送模块803，还被配置为循环执行上述向所述网络服务器发送文件上传请求的步骤，直至遍历每个分片数据。

本公开实施例提供的装置，在上传大文件时，终端会将大文件分割处理为至少两个分片数据，其中，分片总数用于指示大文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值；之后，终端会循环地通过浏览器向服务端发送文件上传请求。对于任意一个文件上传请求，若该文件上传请求中携带分片总数且分片总数大于第一阈值，则服务端会获取该文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，并根据用户标识和分片标识，缓存当前上传的分片数据；服务端循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与分片总数一致。

基于以上描述可知，终端在通过浏览器上传文件时，会先判断文件大小，并在待上传的文件为大文件时，会对大文件进行分割处理形成多个分片数据，循环地向服务端上传分片数据，而服务端负责缓存分片数据，直至最后一个分片数据，该种文件上传方式避免了在通过浏览器上传大文件时可能出现的浏览器被卡死现象，提高了文件上传的成功率，因此该种文件上传方式的效果较佳。

在一种可能的实现方式中，所述文件上传请求中还携带所述目标文件的文件标识；

其中，所述文件标识用于指示所述网络服务器以所述文件标识作为文件名称进行新文件创建，并将循环接收到的分片数据写入到创建好的新文件中。

在一种可能的实现方式中，该装置还包括：

接收模块，被配置为接收所述网络服务器返回的第一通知消息，所述第一通知消息由所述网络服务器在确定至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中后，向所述终端发送；或，接收所述网络服务器返回的第二通知消息，所述第二通知消息由所述网络服务器在确定每个分片数据均被成功读取且均被成功写入到创建好的新文件中后，向所述终端发送。

上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图9示出了本公开一个示例性实施例提供的一种电子设备900的结构框图。其中，该设备900可以是便携式移动终端，比如：智能手机、平板电脑、MP3播放器(Moving PictureExperts Group Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(MovingPicture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。设备900还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，设备900包括有：处理器901和存储器902。

处理器901可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器901可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器901也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器901可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器901还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器902可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器902还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器902中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器901所执行以实现本公开中方法实施例提供的文件上传方法。

在一些实施例中，设备900还可选包括有：外围设备接口903和至少一个外围设备。处理器901、存储器902和外围设备接口903之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口903相连。具体地，外围设备包括：射频电路904、触摸显示屏905、摄像头906、音频电路907、定位组件908和电源909中的至少一种。

外围设备接口903可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器901和存储器902。在一些实施例中，处理器901、存储器902和外围设备接口903被集成在同一芯片或电路板上；在一些其他实施例中，处理器901、存储器902和外围设备接口903中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路904用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路904通过电磁信号与通信网络以及其他通信设备进行通信。射频电路904将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路904包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路904可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：万维网、城域网、内联网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路904还可以包括NFC(Near Field Communication，近距离无线通信)有关的电路，本公开对此不加以限定。

显示屏905用于显示UI(User Interface，用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏905是触摸显示屏时，显示屏905还具有采集在显示屏905的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器901进行处理。此时，显示屏905还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏905可以为一个，设置设备900的前面板；在另一些实施例中，显示屏905可以为至少两个，分别设置在设备900的不同表面或呈折叠设计；在再一些实施例中，显示屏905可以是柔性显示屏，设置在设备900的弯曲表面上或折叠面上。甚至，显示屏905还可以设置成非矩形的不规则图形，也即异形屏。显示屏905可以采用LCD(LiquidCrystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode,有机发光二极管)等材质制备。

摄像头组件906用于采集图像或视频。可选地，摄像头组件906包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件906还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路907可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器901进行处理，或者输入至射频电路904以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在设备900的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器901或射频电路904的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路907还可以包括耳机插孔。

定位组件908用于定位设备900的当前地理位置，以实现导航或LBS(LocationBased Service，基于位置的服务)。定位组件908可以是基于美国的GPS(GlobalPositioning System，全球定位系统)、中国的北斗系统或俄罗斯的伽利略系统的定位组件。

电源909用于为设备900中的各个组件进行供电。电源909可以是交流电、直流电、一次性电池或可充电电池。当电源909包括可充电电池时，该可充电电池可以是有线充电电池或无线充电电池。有线充电电池是通过有线线路充电的电池，无线充电电池是通过无线线圈充电的电池。该可充电电池还可以用于支持快充技术。

在一些实施例中，设备900还包括有一个或多个传感器910。该一个或多个传感器910包括但不限于：加速度传感器911、陀螺仪传感器912、压力传感器913、指纹传感器914、光学传感器915以及接近传感器916。

加速度传感器911可以检测以设备900建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器911可以用于检测重力加速度在三个坐标轴上的分量。处理器901可以根据加速度传感器911采集的重力加速度信号，控制触摸显示屏905以横向视图或纵向视图进行用户界面的显示。加速度传感器911还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器912可以检测设备900的机体方向及转动角度，陀螺仪传感器912可以与加速度传感器911协同采集用户对设备900的3D动作。处理器901根据陀螺仪传感器912采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器913可以设置在设备900的侧边框和/或触摸显示屏905的下层。当压力传感器913设置在设备900的侧边框时，可以检测用户对设备900的握持信号，由处理器901根据压力传感器913采集的握持信号进行左右手识别或快捷操作。当压力传感器913设置在触摸显示屏905的下层时，由处理器901根据用户对触摸显示屏905的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

指纹传感器914用于采集用户的指纹，由处理器901根据指纹传感器914采集到的指纹识别用户的身份，或者，由指纹传感器914根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器901授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器914可以被设置设备900的正面、背面或侧面。当设备900上设置有物理按键或厂商Logo时，指纹传感器914可以与物理按键或厂商Logo集成在一起。

光学传感器915用于采集环境光强度。在一个实施例中，处理器901可以根据光学传感器915采集的环境光强度，控制触摸显示屏905的显示亮度。具体地，当环境光强度较高时，调高触摸显示屏905的显示亮度；当环境光强度较低时，调低触摸显示屏905的显示亮度。在另一个实施例中，处理器901还可以根据光学传感器915采集的环境光强度，动态调整摄像头组件906的拍摄参数值。

接近传感器916，也称距离传感器，通常设置在设备900的前面板。接近传感器916用于采集用户与设备900的正面之间的距离。在一个实施例中，当接近传感器916检测到用户与设备900的正面之间的距离逐渐变小时，由处理器901控制触摸显示屏905从亮屏状态切换为息屏状态；当接近传感器916检测到用户与设备900的正面之间的距离逐渐变大时，由处理器901控制触摸显示屏905从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图9中示出的结构并不构成对设备900的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

图10是本公开实施例提供的一种电子设备1000的结构框图。

该设备1000可以为前述方法实施例中提及的网络服务器。该服务器1000可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processingunits，CPU)1001和一个或一个以上的存储器1002，其中，所述存储器1002中存储有至少一条指令，所述至少一条指令由所述处理器1001加载并执行以实现上述各个方法实施例提供的文件上传方法。当然，该服务器还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该服务器还可以包括其他用于实现设备功能的部件，在此不做赘述。

在示例性实施例中，还提供了一种包括指令的存储介质，例如包括指令的存储器，上述指令可由电子设备900或电子设备100的处理器执行以完成上述文件上传方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种计算机程序产品，所述计算机程序产品中的指令由电子设备900或电子设备100的处理器执行时，使得电子设备900或电子设备100能够执行如上述方法实施例中的文件上传方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (8)

1.一种文件上传方法，其特征在于，包括：

开启websocket服务，基于所述websocket服务接收终端通过浏览器发送的文件上传请求；

若所述文件上传请求中携带分片总数且所述分片总数大于第一阈值，则获取所述文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，所述分片总数用于指示目标文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值；

根据所述用户标识和当前上传的分片数据的分片标识，缓存当前上传的分片数据；

循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与所述分片总数一致；

所述文件上传请求中还携带所述目标文件的文件标识；在已上传的分片数据的数量达到所述分片总数之后，还包括：

以所述目标文件的文件标识作为文件名称进行新文件创建；

循环读取已缓存的分片数据，并将读取到的分片数据写入到创建好的新文件中，直至读取完毕所述已缓存的分片数据；

若至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中，则基于所述websocket服务向所述终端返回第一通知消息，所述第一通知消息用于指示所述目标文件上传失败；

若每个分片数据均被成功读取且均被成功写入到创建好的新文件中，则基于所述websocket服务向所述终端返回第二通知消息，所述第二通知消息用于指示所述目标文件上传成功。

2.根据权利要求1所述的文件上传方法，其特征在于，在接收终端通过浏览器发送的文件上传请求之后，还包括：创建缓存文件数组；

所述根据所述用户标识和当前上传的分片数据的分片标识，缓存当前上传的分片数据，包括：

根据所述用户标识和当前上传的分片数据的分片标识，将当前上传的分片数据写入到所述缓存文件数组中。

3.根据权利要求2所述的文件上传方法，其特征在于，各个分片数据以流数据的形式缓存在所述缓存文件数组中；

所述循环读取已缓存的分片数据，并将读取到的分片数据写入到创建好的新文件中，直至读取完毕所述已缓存的分片数据，包括：

循环读取所述缓存文件数组中的流数据，并将读取到的流数据写入到创建好的新文件中，直至读取完毕所述缓存文件数组中的流数据。

4.一种文件上传方法，其特征在于，包括：

获取待上传的目标文件，若所述目标文件的大小大于第二阈值，则对所述目标文件进行分割处理，得到至少两个分片数据；

开启websocket服务，基于所述websocket服务通过浏览器向网络服务器发送文件上传请求，所述文件上传请求中携带分片总数、用户标识、当前上传的分片数据以及所述分片数据的分片标识，所述分片总数用于指示所述目标文件被分割处理为分片数据的数量，每个分片数据的大小均不大于所述第二阈值；

其中，所述文件上传请求用于指示所述网络服务器在确定所述文件上传请求中携带所述分片总数且所述分片总数大于第一阈值后，获取所述用户标识和当前上传的分片数据的分片标识，并根据所述用户标识和所述分片标识缓存当前上传的分片数据；

循环执行上述向所述网络服务器发送文件上传请求的步骤，直至遍历每个分片数据；

所述文件上传请求中还携带所述目标文件的文件标识；

其中，所述文件标识用于指示所述网络服务器以所述文件标识作为文件名称进行新文件创建，并将循环接收到的分片数据写入到创建好的新文件中；

在发送所述文件上传请求之后，所述方法还包括：

基于所述websocket服务接收所述网络服务器返回的第一通知消息，所述第一通知消息由所述网络服务器在确定至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中后，向终端发送，所述第一通知消息用于指示所述目标文件上传失败；或，

基于所述websocket服务接收所述网络服务器返回的第二通知消息，所述第二通知消息由所述网络服务器在确定每个分片数据均被成功读取且均被成功写入到创建好的新文件中后，向所述终端发送，所述第二通知消息用于指示所述目标文件上传成功。

5.一种文件上传装置，其特征在于，包括：

接收模块，被配置为开启websocket服务，基于所述websocket服务接收终端通过浏览器发送的文件上传请求；

获取模块，被配置为若所述文件上传请求中携带分片总数且所述分片总数大于第一阈值，则获取所述文件上传请求中携带的用户标识和当前上传的分片数据的分片标识，所述分片总数用于指示目标文件被分割处理为分片数据的数量，每个分片数据的大小不大于第二阈值；

缓存模块，被配置为根据所述用户标识和当前上传的分片数据的分片标识，缓存当前上传的分片数据；

所述接收模块和所述缓存模块，还被配置为循环执行上述接收文件上传请求并缓存相应的文件上传请求中携带的分片数据的步骤，直至已上传的分片数据的数量与所述分片总数一致；

所述文件上传请求中还携带所述目标文件的文件标识；所述装置还包括：

第一创建模块，被配置为以所述目标文件的文件标识作为文件名称进行新文件创建；

读取模块，被配置为循环读取已缓存的分片数据；

写入模块，被配置为将读取到的分片数据写入到创建好的新文件中，直至读取完毕所述已缓存的分片数据；

发送模块，被配置为若至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中，则基于所述websocket服务向所述终端返回第一通知消息，所述第一通知消息用于指示所述目标文件上传失败；若每个分片数据均被成功读取且均被成功写入到创建好的新文件中，则基于所述websocket服务向所述终端返回第二通知消息，所述第二通知消息用于指示所述目标文件上传成功。

6.一种文件上传装置，其特征在于，包括：

获取模块，被配置为获取待上传的目标文件；

分割模块，被配置为若所述目标文件的大小大于第二阈值，则对所述目标文件进行分割处理，得到至少两个分片数据；

发送模块，被配置为开启websocket服务，基于所述websocket服务通过浏览器向网络服务器发送文件上传请求，所述文件上传请求中携带分片总数、用户标识、当前上传的分片数据以及所述分片数据的分片标识，所述分片总数用于指示所述目标文件被分割处理为分片数据的数量，每个分片数据的大小均不大于所述第二阈值；

其中，所述文件上传请求用于指示所述网络服务器在确定所述文件上传请求中携带所述分片总数且所述分片总数大于第一阈值后，获取所述用户标识和当前上传的分片数据的分片标识，并根据所述用户标识和所述分片标识缓存当前上传的分片数据；

所述发送模块，还被配置为循环执行上述向所述网络服务器发送文件上传请求的步骤，直至遍历每个分片数据；

所述文件上传请求中还携带所述目标文件的文件标识；

其中，所述文件标识用于指示所述网络服务器以所述文件标识作为文件名称进行新文件创建，并将循环接收到的分片数据写入到创建好的新文件中；

所述装置还包括：

接收模块，被配置为基于所述websocket服务接收所述网络服务器返回的第一通知消息，所述第一通知消息由所述网络服务器在确定至少一个分片数据未被成功读取或未被成功写入到创建好的新文件中后，向终端发送，所述第一通知消息用于指示所述目标文件上传失败；或，

所述接收模块，被配置为基于所述websocket服务接收所述网络服务器返回的第二通知消息，所述第二通知消息由所述网络服务器在确定每个分片数据均被成功读取且均被成功写入到创建好的新文件中后，向所述终端发送，所述第二通知消息用于指示所述目标文件上传成功。

7.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至3中任一项所述的文件上传方法；或，如权利要求4所述的文件上传方法。

8.一种计算机可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1至3中任一项所述的文件上传方法；或，如权利要求4所述的文件上传方法。

Images