本文中指的纯文本是简单文本，类似Instapaper和Kindle支持的简单格式文本，并非严格意义的无任何格式的文本。

今天下午在看Google App Engine上关于data store部分的文档。Google从web起家，文档也很自然以web方式展现，并且效果很好。不过台式机（甚至包括笔记本）前看东西，不管是coding还是阅读、学习，我都会太久不站起来，这样对身体不怎么好，于是就想把一些文档搬到Kindle上，可以站着看可以稍活动点看，而且屏幕不刺眼。这么一个简单的需求，又引发出了今天的文字：纯文本格式和web格式的区别。

其实Instapaper和Readability类似服务的流行，就是因为人们一直存在这样需求，但是因为环境问题总是没有很好的服务解决这样的问题。现在web应用普及、小尺寸屏幕设备普及、Kindle类纯文本设备普及，让环境发生了改变，文本化web页面内容的需求越来越旺盛。

不过从Readability第一天登上Safari，我就发出了一些“反动”的质疑：组成一个web页面、一个网站（一系列web页面）的元素有文字的内容，行文的风格，还有挺重要一部分是web的样式；文本在偏左还是偏右、页面背景是暗色系还是亮色系、链接是蓝色还是红色、广告是横躺还是侧立，等等一系列因素，都是web内容的重要组成部分。可以稍微夸张但话糙理不糙地说：如果看不到一个页面的标题图案、背景样式、字体设置这些，我会失去对正在阅读的这个网站的长久以来积累信任感。

今天的发现，依旧和上面有些类似，结论是并非所有web内容适合文本化。可以说web文本和纯文本之间的差异有表面和内在两方面，大部分差异都有更深层次差异，这些差异都是难以逾越的，尤其是在web普及之后。

• 如前所说，一个网站的文章或信息，其布局、配色，等等样式，向读者传递的是隐形和潜移默化的信息。对于一个样式、风格不那么经常变化并且达到了正常审美标准，那么它将渐渐地在读者脑中建立起内容类别、行文风格、可信度等等抽象信息与页面样式之间的联系。也就是说读者会日积月累行程“以样式判断内容”的习惯。这是纯文本格式无法替代的。

• web文字还有超链接、JavaScript等和纯文本之间的功能差异。假设对于一篇wikipedia上的词条来说，有可能将其纯文本化，并且结果看似并不影响阅读，但即便如此，还是有可能有深层的被”漏转”的要素。比如，在2011年一位维基人在撰写维基词条，他脑中对读者的认知，和对十年前读者的认知是不同的：2011年比较十年前几乎人人都知道了维基百科是什么，知道词条里出现的概念和名词可以是另一个词条，也就是超链接在词条里的作用。当他假设所有人都明了超链接时，他有可能写出的词条不会稍微解释或者足量地解释某个概念，他明白读者不明白的话会自己点开超链接。所以，即便是撰写文字，有某样功能和没有某样功能，有可能有完全不同的效果。

• 今天最初的例子Life of a Datastore Write，这里含有很多“微格式”，比如代码、旁注、夹杂在正文中的变量名、多种格式的复杂列表…… 这些项目一方面技术上难以无损转为纯文本格式，另外更深层来看，则是web灵活便捷的格式变换与作者表达概念间混合，这更加造成了web格式和纯文本格式之间基本不可能无损转换。还举个简单例子，比如Life of a Datastore Write中，“夹杂在正文中的变量名”相对正文文字，将字体颜色变为绿色，字体风格变为等宽字体；如此一来，在纯文本阅读环境，要么去除格式消灭了这种格式表示的意义，要么换成另外一种简单纯文本格式支持的方式，哪怕是用文字标注”<变量>变量>”。显而易见，这种方式是效果是一站内的，如果IBM网站用蓝色和有衬线字体做正文中的变量名这个类别的样式，那就不得不更换转换方式了。

上面零零碎碎说了些对web富文本格式和简单的近纯文本格式的差别的思考。我认为的最终结论是：对于小说、散文等当今和50年前载体几乎没什么差别的文体，使用纯文本以及和其他格式互相转换，是没有问题的，除此以外的文体，尤其是当今的web页面的内容，稍有复杂的功能和格式，都是不适宜进行纯文本阅读的，不适宜度随着web格式复杂度升高而升高。于是，结论的扩展就包含了，如果常看、长看web内容的话，7-10寸的有极佳web browser的tablet才是王道，唯一缺憾就是LCD和用眼时间的矛盾了。