CN109408790B

CN109408790B - 一种多人编辑文档的方法

Info

Publication number: CN109408790B
Application number: CN201811205670.1A
Authority: CN
Inventors: 魏拾俊
Original assignee: Wuhan Fulin Technology Co ltd
Current assignee: Wuhan Fulin Technology Co ltd
Priority date: 2018-10-17
Filing date: 2018-10-17
Publication date: 2023-08-01
Anticipated expiration: 2038-10-17
Also published as: CN109408790A

Abstract

本发明公开了一种多人编辑文档的方法，其特征在于，将文档分拆成若干个单元，服务器仅对发生了用户操作的单元进行数据更新并推送给其它用户的客户端进行数据更新。当用户编辑文档的不同单元时，相当于编辑不同的对象，它们之间的操作互相独立，完全没有影响，因此不需要和服务器非常频繁的交互就可以实现多人编辑，大幅降低了服务器的压力。另外，本发明不再使用整数作为位置标识，而是使用浮点数(小数)作为位置标识，有效减少了大量数据更新操作。本发明的方法不受网络状况影响，对服务器依赖很低，可以离线编辑，同时又很好地避免了冲突问题。

Description

一种多人编辑文档的方法

技术领域

本发明涉及一种多人编辑文档的方法，属于计算机网络技术领域。

背景技术

目前，当多人编辑同一个文档时，通常有两种实现方法，一种是离线方式编辑，然后在提交给服务器的时候进行合并，典型的例子是git；另一种是实时更新，例如googledocs，当有多人编辑文档的时候，会实时在所有人的浏览器内显示其他人编辑的结果。

git是离线编辑方式，用户A和B分别在本地编辑同一篇文档，在提交到服务器的时候，和服务器上面的内容进行比对，找出差异，然后进行合并。这种方法对服务器依赖很低，不需要实时在线，只要在提交修改的时候连接服务器即可。但是，这种方法很容易出现冲突：当用户A和B分别编辑同一部分内容的时候，就会出现冲突。git会要求用户自己解决冲突，通常是后提交修改的用户解决冲突。

实时更新通常是为了避免冲突，例如用户A和B分别修改了同一段内容，googledocs通过实时更新服务器和所有用户的数据，可以比较好的解决冲突。但是要求用户A和B必须同时和服务器保持较好的网络连接，以便能够即时发送每一个用户编辑的内容。

google docs多人实时编辑的实现方法如下：

首先，google docs有一个或一组服务器，服务器上面保存了正在编辑的文档内容。用户A和B分别在自己的客户端(浏览器)上面，将文档内容从服务器下载到本地，并在客户端(浏览器)里面显示出来，以供用户编辑。google docs将整个文档作为一个stream，当用户A编辑的时候，当前位置为从文档开始的偏移量，然后记录用户输入的内容。例如当用户在第3段第5个字符输入新的字符串test的时候，向服务器发送的命令为：

[{"commands":[{"ty":"is","ibi":14,"s":"test"}],"sid":"16aa3baef0685777","reqId":30}]

其中ty:is表示插入，ibi：14表示从文档开头到第三段第5个字符的偏移量，也就是从开始到当前位置一共有15个字符。s:test表示插入的内容。当用户A插入一个或几个字符，客户端(浏览器)就会发送一下当前编辑的内容给服务器。通常用户修改之后的1-5秒内，就会发送一次修改。当修改后的内容发送给服务器之后，客户端(浏览器)会继续记录用户的下一次修改内容，并继续发送给服务器。通常如果用户在连续输入内容的时候，客户端会频繁的给服务器发送数据。

当用户连续输入内容的时候，通常每秒钟都会输入多个字符，为了避免不断的向服务器发送操作，造成服务器压力过大，客户端会将用户操作合并，例如当用户短时间连续输入多个字符或单词的时候，客户端会合并这些操作成为一个操作，把多个插入单个字符的操作，合并成一个插入多个字符的操作。这样，可以将请求从1秒钟多次降低为数秒钟1次。

而服务器接收到用户A的操作后，会在服务器执行类似的操作，例如收到前面的命令后，服务器就会在自己保存的文档里面，从文档开头偏移量为14的地方，插入test字符串。

