代码之家  ›  专栏  ›  技术社区  ›  LiraNuna

javascript中两个字符串的网络效率差异

  •  3
  • LiraNuna  · 技术社区  · 15 年前

    我有一个Web应用程序,其中客户端编辑器正在编辑服务器端已知的真正大的文本。

    客户机可以对此文本进行任何类型的修改。

    最重要的是什么 网络效率 如何以服务器理解的方式传输结果差异?另外,由于这将发生在客户端(javascript),我也希望它“快”(或者至少不会明显慢)

    一些场景:

    • 用户修改一个字符
    • 用户在随机位置修改多个句子
    • 用户删除所有内容并生成空白文本。

    我不能使用类似diff的语法,因为它不是网络效率,它检查行,其中示例1和3将产生可怕的差异(尤其是最后一个,结果将超过旧的本身)。

    有人在这方面有经验吗?用户操作一组非常大的数据——大约3-5MB的文本,上传整个“新”内容是一大禁忌。

    明确地说,我在寻找传输的“协议”,字符串比较不是问题。

    5 回复  |  直到 15 年前
        1
  •  3
  •   brianpeiris    15 年前

    我不太熟悉这个主题,但是我可以向您指出一个开源(ApacheLicense2.0)项目,它可能非常有用。

    它是一个diff、match和patch库,用多种语言编写,包括来自Google工程师的javascript,并在多个在线协作编辑服务中使用。

    以下是资源列表:

        2
  •  1
  •   Brian Campbell Dennis Williamson    15 年前

    一个简单的方法,假设您知道服务器上的副本不会改变,只需发送一个编辑列表(删除和添加),其中删除部分表示为开始和结束索引,添加部分表示为开始索引,文本表示为插入。

    如果您有不止一个简单的diff算法(我不确定您所说的“字符串比较不是问题”),您还可以检测移动或复制的文本块,并将其作为移动或复制的文本块的开始和结束索引发送,以及插入的目的地。

    请注意,您需要确保跟踪您的索引是指原始文档还是迄今为止编辑的文档。避免此问题的一个简单方法是始终从文档结尾到开头执行编辑;然后早期编辑不会影响后期编辑指定的偏移量。

    有关这种方法的示例,请参见 ed 格式化 diff -e 输出。这基本上是可以输入到 ed line-oriented text editor . 如果您希望发送绝对最小的差异,您可能希望执行基于字符的索引,而不是基于行的索引,但相同的基本方法可以工作。

        3
  •  1
  •   Alex Martelli    15 年前

    用户执行的任何编辑都可以有效地分解为:从x中删除长度y;在x处插入文本“whatever”。x和y是从文本开始的字符偏移量;y是字符数;“whatever”是任何字符串。你说你不需要帮助计算差异,但是一个例子是 here ,只是它的输出比您需要的要丰富,但是它确实标识了“删除和插入”,所以,只需更改输出部分。

    可以调整将数据发送到服务器的确切格式,但我认为这样做没有多大的好处--在等待测量之前,我会先将命令发送为D表示删除,I表示插入,数字以十进制表示,插入的字符串以引号形式表示。一旦您对正在执行的实际传输有了一些统计,您就可以看到数字(十进制与二进制)和引号中的开销有多大,但我怀疑这并不是所有有意义的(如果事实证明是这样的话,您可以尝试各种方法,例如从最新的插入或删除点进行偏移,而不是总是这样从一开始,使事情更快)。

    您可以每隔几秒钟对用户正在做的事情进行一次采样,然后在过去几秒钟(如果有的话)内发送增量更改——这样,您发送的每个数据包都将很小,如果网络连接或用户的计算机/浏览器崩溃,用户不会损失太多工作。

        4
  •  0
  •   James Black    15 年前

    您可以每500毫秒发送一次更改,因此,在最后500毫秒中所做的任何更改都将被发送,但只有在发生更改时才发送数据。

    在这种情况下,您可以发送已更改单词的位置,然后只发送整个单词,但我希望该位置位于文本的前面。

    它不会有几个句子的价值,但是可能会有几个单词,但是,如果你按顺序发送它们,那么结果应该是一致的。

        5
  •  0
  •   Kev    15 年前

    因为有很多方法可以进行编辑——即使是在500毫秒这样的短时间内——包括 拖放或剪切和粘贴文档内或文档外的大段文本 --我不知道是否会有什么东西可以很好地覆盖所有的场景。从表面上看,这当然不是对您问题的回答,但我会仔细考虑与更改界面以限制文本大小和将现有文本拆分为小块相比,开发和维护类似内容的困难。

    也许在你的情况下这是不可能的,但如果是的话,我想最终用这种方式避开这个问题并在编辑后发送完整的文档会省去很多麻烦。