wikipedia_Wikipedia的实时编辑工具

wikipedia

维基百科是世界上最常访问的网站之一。 庞大的在线百科全书，任何人都可以编辑，已经成为有关任何主题的一般信息的首选来源。 但是，维基百科使用的“众包”为旋转和粉饰打开了大门，这些编辑本质上可能不如事实。 为了帮助记者，公民和活动家跟踪这些编辑， TWG （工作组）与Metro News和Investigative Reporting Reporting Center合作建立了WikiWash 。

WikiWash是一个开放源代码工具，任何使用Web浏览器的人都可以观察Wikipedia页面的历史记录，并实时查看编辑内容。 记者已经在使用WikiWash来研究有争议的Wikipedia页面的历史。

构建WikiWash是一个基于Wikipedia的海量数据集的用户友好型应用程序，涉及克服了许多技术难题。 下面，我们详细介绍了针对某些挑战的解决方案，而其他构建基于Wikipedia的软件的挑战可能会有所帮助。

为了促进对项目的开源贡献，WikiWash已用Javascript构建，而Javascript是当今流行的最易访问和灵活的编程语言之一。 还使用了一些Web上最流行的新技术，包括Node.js，Express.js，Angular.js和Socket.IO。

进入Wikipedia的数据库

要获取有关Wikipedia页面历史的数据，WikiWash依赖于Wikipedia的API。 Wikipedia通过其API提供对海量数据库中几乎所有数据的访问，从而使开发人员可以基于数据构建应用程序。 不幸的是，并非所有这些数据都能很快获得。 我们几乎可以立即从Wikipedia中获得许多数据，例如与每个修订版相关的用户名列表和修改时间列表。 但是，每个Wikipedia页面的每个修订的实际内容生成起来都很慢。 要了解为什么会这样，我们需要首先查看Wikipedia的工作方式。

让我们看一下Wikipedia上访问量最大的页面之一，即现任美国总统巴拉克·奥巴马 （ Barack Obama）的页面。 此页面的开头段落是一段易于阅读的文本，链接和符号块：

但是，维基百科以称为“ 维基标记 ”或“ 维基文字”的格式存储此页面（及其数据库中的每个页面）。 上面相应的介绍段在Wikitext中如下所示：

要准备供用户查看的每个页面，Wikipedia必须首先将页面从其数据库中存储的Wikitext转换为HTML（Web浏览器使用的语言）。 由于许多原因，此操作的要求很高：

• Wikitext允许在任何页面中使用动态模板，从而允许在页面中包含其他小页面。 例如，出现在许多Wikipedia页面右侧的“信息框”就是这些模板之一。 必须分别获取每个模板（因为它也是一个可以修改的页面），并使用将要放置的特定页面所提供的信息进行自定义。（在前面提到的Barack Obama页面中，该模板包含591个模板）。本文）。
• 该页面中的每个链接都必须由Wikipedia进行检查，以验证该链接没有损坏，并获取要链接到的页面的名称。 （“巴拉克·奥巴马”页面包含758个其他页面的链接。）
• 参考和引文必须在页面底部进行计算，链接和正确设置格式。 对于许多页面来说，这不是问题，但是许多写得很好的页面都有成百上千的修订版本。 （以巴拉克·奥巴马（Barack Obama）为例，有464条引用。）

考虑到生成每个Wikipedia页面所需的工作量，首先Wikipedia怎么这么快？ 答案很简单：维基百科大量使用了缓存。 编辑后，每个页面都会生成并保存其最新版本。 将来每次有人访问该页面时，Wikipedia都不再需要将页面转换为HTML，而是可以从缓存中提供最新版本。

另一方面，WikiWash则没有这种奢侈。 每次有人使用WikiWash查看页面的历史记录时，Wikipedia都必须将页面的每个版本转换为HTML，因为Wikipedia仅存储每个页面的最新版本的缓存副本。 不幸的是，这会使每个版本的加载时间增加很多秒。

WikiText和Wikipedia上的随机修订样本HTML版本的加载时间。 请注意，将页面呈现为HTML的行为比简单地获取页面的WikiText版本要花费30倍的时间。

为了缓解WikiWash中的此问题，我们实施了一种称为抢先式缓存的策略，以使修订版本的加载速度更快。 当用户在WikiWash中加载页面时，我们首先从Wikipedia请求页面的最新修订版和第二最新版本。 初始加载可能需要三到30秒的时间，具体取决于页面的大小。