由于此时B也在编辑文档，因此，服务器还需要把A编辑的命令，发送给用户B。用户B所在的客户端(浏览器)，会通过websocket等技术(因为兼容性问题，google docs没有使用websocket，而是使用了传统的http连接来解决兼容性问题)，从服务器获取其它用户编辑的操作。当用户B的客户端接收到服务器发来的操作后，同样也会执行类似的操作，找到文档开始位置偏移14的地方，插入test字符串。

因为用户B也在编辑文档，同样，有可能也会在文档开始偏移位置14或其它位置的地方插入或删除字符串，并将编辑操作发送给服务器。服务器也会接收用户B的操作，并把用户B的操作发送给用户A，用户A同样要处理用户B的操作，并合并到自己正在编辑的文档里面。

然而，这种实现方式，第一个弊端就是服务器压力非常大，因为通常一个文档内容比较大并且整个文档是一个整体，用户操作都是相对于文档开头的位置，所以服务器在执行用户操作的时候，也需要将整个文档加载到内存里面，从而造成服务器需要有足够多的内存，才能应对大量用户同时编辑不同的文档。

第二个弊端就是容易造成冲突：下面举例说明：

假如当前文档内容：

1234567890

假如在某一时间，用户A和用户B同时在编辑文档，并且用户A在位置15处插入abc，用户B在位置20插入def，那么：

此时A的内容：

1234567890

12345abc67890

1234567890

用户B的内容：

1234567890

1234567890def

1234567890

然后用户A和B分别向服务器发送编辑命令，我们希望得到的结果是：

1234567890

12345abc67890def

1234567890

当服务器先收到用户A的命令，首先服务器执行用户A的结果为：

1234567890

12345abc67890

1234567890

然后收到用户B的命令，然后服务器执行用户B的结果为：

1234567890

12345abc67def890

1234567890

但此时文档内容已经和预期的不一样了。

如果服务器先收到用户B的命令，然后收到用户A的命令，则结果符合预期：

1234567890

12345abc67890def

1234567890

因此，按照这种方式，服务器收到命令的顺序不同会导致不同的结果。要解决冲突，就要求客户端必须尽可能快的将自己的修改操作发送给服务器，并通知给其它客户端。但是这个要求又和降低服务器压力的需求相冲突，因此无法彻底解决这个问题。因为冲突的问题，google docs禁止多人离线编辑。

因此，需要一种新的多人编辑文档的方法，彻底解决现有技术对服务器依赖高，需要实时在线以及存在冲突等问题。

发明内容

本发明的目的是提供一种多人编辑文档的新方法，该方法不受网络状况影响，对服务器依赖很低，可以离线编辑，同时又很好地避免了冲突问题。

本发明提供了一种多人编辑文档的方法，其特征在于，将文档分拆成若干个单元，服务器仅对发生了用户操作的单元进行数据更新并推送给其它用户的客户端进行数据更新。

根据本发明的一个具体但非限制性的实施方案，所述的多人编辑文档的方法，包括：

将文档分拆成若干个单元，给每个单元赋予一个唯一标识id、一个位置标识和内容，服务器存储文档时记录每个单元的数据；

用户在客户端对某一个单元进行操作时，客户端将对该单元的操作发送给服务器；

服务器收到该操作后，对相应的单元进行数据更新，再将该操作推送给其它用户的客户端；

其它用户的客户端对相应的单元进行数据更新。

根据本发明的一个具体但非限制性的实施方案，其中，用户在客户端新增一个单元时，客户端将操作发送给服务器，服务器收到该操作后，新增一条记录并把新增单元的数据写入记录里，再将该操作推送给其它用户的客户端。

根据本发明的一个具体但非限制性的实施方案，其中，用户在客户端修改或删除已有的单元时，客户端将操作发送给服务器，服务器收到该操作后，通过唯一标识id找到相应的单元，更新或删除记录，再将该操作推送给其它用户的客户端。

根据本发明的一个具体但非限制性的实施方案，其中，用浮点数表示位置标识。

