微格式（microformat）让一些人感到非常兴奋，又让一些人深感困惑，这取决于你对它了解多少。我必须承认，当一年前后人们首次开始谈及微格式的时候，我没有完全理解这个重要事物。初次看到hCard微格式，它给我留下的印象就是大量的额外标记，也就是大量的<span>和< div>标签，没有什么别的额外收获。但是，跟其他很多人一样，我最终开始了解到它们所蕴含的巨大潜力以及它们的广泛用途。如果你还是以一种怀疑的眼光来看待微格式的话，我希望在读完本节内容之后，能够改变你的看法。
首先，什么是微格式？问得好，让我们先来看看microformats.org为微格式所下的定义，它将微格式描述为“建立在已有的、被广泛采用的标准基础之上的一组简单的、开放的数据格式”。microformats-discuss邮件列表（microformats.org/discuss/）则给出了另一个定义：微格式是为了把语义嵌入到HTML以便有助于分离式开发而制定的一些简单约定。
这些定义到底是什么意思呢？它们的意思实际上就是，按照某种标准方式标记出内容块，可以让外部应用程序、聚集程序和搜索引擎能够做以下的事情：
● 在爬取网站的时候能够识别内容的语义。
● 对内容进行操作，包括提供访问、校对，还可以将其转化成其他的相关格式，提供给外部的程序和Web服务使用。
为了防止描述过于抽象，我们还是来看看一些示例。举例来说，前面曾经提到过hCard微格式。后面我们将进一步深入地讨论它，但现在只需要知道，它是一种使用标准化类别名来标记已有网上联系信息的方式，可方便地将联系信息转化成vCard格式（一种可跨平台的电子商务名片）或者让那些专门用来搜索联系信息的搜索引擎提取这些信息。
还有一个示例就是XFN微格式。XFN表示的是“XHTML Friends Network”，它使用超链接中的rel属性来描述你与所链接到的那个人之间的关系，可以根据该信息来建立自动生成社会网络（automatically generated social network）。
微格式就是一种利用已有标准来解决碰到的问题的方法。对于hCard而言，它要解决的问题是没有一种标准的方法能够格式化网页上的联系信息或者从网页中提取联系信息；而对于XFN而言，它要解决的问题是没有一种标准的方法能够按语义表达链接者和被链接者之间的关系。初看起来，它们似乎非常不雅观。实际上，我所听过的最常见的抱怨是，由于它们大量使用了一般性元素，很明显与我们现在正在努力编写简洁的、语义丰富的标记背道而驰。我能够理解这种抱怨，这是因为我第一次看到hCard的时候也正是这样认为的。
但是，其实没有必要这样抱怨。有些微格式制作指导原则指出，应该尽可能使用最适当的(X)HTML语义性元素。如果没有这样的元素，那么就应该改用最适当的结构性元素，可以用<div>或者<span>，但也可以是<address>、<li>，甚至可以是< td>，这取决于具体的使用环境。在微格式的一些具体实现中，人们确实往往偏爱<span>，但我不认为这就像它最初看起来的那么糟糕。避免滥用一般性元素是一件好事，在这个示例中，这个标签的用法就具有语义性；它被赋予了一定的语义意义，而这个意义在上下文中非常明显。此外，使用微格式，就可不必再使用表示性标记（比如<br/>），这样一来页面尺寸可以变得更小。
是否应该对微格式感到兴奋呢？我非常坚定地认为它们具备非常大的潜力，而且使用的人越多，就越有利：可用的数据就更加丰富，范围更加广泛，而且能够利用微格式的工具也将会更好地整合起来，可用的工具也更多。除了Technorati之外，还有一些大型网站（比如Upcoming.org，还有Yahoo!旗下的各种网站）也已经在广泛使用微格式。我们甚至还会看到微软加入进来，2006年3月比尔·盖茨说到，“我们需要微格式，还要让人们就其达成一致。它可以加速 Web数据交换……我们需要微格式来组织联系人名片、事件、指示……”（www.youtube.com/watch?v=Z9X-vHJ_Z-I）。是否有一天我们会看到微格式数据无缝地集成到Windows和IE呢？
现在来看看一些已具备完整规范的微格式：hCard、hCalendar、XOXO、XFN、VoteLinks和3个“rel-”微格式：rel- license、rel-nofollow和rel-tag。我还将展示hReview（尽管此时还处于草案阶段），因为它已经用在了高端网站中（比如 Yahoo! Tech在使用它），因此到它最终标准化之前不大可能出现较大的变动。到本书出版的时候，一些目前尚处于草案阶段的格式毫无疑问会最终标准化，因此有关这些微格式的最新消息，请到microformats.org网站查看。
首先，让我们来看看hCard微格式