阅读页面的第一个修订版后，我们注意到大多数用户都倾向于在几秒钟后单击列表中的下一个修订版。 为了使第二次点击体验更加轻松，WikiWash抢先从Wikipedia加载列表中的每个修订。 当用户单击修订版本时，WikiWash可能会缓存他们已经单击的修订版本。 （我们还关注Wikipedia的API使用指南，以避免在服务器上造成不必要的负载，同时确保流畅的用户体验。）

这种缓存解决方案并非万无一失，因为用户仍必须等待几秒钟才能加载第一页。 但是，在一般情况下，此策略使WikiWash显得响应更快。 幸运的是，所有缓存的数据大部分都是幂等的。 除了包含的模板之外，Wikipedia页面的修订版中的内容永远不会更改。 这意味着我们可以无限期地缓存每个修订版，以加快将来某个特定修订版的所有访问者的页面加载–确实，WikiWash就是这样做的。

显示页面历史记录中的更改

由于WikiWash是Wikipedia的历史浏览器，因此其主要目的是显示页面修订之间的差异。 为此，它使用称为Myer的Diff算法的复杂算法来确定已在页面中添加或删除了哪些文本。 WikiWash并不是从头开始实现算法，而是使用Google的Neil Fraser实现的算法的Javascript端口 。

该算法可以很好地显示多个纯文本文档之间的差异，但是当给定复杂的结构化内容（例如我们从Wikipedia接收HTML）时，其结果将无济于事。 WikiWash插入HTML标签以显示内容上的差异–但是，如果现有HTML标签内出现差异，我们的幼稚过程会将HTML标签插入其他HTML标签内，从而导致无效HTML：

当插入HTML标记以指示HTML中的差异时，生成的文档可能无效。 此处，已删除的文本以红色显示，并由<del>标记包围，而插入的文本则以绿色显示，并由<ins>标记包围。

为了避免出现此问题，WikiWash在处理差异之前先处理HTML，然后处理差异的输出。 在运行算法来确定差异之前，WikiWash将所有HTML标签替换为单个Unicode字符-Unicode私有使用区中保证在Wikipedia文章中不存在的字符 。 之所以可行，是因为diff算法通过查看特定字符来发现差异。 通过用唯一的字符替换每个标签，我们强制算法检测到的每个差异为“全部或全部” –标签已完全更改，或者根本没有更改。

用唯一的Unicode字符替换HTML标签（此处用“ \ xE000”之类的标签表示）可以防止diff算法更改标签内部，从而防止WikiWash生成无效HTML。

在结果输出上运行diff算法后，WikiWash通过将每个Unicode字符替换为其对应HTML标记来解码文本。 结果是HTML现在在语法上是有效的-也就是说，没有标签被破坏。 但是，还有一个问题：生成的文档可能具有不正确的结构。 要了解为什么会出现这种情况，让我们看一下上面的示例，它将其转换回HTML：

中间HTML代码段显示删除了具有类“ class1”的开头“ div”标签，并插入了具有类“ class2”的开头“ div”标签。 但是，由于HTML是分层或基于树的语言，因此此代码段无效。 确实已替换了开头的“ div”标记，但表示此标记的正确方法是将标记的开头和结尾（从开头“ <div”到结尾的“ </ div>”）都包含在区别。 这就是WikiWash所做的–当检测到标签的开始更改时，它将从打开到关闭的过程中找到整个标签，并用插入或删除标签将其包围，如下所示：

此解决方案无法完美运行-即，如果我们从Wikipedia接收到HTML格式错误，或者如果我们从diff算法接收到的差异以意外的方式格式化，则该解决方案将失败。 但是，这种解决方案在我们尝试过的大多数情况下都能解决问题。 （细心的读者可能会建议使用基于树的diff算法来完全解决此问题。不幸的是，此类算法在实践中相当缓慢并且难以实现。）

WikiWash是一个复杂的工具，用于解决一个非常简单的问题-查看Wikipedia（世界上最大，最受欢迎的网站之一）中的更改。 这些只是构建此工具所必须克服的一些技术挑战，我们邀请您在Github上分叉该项目以帮助我们进行改进。

最初发布在工作组博客上 。 通过知识共享重新发布。

翻译自: https://opensource.com/life/14/12/lessons-learned-building-wikiwash

wikipedia