根据本发明的一个具体但非限制性的实施方案，其中，新增单元的位置标识是通过获取新增单元的前后两个单元的位置标识，并计算平均数而得到的。

根据本发明的一个具体但非限制性的实施方案，其中，随机选取新增单元前后两个单元的位置标识之间的任意数字，作为新增单元的位置标识。

根据本发明的一个具体但非限制性的实施方案，其中，服务器给每个用户一个独立的值，在计算新增单元的位置标识时，将这个值加入计算，以确保每个用户计算出的新增单元的位置标识都不同。

根据本发明的一个具体但非限制性的实施方案，其中，当不同用户提交的位置标识相同时，通过比较它们的id或者内容，确定先后顺序。

根据本发明的一个具体但非限制性的实施方案，其中，将新增单元的位置标识与其前后两个单元的位置标识进行比较，如果不相同，则使用该值作为新增单元的位置标识；如果与任何一个位置标识相同，则重新调整新增单元前面和/或后面若干个单元的位置标识，以便让新增单元的前后两个单元之间有足够的空间插入一个新增单元，然后根据前后两个单元调整后的位置标识，计算出新增单元的位置标识。

本发明有益效果主要体现在：

1.本发明将一个文档分拆成若干个单元，并给每一个单元赋予一个唯一标识id、一个位置标识和内容等，服务器仅对发生了用户操作的单元进行数据更新，当用户编辑文档的不同单元时，则相当于编辑不同的对象，它们之间的操作互相独立，完全没有影响，因此不需要和服务器非常频繁的交互就可以实现多人编辑，甚至可以离线编辑，服务器不需要读取或者缓存整个文档的内容，因此大幅降低了服务器的压力。同时，服务器在推送用户操作到客户端时，也不受网络状况影响，就能正确实现客户端文档更新。

2.本发明采用分拆文档的处理方式，可以有效避免google docs所遇到的各种冲突问题，而且不需要服务器有很好的性能以及很高的网络速度，大部分操作都是简单的对象增删改，不涉及复杂的冲突解决问题。

3.本发明不再使用整数作为位置标识，而是使用浮点数(小数)作为位置标识，有效减少了大量数据更新操作，进一步降低了服务器压力。同时改进了位置标识的算法，以确保位置标识刚好在合适的位置。

附图说明

图1是本发明的多人编辑文档的方法流程图。

具体实施方式

下文提供了具体的实施方式进一步说明本发明，但本发明不仅仅限于以下的实施方式。

相对于google docs等现有技术，本发明不再把一个文档当成一个整体处理，而是把它分拆成一个一个的单元。例如，我们可以把一个文档，按照换行符，分拆成不同的行，每一行就是一个单元。然后，给每个单元赋予一个唯一标识id、一个位置标识和内容等信息，其中位置标识表示了每个单元在文档中的位置，单元的内容可以是文字和/或图片等。当服务器存储文档时，不再把一个文档作为一个整体保存，而是在数据库里逐条记录文档每一个单元的信息，如表1所示：

表1服务器的数据库里文档的记录方式

doc_id	line_id	position	content
				doc1	line1	1	this is first line
doc1	line2	2	this is second line
				doc2	line1	1	this is doc 2
…	…	…	…

当用户在客户端编辑文档的时候，首先从服务器获取某一个文档的所有单元数据并按照它们的位置标识进行排序(或者在服务器已经按位置标识排好序了，客户端就不需要排序了)，例如编辑文档doc1的时候，从服务器可以获取到doc1的两行数据，如表2所示：

表2客户端从服务器获取的文档数据

line_id	position	content
			line1	1	this is first line
line2	2	this is second line

客户端就可以根据这两行数据，组成一篇完整的文档给用户编辑。如图1所示，当用户在客户端对某一单元进行增加、修改、删除的操作时，只需要将针对这个单元的操作发送给服务器，服务器收到这个操作后，只需要在数据库里面对这个单元进行相应的数据更新，再将这个操作推送给其它用户的客户端即可。服务器不需要读取或者缓存整个文档的内容，因此大幅降低了服务器的压力。

下面结合具体实施例对本发明作进一步阐述，但本发明并不限于以下实施例。

