一种基于二维码的文件协同处理方法及系统与流程

本发明涉及文件协同处理领域，特别涉及一种基于二维码的文件协同处理方法及系统。

背景技术：

文件共享包括了：本地局域网共享、网盘云共享、U盘文件共享方面。

协同处理，是指发生在两台或多台计算机分担一个程序或计算任务处理的分布式计算系统中。一般而言，协同处理需要一个复杂的程序能在网络上处理分配负载、共享数据文件和内存竞争，同时要维持信息的同步安全性和准确性。

此外，在远程协同处理上述共享文件中的某一个文案时，往往要反复上传、下载，甚至还会遇到Word、Office等版本不同，还需要各种更新；特别是当Windows与Mac系统文件相遇时，不仅版本不兼容且无法实现多人协同操作。

目前单据的录入是软件使用过程中最常见的场景，较为常见的应用场景是：通常一个单据由一个录入员在一台设备上就可以完成，但也存在一些场景比较复杂。

首先，单据需要的资料在多个人手中，比如地产工地现场的一些变更涉及到合同信息、费用、施工设计、变更前后照片等，需要开发商、施工方等多人提供资料。

其次，单据信息在不同设备上，比如在office附件在pc上，但一些现场的施工照片在手机上。

上述复杂的场景通常做法有两种形式：

1.线下搜集资料，然后交给统一对接人统一录入；

2.通过流程转接进行协作，一个人录入完成后再转到下个人进行录入；

这两种方式都会导致单据录入很繁琐，而且周期非常长，用户体验差。

技术实现要素：

本发明要解决的技术问题是，如何实现高效率处理和快捷协同处理的基于二维码的文件协同处理方法。

解决上述技术问题，本发明提供了一种基于二维码的文件协同处理方法，包括如下步骤：

第一协作者，按照文件处理需求生成第一处理指令，

根据所述第一处理指令生成文件二维码，并将所述文件二维码分享至：

第二协作者，

第三协作者，

……

第N协作者，N为自然数，

所述第二协作者、第三协作者……以及第N协作者通过扫描所述文件二维码获取编辑权限，根据所述编辑权限编辑符合上述文件处理需求的内容，并且分别上传；

所述第一协作者同步获得上述编辑过后的内容并提交。

更进一步，所述第一协作者、所述第二协作者、第三协作者……以及第N协作者与服务器通过长连接保持通信。

更进一步，所述文件二维码分享方法为：微博、链接或者微信中的一种或者多种第三方API接口。

更进一步，所述第一协作者还用以根据同步获得的编辑内容，生成用以确认提交、重新修订以及审批通过的第二处理指令。

更进一步，所述第一协作者还用以处理：文件变更、文件作废、文件处理、文件备案的文件处理需求。

更进一步，根据所述第一处理指令生成文件二维码的具体方法如下：

基于对应的文件编号ID+当前处理时间+GUID全局唯一标识符，并采用AES对称加密算法，进行加密后作为所述文件二维码。

更进一步，当所述第二协作者、第三协作者……以及第N协作者扫描所述文件二维码时，

通过反解密算法得到文件二维码的文件编号ID和当前处理时间，再校验扫描二维码的所述第二协作者、第三协作者……以及第N协作者是否具有该文件的权限；

若有权限，则根据当前处理时间校验是否过期，

以及，校验是否被提交了，若已提交则其他协作者不能再进行编辑。

基于上述本发明提供了一种基于二维码的文件协同处理系统，包括：多个客户端以及至少一个服务器端，

所述客户端与服务器端连接，所述客户端包括：第一客户端、第二客户端、第三客户端……以及第N客户端；

所述第一客户端用以，按照文件处理需求生成第一处理指令，根据所述第一处理指令生成文件二维码，并将所述文件二维码分享至：

第二客户端，

第三客户端，

……

第N客户端，N为自然数，

在所述第二客户端、第三客户端……以及第N客户端通过扫描所述文件二维码获取编辑权限，根据所述编辑权限编辑符合上述文件处理需求的内容，并且分别上传；

