为什么维基百科的内容要使用代码格式编写?

不知道我形容问题的方式是否正确,但我想明白相比百度百科可视化性比较好且容易理解的情况下,wikipedia的这种编写方式有什么其它的好处?
关注者
43
被浏览
17,277

3 个回答

首先我必须得指出这个问题本身就是有些偏颇的

  1. 维基百科并非只支持源码编辑(MediaWiki亦然)
  2. 维基百科并非不建议使用VE(针对 @柳玉 的回答)

我想从VE(可视化编辑器)和源码编辑器的工作原理出发来补充一下:

什么是可视化编辑器

我们在90%的网络产品中看到的编辑器都是VE(可视化编辑器,下同),比如之前很流行的博客,以及现在随处可见的百度百科,微博,当然还有我们现在正在用的知乎。VE的本质就是一个只能从限定的预设样式里做选择进行排版的html编辑工具

以知乎的VE为例,“B” 实际上就是为文字加一个 font-weigt:bold


类似的I、H都是常见的预设style。

这时候如果你想定义一个不在上述预设style里的样式,例如color:#333,vertical-align:top等等基本上就不可能了(当然也许可以直接从剪贴板里带一些样式进来)

为什么所有网络产品都会先从VE入手甚至只支持VE,无外乎两个原因

  1. 易用,毕竟不是所有人都懂HTML+CSS
  2. 安全,过滤掉了很多不安全的代码,这里安全包括两层含义,一层是攸关security的“安全”,当然这个是很底层的东西,一般即使是源码编辑也会做预筛(等下还会说),另一层是“浏览器体验的安全”,也就是通俗的“美观”,或者说前端表现良好。用户能够输入内容的样式始终处在一个开发者给你划好的圈子里,大体是可控的,这样不会出现覆盖站点皮肤样式,在多终端设备上出格或者浏览器样式不兼容等等情况出现

可视化编辑器与源码编辑器并轨

普通的产品对VE和源码编辑器做并轨并不难,因为大部分产品的源码编辑器中只涉及到html样式,这时VE是源码的一个子集,源码是HTML的子集,只需要让VE里的东西“显出本来面目”即可转换到源码。同时将源码里的样式按照html规则渲染出来到VE里就完成了并轨。

但MediaWiki棘手的地方就在于他的源码编辑器里并不是只有HTML,还包括大量控制运算逻辑的标记语言(wikitext,一种轻量级的Markup语言),这一块之前两位回答的表述不是特别的准确,我再多啰嗦几句:

MediaWiki的源码编辑器大体相当于是HTML编辑器和wikitext标记语言的并集,其中HTML部分除了因为上述安全原因过滤掉了一部分容易被注入的高危代码,譬如<a><img>标签,其他大部分的HTML标签都可以直接在源码编辑器书写,例如


这里绿色部分全是html语法,当然这部分内容也可以用wikitext书写 因为wikitext中的样式控制部分本质是一种html语言的简化写法, 例如 '''TEXT''' 的本质就是<span style="font-weight:bold;">TEXT</span> 你直接在源码编辑器写<span style="font-weight:bold;">TEXT</span>也是ok的,甚至还可以自己加一些其他的属性,比如class=,id=等等

而标记语言中除了样式控制部分(实际上和html功能重合),另一大主体就是逻辑运算,而逻辑运算功能里最突出的就是“模板”(template),MediaWiki的模板是一种类似子程的块状机制,可以控制参数、变量、样式、逻辑并可以层层嵌套。也就是说模板完全是个“X因素”,里面什么都会有,这时候要把wikitext还原成VE里的元素,就需要写一个很长很长的Parser(即一坨又一坨的正则表达式)

如果parser写不好,写不完备,就会造成源码内容转入VE后失败甚至丢失,如果VE和源码不能并轨,从产品角度就必须有所取舍,二选其一。

90%的网络产品和大部分的维基软件(包括confluence以及百度百科)会选择放弃源码


而源码恰恰是MediaWiki最不能放弃的东西

如同前二位所说,这种自由、高校的标记语言和模板恰是MediaWiki强大的功能灵魂所在也是维基文化的精神内核使然,所以理所当然的,VE成为了被“暂时”放弃的那一个

MediaWiki从未忘记过可视化编辑器