通常我们把一个文档，按照换行符，分拆成不同的行，每一行就是一个单元，下面以此为例对本发明作详细的阐述，但本发明不仅限于此，也可以按照段落把一个文档分拆成若干个单元，或者按照其它方式分拆文档。

首先介绍用户操作更新。

1.增加新行

当用户在一行末尾按下回车，则会增加一个新行，客户端新增一个行对象，自动生成一个新的id，通常可以通过uuid/guid等方式，获取一个永不重复的id，并根据当前行的位置标识，计算出新行的位置标识。例如，假如回车之前在第5行，则新增行的位置标识可以是6(后面我们会详细介绍如何计算位置标识)。行的内容，则默认为空。下面就是一个新增对象可能的内容：

客户端可以记录这个对象，并声称一个操作，发送给服务器，例如下面就是操作的内容：

服务器收到这个操作后，只需要在数据库里面新增一条记录，并把对象的数据写入记录里面即可。服务器不需要读取或者缓存整个文档的内容。

当用户在一行中间按下回车，也就是用户把原来的一行内容变成了两行。例如，假如原来一行的对象数据如下：

当用户在fox后面按下回车的时候，原来一行的内容变成了The quick brownfox，其它数据不变。同时新增了一行，内容是jumps over the lazy dog。此时产生了两个操作，一个是原来对象的修改，内容变化了。另外一个是新增了一个新的行。

此时有两个操作生成：

(1)修改操作

数据里面，只需要包含lineId和content，因为原来行的位置标识并没有变化。

(2)新增操作

新行则包括了新行完整的内容，例如新生成的id，内容以及新行的位置标识。

客户端生成这两个操作后，发送给服务器。服务器只需要更新数据库里面的原来行的数据，并插入新的记录保存新行的内容即可。同样不需要获取完整的文档内容，只需要简单的数据库操作即可。

2.修改已有的行

当用户在已有的行里面编辑内容的时候，同样，只需要生成更新操作，并把对应的操作发送给服务器即可。服务器也仅仅需要更新数据库里面的记录即可。

3.删除数据

当用户删除整行的时候，可以生成一个删除操作，例如下面的操作

将这个操作发送给服务器，服务器可以直接从数据库里面，通过id找到对应的记录删除即可。

通过以上方式，即可实现在客户端编辑文档并将操作发送给服务器更新文档数据。

接下来，举例说明插入新行时如何计算新行的位置标识。如表3所示，假如有下面三行内容：

表3原有行的记录

传统记录位置的方法是，当在第一行a后面插入一个新行的时候，此时新行将在a，b之间，新行所在的位置标识将会变成2，而原来b，c的位置标识将会分别从2，3变成3，4，如表4所示：

表4传统插入新行后的记录

line_id	position	content
			a	1	this is first line
newline	2	new line
			b	3	this is second line
c	4	this is third line

因此，当插入一个新行的时候，按照传统的方法，会导致新行后面所有行的位置标识都变化了。这对于大文档来说，将会导致大量的数据更新操作，容易造成服务器压力过大，效率低下。

而本发明用一种全新的方法来解决这个问题。当插入新行的时候，假如新行前后两行的位置标识分别是1和2，那么我们只要把新行的位置标识设置成1和2之间的任意一个浮点数值，就可以实现插入新行后不影响其它原有行的位置。例如，可以把新行的位置标识设置成1.5即可。但是要把这个位置标识设置成1.5，首先要把记录位置标识的数据类型从整数修改成浮点数。在服务器的数据库里面，也需要更改数据库字段的类型，从整数变为浮点数或小数等类型，具体和数据库相关。

修改完成后，在计算新行位置标识的时候，只需要获得新行前后两行的位置标识，然后计算出前后两行位置标识的平均数，作为新行的位置标识即可。或者按照其它算法计算，或者随机取前后两行位置标识之间的任意数值(浮点数)，作为新行的位置标识都可以。按照本发明的方法，新增行之后的结果如表5所示：

表5本发明插入新行后的记录

line_id	position	content
			a	1	this is first line
newline	1.5	new line
			b	2	this is second line
