Wiki你长的为何与众不同--对Wiki独创写作语法原因的思考

    Wiki虽然早出现于上个世纪九十年代中期, 但逐渐兴起也就是近几年的事情. 随着维基百科的成功, wiki走入人们的视野, 越来越多的人加入了探索wiki成功应用的模式行列. wiki这种形式怎样才能让大众接受, 这是个必须面对的问题, 在实际应用过程中往往卡住人们步入wiki大门的第一道障碍就是其特殊的写作语法.

 

    相较于人们广泛熟悉的文档管理系统(如BBS, Blog)的写作方式而言wiki的写作语法与众不同, 要想写作必须先学习一番, 人的本性即懒, 即使再简单的东西要让一个人去学习也是很困难的. 同样是文档信息发布, 人们总会在脑海中拿如BBS, Blog这些相似的影子来做对比, 以往的经验无法应用于wiki写作, 于是很失望.

 

    这引起了一些思考, wiki的写作语法为何与众不同呢? 这是一种更先进的技术么? Wiki为什么没有像BBS, Blog一样选择html做为写作语法呢?

 

    先看看wiki用了什么样的写作语法, 在众多已经实现的wiki引擎中写作语法虽然各有千秋, 但本质一样, 均是通过结构化文本来写作. 结构化文本最大的优点就是便于程序处理, 如检索, 重构输出等. 这样的格式对于wiki引擎的处理是非常有利的, 但对于已经习惯了所见即所得html写作方式的普通用户来说, 这是一个反传统的东西.

 

    再看看html, 无论我们现在怎样诟病html, 但都不得不承认html的所见即所得技术是目前最好的Web写作用户体验方式. 这项技术发展了10多年了已经很成熟了, 即便他不能面面俱到, 但这丝毫不会影响用户对他的喜爱. BBS与Blog见证了这点.

 

    那么Wiki为何没有使用html从而能利用成熟的html所见即所得技术呢? 我从多方面寻找到了一些解答. 有的说Html不安全, 但完全可以通过程序过滤有潜在危险的html标签. 也有的说html所见即所得技术表现力不完全, 但普通用户写文章, 发帖子谁会经常用到那些所见即所得功能无法触及的地方. 所以这些答案都不尽如人意, 没有很充分的理由说明为何非使用这样的结构化文本不可, 都是很轻易的就能找到驳斥的理由.

 

    这不得不让我怀疑这是历史问题. 于是我做了这样的猜测. Wiki早诞生于1995年, 互联网络刚起步没多久的时候, html的所见即所得技术那时非常简陋. 在没有所见即所得技术支撑下的html用于Web写作是一件十分痛苦的事情, 因此wiki的创造者选择了既容易被程序解读又简单的结构化文本, 然后用程序将结构化文本转换为html输出到web, 这样的方式在当时对于用户来说的确比徒手用html写作强了千百倍. 而wiki在创作当初目的就是为了开发团队的文档交流, 所以对于一个专业的技术团队, 再怎么样的新技术在团队内推行也不为过, 更何况结构化文本的语法简单易学. 在当时, 可以说是一个非常先进的技术, 但随着互联网络突飞猛进的发展, html相关技术也有了日新月异的变化, html所见即所得技术逐步成熟后, 便可以直接用html来写作了, 而且方便的很, wiki呢这些年一直进步缓慢, 直到维基百科点了一把火, wiki才为世人所知, 如同从时空隧道走到了现在, 看着当年丑陋的html老哥批上了华丽所见即所得外衣, 而自己还在裸奔, 羞愧中想到了发展结构化文本的所见即所得技术好为自己先穿上个内裤. 但结果并不理想, 问题多多, 最终绕个圈还要输出成html格式.

 

    在思考此问题的过程中, 我更多的认为这是一个历史造成的问题, 而不是一个更好的解决方案. 我认同的方式则是wiki引擎与现有的html的所见即所得技术结合, 稍加改进, 使其支持内部的wiki引用, 而对文档格式重构方面有要求的可以使用docbook方式来写作, 对于普通于特殊用户能达到两全其美的效果. 由于了解有限, 或许我的观点是错误的, 也可能wiki使用这样的语法另有深意, 欢迎各位指正批评.

附表：

	20世纪90年代		2003年后
	写作方式	WYSIWYG	写作方式	WYSIWYG	程序解析	检索	重构	安全性
Wiki	较方便	无	较方便	不成熟	方便	方便	方便	安全
Html	非常复杂	不成熟	非常方便	非常成熟	较麻烦	较麻烦	很难	不安全
UBB	较方便	不成熟	非常方便	非常成熟	较麻烦	较麻烦	很难	安全
DocBook	—	—	非常复杂	不成熟	方便	方便	方便	安全

转载请注明出处: http://simonw.cnblogs.com/ by simonw