在所述第一客户端同步获得上述编辑过后的内容并提交，

上述第一客户端、第二客户端、第三客户端……第N客户端分别与所述服务器端通过长连接保持通信。

此外，本发明还提供了基于二维码的文件协同处理的客户端，所述客户端被配置为：

按照文件处理需求生成第一处理指令，

根据所述第一处理指令生成文件二维码，并将所述文件二维码分享至其它客户端；

通过扫描所述文件二维码获取编辑权限，根据所述编辑权限编辑符合上述文件处理需求的内容，并且分别上传；

同步获得上述编辑过后的内容并提交。

此外，本发明还提供了基于二维码的文件协同处理的服务器端，所述服务器端用以，

接收第一协作者按照文件处理需求生成第一处理指令，根据所述第一处理指令生成文件二维码，并将所述文件二维码分享至与其长连接的：

第二协作者，

第三协作者，

……

第N协作者，N为自然数，

若所述第二协作者、第三协作者……以及第N协作者通过扫描所述文件二维码获取编辑权限，则接收根据所述编辑权限编辑符合上述文件处理需求的内容分别上传的文件，

以及，接收从所述第一协作者提交的同步获得的编辑过后的内容

本发明的有益效果：

1)本发明中的基于二维码的文件协同处理方法由于第一协作者，按照文件处理需求生成第一处理指令，根据所述第一处理指令生成文件二维码，并将所述文件二维码分享至：第二协作者，第三协作者，……第N协作者，然后，所述第二协作者、第三协作者……以及第N协作者通过扫描所述文件二维码获取编辑权限，根据所述编辑权限编辑符合上述文件处理需求的内容，并且分别上传；最后，所述第一协作者同步获得上述编辑过后的内容并提交。上述过程基于文件二维码生成、文件二维码分享以及协作者与服务器端的长连接。此外，所有协作者都能够实时共享其它协作者添加的内容，而第一协作者作为协作的发起者，具有将申请提交并审批的权项，能够完成文件的审核和提交。上述过程，提高了多人协作编辑的用户体验，从而使得数据在多人之间实时传输。

2)在本发明中还提供了一种文件的二维码生成及扫描技术：基于对应的文件编号ID+当前处理时间+GUID全局唯一标识符，并采用AES对称加密算法，进行加密后作为所述文件二维码。另外，可以在当所述第二协作者、第三协作者……以及第N协作者扫描所述文件二维码时，通过反解密算法得到文件二维码的文件编号ID和当前处理时间，从而实现信息获取和权项校验。

3)相较于传统的方式，线下搜集资料后需要把资料送到同一个地点，需要重复地的花费人力和时间成本。如果通过流程来协作，一个接一个，周期会被拉的很长。而采用本发明中的基于二维码的文件协同处理方法，可以让协作者随时随地都可以在一起协作，文件录入的效率提高80％以上。

附图说明

图1是本发明一实施例中的方法流程示意图；

图2是二维码生成算法流程示意图；

图3与图2对应的反解密算法流程示意图；

图4是本发明中基于客户端的操作流程示意图；

图5是本发明中基于服务器端的操作流程示意图；

图6是本发明的一实施例中的拓扑结构图；

图7是本发明一实施例中的交互示意图；

图8是本发明另一实施例中的交互示意图；

图9是本发明再一实施例中的交互示意图。

具体实施方式

现在将参考一些示例实施例描述本公开的原理。可以理解，这些实施例仅出于说明并且帮助本领域的技术人员理解和实施例本公开的目的而描述，而非建议对本公开的范围的任何限制。在此描述的本公开的内容可以以下文描述的方式之外的各种方式实施。

如本文中所述，术语“包括”及其各种变体可以被理解为开放式术语，其意味着“包括但不限于”。术语“基于”可以被理解为“至少部分地基于”。术语“一个实施例”可以被理解为“至少一个实施例”。术语“另一实施例”可以被理解为“至少一个其它实施例”。