c	3	this is third line

从表5可以看到，根据本发明的方法，新增了一行内容并没有对其它任意一行造成影响。因此，发送给服务器的操作，只有新增这一个操作。这样就大量减少了数据更新操作，大幅降低了服务器的压力，大大提高了效率。

如果在最后一行增加新行，则可以直接在最后一行的位置标识后面增加一个固定数值(例如1)，作为新行的位置标识即可。同样，如果在第一行前面插入新行，则可以将第一行的位置标识减去一个固定数值(例如1)，作为新行的位置标识。

按照本发明的方法，理论上，可以在任意位置任意插入新行，而不影响其它行。但是在计算机中，浮点数是无法精确表示出任意一个小数的。例如，计算机中，无法精确表示出1.00000000000000000001这个数字，而会近似成1.0。假如我们在位置标识1后面插入一个新行，计算出新的位置标识是1.00000000000000000001的时候，就会导致新行的位置标识和前一行的位置标识相同，那么用户编辑文档的时候，这两行将可能出现先后顺序错乱的问题。

下面介绍这种极端情况的解决办法。

首先，在计算出新行的位置标识之后，将新行的位置标识和前后两行的位置标识进行比较，如果不相同，则没有出现浮点数精度的问题，可以放心使用新的位置标识；如果判定和任何一个位置标识相同，则可以认为出现了浮点数精度的问题，就不能直接使用计算后的结果作为新行的位置标识了。

需要注意的是，计算机里面浮点数判断是否相同，不能简单地通过＝(＝＝)比较，而应该通过专门的方式，这是本领域人员应该知晓的已有技术，在此不再赘述。不同的语言有不同的处理方式。

出现精度问题后，可以从新行开始，找到后面第N条(例如第10条，也可以是其它任意多条)对应的行(也可以向前找第N条)，并获得这一行的位置标识，假设位置标识是P_n。获得新行前面一行的位置标识，假设是P₀；

步长：S＝(P_n-P₀)/N；

通过循环，修改新行后面每一行P_i到P_n的位置标识，调整后的位置标识为

P_i＝P₀+S*i；

其中，P₀是新行前面一行的位置标识；i是新行后每一行到新行前面一行(P₀)的行数，值为1～N；P_i为新行后每一行的调整后的位置标识。

最后，根据新行前后两行调整后的位置标识，计算出新行的位置标识。

当一次调整N行仍然出现精度问题的时候，通过递归，调整更多行，直至可以插入新行。

下面通过表6举例说明，出现精度问题后，如何调整位置标识：

表6位置标识调整前后的变化

假如插入的新行位置在P₀和P₁之间，按照之前的计算方式，新行的位置标识应该是1.00000000001，但是由于计算机会把1.00000000001和1当成同一个数字，因此不能使用1.00000000001作为新行的位置标识，而需要重新修改新行后面若干行的位置标识，以便让P₀和P₁之间有足够的空间插入一个新行。

假如找到新行后面第四行的位置标识，让N＝4，那么

P₄-P₀＝2-1＝1

S＝1/4＝0.25

P₁＝P₀+1*0.25＝1.25

P₂＝P₀+2*0.25＝1.50

P₃＝P₀+3*0.25＝1.75

P₄＝P₀+4*0.25＝2

然后重新计算新行的位置标识：

P_新＝(1+1.25)/2＝1.125

最终计算出1.125作为新行的位置标识，同时还修改了新行后面一共三行的位置标识(P₁，P₂，P₃)。客户端把这些操作都发送给服务器进行更新。

通过以上这种方式，我们可以通过重新修改部分行的位置标识，来解决精度问题。

实际上，在实际应用中，我们几乎遇不到精度问题。即使遇到精度问题，本发明采用浮点数记录位置的方法，也比采用整数记录位置的效率高很多。

例如，我们固定在第二行的位置插入数据，从而每次都会导致之前插入的行向后排，在这种极端情况下，当依次插入1000条数据的时候，按照传统的方法，需要调整行位置的次数一共发生了498501次，而按照本发明的上述方法，只需要调整18732次。

