p;除非自己也瞎了，否则就意识不到世界上还有盲人；除非盲人也是客户，否则就不考虑他们的需求。合法、合理，就是不合情。
“你们这个系统用的数据库是什么？”范含问。
“我不懂啦！”笑着回答，“技术问题我一窍不通。”
“没有数据库。”旁边有一位“阿姨”回答，“每张卡片就是一个文件。”
范含扭头，看到旁边一台终端前面，那位阿姨正在输入什么。
本来以为就是htl那样的一堆尖括号，走过去一看，不是。正常文本之间有一堆奇怪的符号和各种控制字符。也对，这时候htl还没出现呢。
每本书都有唯一的书号，所以可以存成一个文件，以后再也不用修改，范含想。存储作者和出版社的文件可能会时常更新，添加内容。这么一来，这套系统就像是一个网站的布局那样。
维护这些文件和维护数据库，哪个更烦？对于这些管理员来说，维护文件应该和原来维护卡片有点像，恐怕更容易接受一点。这样一来，还可以省下购买数据库系统的大笔经费。在当前数据库系统还十分昂贵的情况下，这么干也还说得过去。
“这个系统是从ib那里买的？”范含又问，这个问题才重要。
“不是，”那位阿姨回答，“这本来是布朗大学的一个项目，我们学校有人和他们合作。”
仔细一打听，uc电子工程专业的一帮人挑头引进了这套系统。
以前自己怎么把他们忽略了？范含很后悔。
由于s项目的原因，一直以来，自己在uc都是只和数学系打交道，和这些真正能造计算机的人反而没有来往。当然的，他们干点什么也没必要非得通知自己一声。
失策，真是失策。
回家路上，范含拼命搜索
o，关键字是“布朗大学”。
世界上第一个实用的超文本系统是美国布朗大学在1967年为研究及教学开发的“超文本编辑系统”。之后，布朗大学于1968年又开发了第二个超文本系统“文件检索编辑系统ress”。这两个早期的系统已经具备了基本的超文本特性：链接、跳转等等，不过用户界面都是文字式的。
所谓超文本，就是电子文档的一种，其中的文字包含有可以链接到其他字段或者文档的超文本链接，允许从当前阅读位置直接切换到超文本链接所指向的文字。“超文本”这个词在英语词典上并不存在，是美国人泰得纳尔逊于1965年杜撰的。
由于几乎每篇论文后面都会引用一大堆其他论文，如果按照顺序一篇一篇的找，确实没有直接跳转过去方便。这类系统从诞生之日起，就有它存在的必要。布朗大学的一干人等正是正视了这个需求，才开发了这个系统。
看来历史在这里有个小小的转折，uc里面这些被范含冷落的未来的电子工程师们，面对数学系的同学和for合作边写论文边打工，名利双收的局面，终于不堪平庸，奋发图强，努力证实自己的价值。
嗯！证实的好！范含想，让我知道了这个消息，也算没白来一趟。
既然这个系统不是自己想象中的那个数据库应用，说明情况还不算太坏。并且这个系统并不是ib开发的，说明ib的思想还没那么前卫。不过，这个系统已经成功运行在ibsyste360上这件事本身，说明迟早有一天ib会开始开发类似系统。
自己一定要抓紧。
只要一提到“超文本”，范含立刻就会联想到“超文本链接语言”。这种语言几乎是钦定的描述“超文本”的工具。最明显的特征就是那个“下划线”。
以前总觉得采用添加下划线来表示超文本的方式天经地义，今天亲眼目睹了这样一个早期系统，终于感觉到前辈们决定采用这种方式的无可奈何与理所当然。
那些“后世图形界面浏览器”里面的文字，都是和其他图形界面程序一样，是画出来的。反正画什么也是画，所以随便改字体也无所谓。但是对于字符终端而言，每个字符都采用事先烧入ro里面的等宽点阵字体，直接拍在屏幕上。在这种情况下，就算是同一种字体族，仅仅采用粗体或斜体，实际上都需要更改点阵，肯定会涉及到字符位置的重新计算。相比之下，字体不变而改换颜色反而更容易一些。但是目前最通用的是单色终端，并且这种系统的设计从一开始就决定了不能依赖颜色。于是，下划线几乎是唯一可能的解决方案。每打出一个字符，在下面多一条线，还是可以轻松办到的。
这些事实都在提醒范含，尽快设计htl，规范化超文本的表现形式，利人利己。
不过……htl由于历史的原因，设计的太随意了些。这种随意曾经让范含吃尽了苦头。
以前范含搜集资料的时候，遇到了一个“国学网”，里面都是各种国学古籍。曾经兴高采烈的从网页上面复制文字，存成文本。但是打开一看，每行后面都多了一个字。基本上就是“知”、“古”、“斋”、“主”四个字轮换使用。仔细分析网页源代码，发现这个多余的字的确是原来就有，只不过颜色设置和背景色相同，在浏览器中看不出来而已。
对于这样做的动机，范含是可以理解的。毕竟辛辛苦苦做成网页，不希望其他竞争站点原封不动拿走就用。但是对于这种手段，范含是不支持的。毕竟这些古籍的著作权属于死人，版权不属于任何活人。要么您就别贴出来，要么您就贴图，像现在这么干，只会给一些查找资料的人制造困难。
况且这类手段别说难不住“竞争站点”，甚至难不住范含这厮。范含把所有网页下载完毕之后，专门用erl写了个脚本，读入网页，输出文本，顺便除掉中间的这些垃圾。
写脚本的时候就意识到了htl的不规范所带来的麻烦。
首先，标签关键字不区分大小写。处理这个就很费劲。
其次，许多标签可以闭合，也可以不闭合。比如表示段落的“”，可以单独出现，也可以和结束标签“”成对出现。处理这个也很费劲。
再次，标签属性值的引号可用可不用。比如“lor=”red””，也可以写成“lor=red”。处理这个最费劲。
还有其他许多地方需要范含费劲，虱子多了不咬，债多了不愁，至于那些地方到底是哪些地方，现在的范含大人大量……已经忘了。
这还是自己专门针对一套模板做出来的网页写分析程序，已经痛不欲生。对于专门写浏览器，必须分析所有可能的htl格式的那些家伙们，郁闷到何等地步应该是可以想象的。
所以到了后来，xhtl标准出现，范含几乎是举双手双脚赞成，巴不得全天下的页面都是如此规范。
所谓“xhtl”，其实就是用xl语法规范化的htl，每个xhtl文件都是一个标准的xl文件。处理这样的文件当然会很轻松。
范含最欣赏xl的地方，就是它很“规范”。上面提到的那些htl的缺陷，xl一概没有。
比如大小写问题，xl是区分的。这个就有它的必然原因……在unide里面处理大小写，实在是太他妈的的烦了！
不说阿拉伯文没有大小写。不说东亚的象形文字、也不说泰文、梵文、希腊文、俄文字母。就是采用拉丁字母的语言，除了英语、意大利语这类不采用重音符号的文字之外，都会很烦。
比如德文，大写字母29个，小写字母30个。多出来的那个小写字母，形状类似希腊文的beta，实际上是“ss”的合写。这个字母不会出现在字头，也就没有大写形式，一旦需要大写……比如文章标题全部字母大写的情况……就必须用“ss”两个字母代替。
总之，对于xl这种主要是让程序来阅读的文件，语法规则越简单越规范越好。其实htl不也是让浏览器用的么？理论上最终用户没有必要非得阅页的源代码呀！那为什么当初要设计成这样？！
范含早就在幻想，如果时光能倒流，自己一定会仔细设计htl规范，以便造福无数“后世程序员”。现在真的回来了，自然是打算兑现诺言。
不如一上来就直接推出xl吧，然后派生出一个htl的子集，这样以后干什么都好说。
可是……这个xl也不是凭空出现的，而是另一个更大更复杂的sgl的子集。
这个sgl，是历史上的ib从1969年开始制定的。
又是ib？！
我日你先人的板板！！
第贰拾壹章 太监们 （上）[2/2页]