图1是本发明一实施例中的方法流程示意图，本实施例中的一种基于二维码的文件协同处理方法，包括如下步骤：

步骤S100第一协作者，按照文件处理需求生成第一处理指令，

步骤S101根据所述第一处理指令生成文件二维码，并将所述文件二维码分享至：

第二协作者，

第三协作者，

……

第N协作者，N为自然数，

步骤S102所述第二协作者、第三协作者……以及第N协作者通过扫描所述文件二维码获取编辑权限，根据所述编辑权限编辑符合上述文件处理需求的内容，并且分别上传；

步骤S103所述第一协作者同步获得上述编辑过后的内容并提交。

在一些实施例中，在上述步骤S101中所述第一协作者、所述第二协作者、第三协作者……以及第N协作者与服务器通过长连接保持通信。在本实施例中长连接即是要在客户端与服务器之间创建和保持稳定可靠的连接。通常的做法是，在服务器的程序中加入一个死循环，在循环中监测数据的变动。当发现新数据时，立即将其输出给浏览器并断开连接，浏览器在收到数据后，再次发起请求以进入下一个周期的长轮询(long-polling)方式。长连接在页面里嵌入一个隐蔵iframe，将这个隐蔵iframe的src属性设为对一个长连接的请求或是采用xhr请求，服务器端就能源源不断地往客户端输入数据。

作为本实施例中的优选，所述文件二维码分享方法为：微博、链接或者微信中的一种或者多种第三方API接口。所述第二协作者、第三协作者……以及第N协作者通过分享的文件二维码，即可打开对应的需要操作的文件。

在一些实施例中，所述第一协作者还用以根据同步获得的编辑内容，生成用以确认提交、重新修订以及审批通过的第二处理指令。

确认提交：将文件确认后提交至接收端。

重新修订：对文件进行更新或者修改。

审批通过：审批文件中的条款或者款项。

在一些实施例中，所述第一协作者还用以处理：文件变更、文件作废、文件处理、文件备案的文件处理需求。

文件变更，包括但不限于文件中涉及甲方、乙方或者第三方的文件变更内容。

文件作废，包括但不限于将文件中的内容部分或者全部作废。

文件处理，包括但不限于将文件中缺少的内容进行完善、将有误的内容进行修订、将多余的内容进行删除等。

文件备案，包括但不限于对文件内容进行备份留档。

在一些实施例中，所述第一协作者作为协作的发起者，所述第二协作者、第三协作者……以及第N协作者作为文件的协作者，所述第一协作者具备查看、修改、审核以及提交等权限，所述所述第二协作者、第三协作者不具备审核以及提交的权限，具备查看更新文件、修改文件的权项。

上述的方法，可以应用至以下的施工场景中：

STEP 1在工地现场需要发起一个变更申请，用户A(比如，施工方项目经理)打开一个变更的新增界面，填写变更单。所述变更单除了用户A要录入“变更内容”和“变更日期”外还有其他很多信息：

比如，这个施工项目的“合同照片”，在用户B(比如，施工方的合同管理员)手中；另外还需要上传“施工前后照片”，在用户C(比如，施工方工程师)手机上；

STEP 2用户A在界面上点击生成二维码按钮，生成二维码，将该二维码图片分享给需要协作的用户B、用户C、……或者更多需要协作参与的用户。

STEP 3用户B、用户C通过扫描二维码进入同一个变更单，进行编辑。

STEP 4用户A、用户B、用户C编辑的内容传递到服务器端，再由服务器端分发给其他用户，这样所有人可以同时编辑内容又能实时看到其他人编辑的内容

STEP 5最后由单据的发起人(用户A)检查完整后提交单据，只有单据的发起人才能最后提交表单，其他人只能填写信息和查看别人填写的信息。

