Openvatar 你怎么不觉悟？

Openvatar 是一家刚刚上线的头像托管服务，支持 OpenID 登录。用户将头像上传到 Openvatar 的服务器上，然后使用 avatar.php 进行调用：

http://www.openvatar.com/avatar.php
?openvatar_id=9b2894b2fa12ea24c455f4be9331d3fe
&size=50
&default="http://www.mysite.com/avatar.jpg

博客们最早广泛的接受头像始于 Gravatar ，他们用邮件地址作为用户 ID ，通过插件来实现头像调用，支持的平台相当广泛。内部 Gravatar 和 Openvatar 的调用语法十分相似（几乎一模一样）， avatar id 也是一个 MD5 的邮件地址，同时还有一样的 size 和 default 属性。

随后 Gravatar 经历了一段长时间的掉线，使我们逐渐放弃它，并开始思考分布式（就像 OpenID 一样）的存储方式。 Pavatar 由此诞生。简单的说， Pavatar 更像一种规范而非服务。它用三种方式规定头像文件的位置。

1. 修改 HTTP 头增加 X-Pavatar 属性；
2. 在 HTML 头增加 标签
   <link rel="pavatar" href="http://example.com/path/my-pavatar.png" />；
3. 类似 favicon.ico 标准，将 pavatar.png 放置在 URL 根目录。

很快，第二名称也推出个人网络图标，而将头像加入 OpenID 协议的讨论也在社区中轰轰烈烈的进行了一段时间，但很快，我们发现这样做显得如此的多余。 Gravatar 因为将某种公开而微小的信息（头像）加密并集中存储而显得多余， Pavatar 则在现有的标准身边尝试创造新标准而显得多余。

是的，这个现有的标准就是 Microformats 。头像和诸如姓名、地址等个人信息一样，是开放的、可见的，因此一开始， hCard 就包含了 class=photo 的定义。在 OpenID （或者任何 URL 标识）应用端看来，使用 avatar 的过程十分简单：

1. 连接 OpenID URL 寻找 hCard 段，如果有 photo 字节，使用其提供的头像地址；
2. 如果没有 photo 或者没有 hCard ，那么在 OpenID URL 根目录寻找 avatar.png （这一步涉及到创立一种新规范及其他很多问题，不推荐但也并非不可行）；
3. 没有发现任何头像信息，则使用内置的缺省头像。

整个过程很干净，应该说是目前头像应用比较完美的解决了，有兴趣的朋友可以看一下Wordpress 的 hAvatar 插件。

回头再看一看 Openvatar 的发布，一下把人拉回到 Gravatar 时代，就算跟 OpenID 扯上那么一点关系，也不能太缺乏觉悟吧。