如果我们调整新行插入的位置，不再取新行前后两行位置标识的平均数，而是在靠近新行前一行或后一行的地方取值，例如在前后两行之间90％的位置取值，则调整次数变成2411。

如果在更靠近新行前一行或后一行的地方取值，例如在前后两行之间99％的位置取值，则调整次数为0，也就是不需要额外调整任意行。

因此，根据本发明的方法，我们还可以根据实际情况，来调整新行插入位置的取值策略，进一步优化效率。

通过上述方式，可以完美实现客户端编辑文档并把操作发送给服务器进行更新。接下来我们讨论多人编辑文档和服务器推送操作。

要实现多人编辑，首先服务器需要把不同用户的操作，通知给其它用户的客户端。比较主流的方法仍然是通过websocket实现，当然也可以类似于google docs那样，通过普通的http方式。但是随着浏览器的发展，现在websocket已经是主流方式了。下面以websocket方式实现为例介绍本发明。

首先，服务器开启websocket服务，等待客户端连接。

客户端通过websocket连接到服务器，并通知服务器自己的用户身份和正在编辑的文档id。服务器则维护一个表，记录每一个文档都有那些用户正在编辑，并保持对应的链接。

当任意一个用户提交文档编辑操作的时候，服务器首先根据对应的操作，更新服务器数据。然后，在通过文档/用户表，找到都有那些用户正在编辑当前文档，并把用户操作，通过websocket推送给其它用户的客户端。

当其它用户客户端收到服务器推送的操作后，根据推送的数据，更新本地数据，并更新文档内容，就可以实时展示其它用户的编辑操作了。

由于本发明采用了分拆文档的方式，则可以有效避免google docs所遇到的各种冲突问题。下面详细介绍本发明是如何避免冲突问题的。

1、不同的用户不同行编辑

当不同用户在不同行编辑的时候，对于google docs来说，是否有冲突，仍然依赖于用户操作是否可以及时提交到服务器，并推送给每一个客户端，否则就会产生冲突，因为google docs的操作位置，全部是相对于文档开头的偏移量。

而对于本发明来说，不同用户在不同行编辑，则相当于编辑不同的对象，他们之间的操作互相独立，完全没有影响，因此不需要和服务器非常频繁的交互，就可以实现多人编辑。

例如，用户A编辑id为a的行，用户B编辑id为b的行，用户C编辑id为c的行，他们之间的操作完全独立，没有影响。即使用户A先编辑了a行，用户C后编辑了c行，然后用户C反而先提交了操作记录，用户A后提交了操作记录，服务器仍然只需要简单的执行更新操作就可以完成文档更新。同时，服务器在推送用户操作到客户端的时候，也不受网络状况影响，就能正确实现客户端文档更新。

2、当用户在同一行后面，同时插入新行编辑

考虑一种常见的情况：用户A和B同时在id为a的那一行后面，按下回车。此时，按照操作，用户A和B分别在行a后面增加了一个新行。

对于google docs来说，这是一种复杂的情况，因为相当于两个人在同一个位置进行编辑，他们之间会产生严重的冲突。

而对于本发明来说，此时两个用户的客户端分别生成了一个新行，他们新行的id不同，位置相同，都在行a之后；然后他们各自编辑自己插入的新行，并把新建行/编辑行的操作分别通知给服务器；服务器最终会把操作记录推送给对方的客户端；客户端收到通知后，则会在行a之后，插入对方新建的行，而自己新建的行不受影响。这样就完美地避免了冲突。

在这里可能会遇到一个问题，就是按照之前计算插入位置标识的算法，会获取新行所在位置前后两行位置标识的平均值作为新行的位置标识，从而导致用户A/B客户端计算的新行位置标识一样。这就会导致用户A/B新插入的两行，他们之间的排序结果可能不一致。例如用户A这里可能自己新建的行在前面，而用户B那里可能自己新建的行在前面。要解决这个问题也比较简单，我们只需要稍微调整一下新行位置标识的计算方法。