以上完成了文件协同处理，上述过程基于文件二维码生成、文件二维码分享以及协作者与服务器端的长连接。此外，所有协作者都能够实时共享其它协作者添加的内容，而第一协作者作为协作的发起者，具有将申请提交并审批的权项，能够完成文件的审核和提交。上述过程，提高了多人协作编辑的用户体验，从而使得数据在多人之间实时传输。

图2是二维码生成算法流程示意图，根据所述第一处理指令生成文件二维码的具体方法如下：基于对应的文件编号ID+当前处理时间+GUID全局唯一标识符，并采用AES对称加密算法，进行加密后作为所述文件二维码。

作为本实施例中的优选，在上述STEP 1中涉及的所有变更单都是基于合同的，用户A在点击“生成二维码”UI按钮时，会将该变更单对应的合同ID+当前时间+GUID，用AES对称加密算法进行加密后作为内容生成二维码。

所述合同ID包括但不限于：合同编号。

所述当前时间包括但不限于：当前处理发起时间、当前处理截止时间等。

所述GUID是指，全局唯一标识符(GUID，Globally Unique Identifier)是一种由算法生成的二进制长度为128位的数字标识符。GUID主要用于在拥有多个节点、多台计算机的网络或系统中。在理想情况下，任何计算机和计算机集群都不会生成两个相同的GUID。随机生成两个相同GUID的可能性是非常小的，但并不为0。所以，用于生成GUID的算法通常都加入了非随机的参数(如时间)，以保证这种重复的情况不会发生。本实施例中采用GUID符合多人协作的网络环境要求即多个节点、多台计算机的网络。

作为本实施例中的优选，对称加密算法还可以是：DES算法、3DES算法，TDEA算法、Blowfish算法、RC5算法、IDEA算法、AES算法。

AES算法是广泛运用的可以用于保护电子数据的加密算法。在AES算法中采用迭代的、对称密钥分组的密码，它可以使用128、192和256位密钥，并且用128位(16字节)分组加密和解密数据。与公共密钥密码使用密钥对不同，对称密钥密码使用相同的密钥加密和解密数据。通过分组密码返回的加密数据的位数与输入数据相同。迭代加密使用一个循环结构，在该循环中重复置换(permutations)和替换(substitutions)输入数据。采用相同的密钥加密和解密数据，得到使得所述第二协作者、第三协作者……以及第N协作者通过扫描所述文件二维码后，能够解密并获得文件信息内容。

图3与图2对应的反解密算法流程示意图，包括步骤为：

步骤S300所述第二协作者、第三协作者……以及第N协作者扫描所述文件二维码，

步骤S301通过反解密算法得到文件二维码的文件编号ID和当前处理时间，

步骤S302校验扫描二维码的所述第二协作者、第三协作者……以及第N协作者是否具有该文件的权限；

步骤S303若有权限，则根据当前处理时间校验是否过期，

步骤S304校验是否被提交了，若已提交则其他协作者不能再进行编辑。

上述步骤S302为一级校验，步骤S303为二级校验，步骤S304为三极校验。在所述步骤S302中所述第二协作者、第三协作者……以及第N协作者获得上述文件的权限，若没有权限则无法查看或者修改。在所述步骤S303中需要校验当前处理时间是否过期，比如设定的当前处理时间为2hs，若超过则过期，二维码失效。在所述步骤S304中，校验文件是否被协作的发起者提交，若已经提交则无法进行查看或者修改。

若否则进入步骤S305，获得文件查看或者编辑权限。

在一些实施例中，所述第二协作者、第三协作者……以及第N协作者包括但不限于：PC端、WEB端、IOS/安卓端。

在一些实施例中，所述第二协作者、第三协作者……以及第N协作者可分别选用PC端、WEB端、IOS/安卓端进行协作。

在一些实施例中，所述第二协作者、第三协作者……以及第N协作者可选用相同的PC端、WEB端、IOS/安卓端进行协作。

在PC端上传完office附件后，在移动端立即扫描二维码就可以打开单据传输图片。而不需要像原来先把图片通过数据线传输到PC上，在上传到单据中。