如果你是一个关心MediaWiki软件的开发者,那么可以很明显的感受到MediaWiki团队对于VE的执着,

这是媒体基金会MediaWiki项目开发团队自2012年以来启动的对VE升级的七个阶段,实际上这部分规划在2010年就已经提上日程了

之所以花了这么久的原因我上文第二部分也解释了一些,:

  1. MediaWiki的VE必须与源码并轨,而MediaWiki的源码编辑器恰恰是非常复杂的
  2. MediaWiki所使用的标记语言和模板机制充满变数,parser很难写完备
  3. MediaWiki和百度百科这种“伪维基”的最大区别某种意义上来说不在内容本身而是底层开发机制,特别是MediaWiki的开放性,MediaWiki是开源的,支持插件扩展,这就带来了更多的变数。

就是在MediaWiki的源码功能不断复杂化、不降低标准的前提下,VE还要追赶源码的开发,才导致了MediaWiki的VE在面世之初非常难用,渐渐给了人“维基没有可视化”的错觉。

实际上真正了解MediaWiki底层开发机制的话,就能够去包容MediaWiki一坨的VE了

MediaWiki VE最尴尬的地方就在于,他看似很简单,但是对于新手还不够简单,看似很努力的在进步,但是对于会写wikitext的开发者而言又如同鸡肋。如同评论中 @nbfreeh 提到的那样,大部分会写模板的用户从来不用VE(包括我),我只有在处理表格的时候才会用VE(同 @陈肖恩

但MediaWiki的VE的确在不断进步,说到这一点很有趣,因为我基本不用VE,所以几个版本的更新对我而言基本上是没有的,但是我们之前在ga上对灰机wiki新注册用户的行为习惯做了一系列的操作行为记录和数据收集,后来发现,从2015年到现在,新注册并有编辑行为的用户选择使用VE的比例在逐月提升(我稍后会补图,今天ga上不去)。所以有时候资深的维基使用者应该换个角度,站在从没用过MediaWiki的用户的立场上去看问题,毕竟在国内,这些人是绝对多数,大部分人第一次接触MediaWiki时,还是会选择使用VE。

以及,MediaWiki的可视化编辑器现在已经很好用了,几乎每个版本都有质的飞升,类似google doc的多人实时协作功能也在开发之中。我不知道中文维基百科是怎样,英文wikipedia点开编辑都是强烈推荐和引导用户使用Visual Editor(可视化)

同样的源码编辑器也要迎来大更新,1.29正在beta的源码编辑器从UI上看起来已经和VE没有太大区别了。

P.S.MediaWiki的开发团队真是太赞了,笔芯

首先wikipedia的编辑器也是跟着时代进步的。

其次,wikipedia在创建之初为什么选用代码进行编辑,是有多种原因的,一是当时富文本编辑器并不是太好用。二开通富文本编辑器会占用更多的资源,我们都知道wikipedia是非盈利的资金是有限的。

其实wikipedia的个人设置当中是有富文本编辑器的实验功能,只不过默认没有开起。

同时wikipedia本身是一本百科全书,更多的是为是展示文本排版,如果使用富文本编辑器 在当时来说并不好用的情况下只会分心编辑。

而Wiki语法学习简单,可以快速上手,markdown实际上很大程序上可以看作是Wiki语法的进化形。

那为什么要创建Wiki语法呐?

这个(๑°3°๑)我忘记了,但wikipedia上是有说明的。

其实wikipedia的一个条目很多就是一个、几个段落,几堆文字,使用Wiki语法可以很自然就排版好,但如果使用编辑器去排版,反而会上去更多的分心给文本的美化上,进而使你对条目本身价值转向,这有违了WIKI的初衷。

当然随着时代的进步,同类产品的诞生,wikipedia也在进步,但始终还保持着内容为本的原则,不同于度娘百科等更多的是商业价值的考量,虽然不可否认其在知识的普及上歪果仁本土化,但其中所隐藏的黑暗也不可忽视。

同时度娘百科之类的主要编辑成员更多的是企业本身的编辑团队与采集器,尤其是在某些特殊条目上更是‘精心’维护,与wikipedia不同的是需要更丰富的内容展示,所以才需要更多功能的编辑器。

所以为什么wikipedia不建议使用富文本编辑器的原因便还有些,,因为两者所走的路不同,所以需求也不同。