有很多方式可以解决这个问题，比较简单的一种是，在计算新行位置标识的时候，我们不再使用前后两行位置标识的平均值，而是随机采用前后两行位置标识之间的一个数字，作为新行的位置标识。这样，当用户A/B同时在一个位置插入新行的时候，他们计算出来的新行位置标识仍然是不同的，从而保证了排序的稳定，不会发生排序错乱的情况。

另外，还可以通过服务器给每一个用户一个独立的值，在计算新行位置标识的时候，将这个值加入计算，以确保每一个用户计算出的新行位置都是不同的。

另外，也可以调整排序算法，例如当遇到位置标识相同的行时，就比较他们的id或者内容等，这样也可以确保一个稳定的排序结果，在不同的客户端都是同样的展示结果。

3、一个用户编辑行，一个用户删除行

如果是不同的行，他们之间完全不受影响。

如果是相同行，则通过不同的策略，可以让编辑结果作为最终结果，也可以让删除作为最终结果。通常来说，为了避免数据丢失，可以让编辑结果作为最终结果。

例如当用户A编辑行的时候，用户B删除了这一行。因为删除操作比较简单，通常会直接发送给服务器。服务器执行删除。而用户A收到服务器推送的删除操作的时候，因为A正在编辑这一行，则不进行删除，继续让A编辑，并将A编辑操作发送给服务器。服务器发现A正在编辑一个已经不存在的行的时候，可以重新插入该行数据，确保数据不会丢失。

4、两个用户同时编辑同一行内容

这种情况稍微复杂一点，但是同样，可以通过简单的对比算法，来直接合并两个用户的操作。或者也可以当用户A在编辑某一行的时候，直接锁定该行，禁止其它用户去修改。毕竟，两个人同时修改一行的情况还是很少见的。

通过上述方式，只需要很少的改动，就可以从单人编辑增加到多人实时编辑。而且，本发明不需要服务器很好的性能以及很高的网络速度，大部分操作都是简单的对象增删改，不牵涉复杂的冲突解决问题。因此，本发明可以支持离线编辑。

以上仅是本发明的具体应用范例，对本发明的保护范围不构成任何限制。凡采用等同变换或者等效替换而形成的技术方案，均落在本发明权利保护范围之内。

Claims

1.一种多人编辑文档的方法，其特征在于，将文档分拆成若干个单元，服务器仅对发生了用户操作的单元进行数据更新并推送给其它用户的客户端进行数据更新，包括：

将文档分拆成若干个单元，给每个单元赋予一个唯一标识id、一个位置标识和内容，其中位置标识表示了每个单元在文档中的位置，用浮点数表示位置标识，服务器存储文档时记录每个单元的数据；

其它用户的客户端对相应的单元进行数据更新。

2.根据权利要求1的方法，其中，用户在客户端新增一个单元时，客户端将操作发送给服务器，服务器收到该操作后，新增一条记录并把新增单元的数据写入记录里，再将该操作推送给其它用户的客户端。

3.根据权利要求1的方法，其中，用户在客户端修改或删除已有的单元时，客户端将操作发送给服务器，服务器收到该操作后，通过唯一标识id找到相应的单元，更新或删除记录，再将该操作推送给其它用户的客户端。

4.根据权利要求2的方法，其中，新增单元的位置标识是通过获取新增单元的前后两个单元的位置标识，并计算平均数而得到的。

5.根据权利要求2的方法，其中，随机选取新增单元前后两个单元的位置标识之间的任意数字，作为新增单元的位置标识。

6.根据权利要求1的方法，其中，服务器给每个用户一个独立的值，在计算新增单元的位置标识时，将这个值加入计算，以确保每个用户计算出的新增单元的位置标识都不同。

7.根据权利要求1的方法，其中，当不同用户提交的位置标识相同时，通过比较它们的id或者内容，确定先后顺序。

8.根据权利要求4-7中任一所述的方法，其中，将新增单元的位置标识与其前后两个单元的位置标识进行比较，如果不相同，则使用该值作为新增单元的位置标识；如果与任何一个位置标识相同，则重新调整新增单元前面和/或后面若干个单元的位置标识，以便让新增单元的前后两个单元之间有足够的空间插入一个新增单元，然后根据前后两个单元调整后的位置标识，计算出新增单元的位置标识。