本实施例中的二维码生成和解密方法，基于对应的文件编号ID+当前处理时间+GUID全局唯一标识符，并采用AES对称加密算法，进行加密后作为所述文件二维码。另外，可以在当所述第二协作者、第三协作者……以及第N协作者扫描所述文件二维码时，通过反解密算法得到文件二维码的文件编号ID和当前处理时间，从而实现信息获取和权项校验。

图4是本发明中基于客户端的操作流程示意图，基于二维码的文件协同处理的客户端，所述客户端被配置为：按照文件处理需求生成第一处理指令，根据所述第一处理指令生成文件二维码，并将所述文件二维码分享至其它客户端；通过扫描所述文件二维码获取编辑权限，根据所述编辑权限编辑符合上述文件处理需求的内容，并且分别上传；同步获得上述编辑过后的内容并提交。

作为本实施例中的优选，所述客户端被封装为基于WEB端的应用程序软件。

作为本实施例中的优选，所述客户端被封装为PC端的应用程序软件。

作为本实施例中的优选，所述客户端被封装为手机端的应用程序软件。

所述客户端按照文件处理需求生成第一处理指令包括但不限于：变更、作废、审批。

所述客户端可将所述文件二维码分享至其它客户端，或者直接扫一扫所述文件二维码。

协作者通过所述客户端扫描所述文件二维码获取编辑权限，所述编辑权限按照协作者的用户分组确定，所述用户分组为：甲方、乙方或者项目相关的第三方。

图5是本发明中基于服务器端的操作流程示意图，基于二维码的文件协同处理的服务器端，所述服务器端用以，接收第一协作者按照文件处理需求生成第一处理指令，根据所述第一处理指令生成文件二维码，并将所述文件二维码分享至与其长连接的：第二协作者，第三协作者，……第N协作者，N为自然数，若所述第二协作者、第三协作者……以及第N协作者通过扫描所述文件二维码获取编辑权限，则接收根据所述编辑权限编辑符合上述文件处理需求的内容分别上传的文件，以及，接收从所述第一协作者提交的同步获得的编辑过后的内容。

在一些实施例中，服务器端为本地服务器以及数据库。

在一些实施例中，服务器端为云端服务器以及本地数据库。

在一些实施例中，服务器端包括：应用程序服务器和本地数据库。

在本实施例中的服务器端，用以接收第一协作者按照文件处理需求，在接收到文件二维码后发送至其他通过扫描二维码获得文件处理权项的第二协作者，第三协作者，……第N协作者，所述第二协作者，第三协作者，……第N协作者完成后同步至服务器端，此时服务器端再将所述第二协作者，第三协作者，……第N协作者分别变更的数据，由第一协作者确认并再次将完整的变更请求发送至服务器端。

图6是本发明的一实施例中的拓扑结构图，STEP 1在工地现场需要发起一个变更申请，用户A(比如，施工方项目经理)打开一个变更的新增界面，填写变更单。所述变更单除了用户A要录入“变更内容”和“变更日期”外还有其他很多信息：

比如，这个施工项目的“合同照片”，在用户B(比如，施工方的合同管理员)手中；另外还需要上传“施工前后照片”，在用户C(比如，施工方工程师)手机上；

STEP 2用户A在界面上点击生成二维码按钮，生成二维码，将该二维码图片分享给需要协作的用户B、用户C、……或者更多需要协作参与的用户。在所述STEP 2中，所有变更单都是基于合同的，用户A在点击“生成二维码”按钮时，会将该变更单对应的合同ID+当前时间+GUID用AES对称加密算法进行加密后作为内容生成二维码，

STEP 3用户B、用户C通过扫描二维码进入同一个变更单，进行编辑。在所述STEP 3中当扫描二维码时，通过反解密就能得到该二维码的合同和生成时间，再校验扫描二维码的人是否具有该合同的权限，如果有权限，再根据二维码生成时间校验是否过期。最后还会校验这个单据是否被用户A(二维码发起人)提交了，如果单据已经提交了，其他用户也不能再编辑了。若上述的条件都满足时，用户B、C就可以录入内容了。

STEP 4用户A、用户B、用户C编辑的内容传递到服务器端，再由服务器端分发给其他用户，这样所有人可以同时编辑内容又能实时看到其他人编辑的内容

STEP 5最后由单据的发起人(用户A)检查完整后提交单据，只有单据的发起人才能最后提交表单，其他人只能填写信息和查看别人填写的信息。

图7是本发明一实施例中的交互示意图，包括：多个客户端以及至少一个服务器端，所述客户端与服务器端连接，

所述客户端包括：第一客户端、第二客户端、第三客户端……以及第N客户端；

S1所述第一客户端即客户端A用以执行操作：协作者按照文件处理需求生成第一处理指令，

S2根据所述第一处理指令生成文件二维码，并将所述文件二维码分享至客户端B，包括但不限于：第二客户端，第三客户端，……第N客户端，N为自然数，

S3其它协作者在所述第二客户端、第三客户端……以及第N客户端通过扫描所述文件二维码获取编辑权限，

S4根据所述编辑权限编辑符合上述文件处理需求的内容，并且分别上传；

S5在所述第一客户端同步获得上述编辑过后的内容并提交，

上述第一客户端、第二客户端、第三客户端……第N客户端分别与所述服务器端通过长连接保持通信。

图8是本发明另一实施例中的交互示意图，包括：

客户端A,S1按照文件处理需求生成第一处理指令，

客户端B,S2根据所述第一处理指令生成文件二维码，并将所述文件二维码分享至其它客户端；

客户端B,S3通过扫描所述文件二维码获取编辑权限，根据所述编辑权限编辑符合上述文件处理需求的内容，

客户端B，S4并且分别上传至服务器端；

客户端A，S5同步获得上述编辑过后的内容并提交。

上述的客户端A，客户端B与所述服务器端保持长连接。

采用本实施例中的客户端，用户体验能够得到大幅度提升，比如在PC端上传完office附件后，在移动端立即扫描二维码就可以打开单据传输图片。而不需要像原来先把图片通过数据线传输到PC上，在上传到单据中。

图9是本发明再一实施例中的交互示意图，包括：服务器端。

客户端A，S1接收第一协作者通过客户端A按照文件处理需求生成第一处理指令，根据所述第一处理指令生成文件二维码，并将所述文件二维码分享至与其长连接的服务器端，

客户端B,S2通过扫描所述文件二维码获取编辑权限，同步至服务器端；

客户端B,S3接收根据所述编辑权限编辑符合上述文件处理需求的内容分别上传的文件，同步至服务器端；

客户端A,S4接收从所述第一协作者提交的同步获得的编辑过后的内容,提交至服务器端。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

总体而言，本公开的各种实施例可以以硬件或专用电路、软件、逻辑或其任意组合实施。一些方面可以以硬件实施，而其它一些方面可以以固件或软件实施，该固件或软件可以由控制器、微处理器或其它计算设备执行。虽然本公开的各种方面被示出和描述为框图、流程图或使用其它一些绘图表示，但是可以理解本文描述的框、设备、系统、技术或方法可以以非限制性的方式以硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其它计算设备或其一些组合实施。

此外，虽然操作以特定顺序描述，但是这不应被理解为要求这类操作以所示的顺序执行或是以顺序序列执行，或是要求所有所示的操作被执行以实现期望结果。在一些情形下，多任务或并行处理可以是有利的。类似地，虽然若干具体实现方式的细节在上面的讨论中被包含，但是这些不应被解释为对本公开的范围的任何限制，而是特征的描述仅是针对具体实施例。在分离的一些实施例中描述的某些特征也可以在单个实施例中组合地执行。相反对，在单个实施例中描述的各种特征也可以在多个实施例中分离地实施或是以任何合适的子组合的方式实施。