这一篇来自微格的维基网站hCard 1.0,从2010/04/29翻到今天才算翻完,ㄚ琪自觉翻得不好,因为对这个新的技术还不是很熟,所以朋友对这篇翻译有建议,尚请留言给我!

以下是转贴自该维基的页面翻译:

hCard是一种用来表现人、公司、组织及地点的简单、开放、分布式的格式,它在语义的HTML或XHTML使用vCard (RFC2426)以1:1实现,hCard是几个适合嵌入HTML、XHTML、Atom、RSS跟任意的XML文件的开放标准之一。

想要开始写一个hCard吗? 使用hCard产生器来写一些联络资料然后发布,或是照着hCard创作技巧来新增hCard标记到你目前的联络页面。

编辑
Tantek Celik (http://tantek.com/,之前在Technorati, Inc.服务,现在于Microsoft Corporation服务)
作者:Tantek Celik (背景同上)
Brian Suda (http://suda.co.uk/)
致谢: 见 致谢

版权专利声明的申请。

状态

hCard 1.0是一个microformats.org的规格,hCard公开讨论在hcard-feedback、irc.freenode.net上的#microformats irc频道跟microformats-discuss邮件列表

可用语言

这个规格的英文版本是唯一正式的版本,文件的翻译见翻译这节。

错误及更新

这个规格已知的错误及问题在解决结案这里被修正,在报告问题前请先检查那里。

hCard 1.0.1更新正在开发并且已知的错误也会结合进来修正,还有值类模式

前言

vCard标准(RFC2426),和hCard的互相操作性已广泛地实作(例如Apple的”Address Book”应用程式已内建于MacOSX)。

此外,很多部落客会用名字来识别自己并且跟他们的朋友及家人讨论,只需一点点的结构,部落客可以用这样一种方式在他们的部落格内跟人讨论,这种方式网路蜘蛛跟其他的聚合器可以取得这个资讯,并且自动地将它们转换到vCards,然后在任何vCard的应用程式或服务使用他们。

这个规格介绍了hCard格式,hCard在语义的HTML里使用了前面提到的vCard标准的属性和值来1:1的实现,部落客也可以直接用内嵌的hCards在他们的网页里,并且用CSS来设计样式来使他们可以如预期显示,此外,hCard允许应用程式直接从网页来取得讯息而不需参考一个单独的档案来做。

使用hCard产生器并且复制它产生的HTML原始码到你的部落格或网站来公布你的联络资讯。

The key words “MUST“, “MUST NOT“, “REQUIRED“, “SHALL“, “SHALL NOT“, “SHOULD“, “SHOULD NOT“, “RECOMMENDED“, “MAY“, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

格式

一般来说

vCard标准(RFC2426)构成了hCard基础。

hCard的基本格式的类别名称以小写的vCaard物件/属性名称来使用,并且直接对应巢状的vCard物件到巢状的HTML元素里。

根类别名称

一个hCard的根类别名称是”vcard”,一个”vcard”类别名称的元素就是它自己称作hCard

属性跟子属性

一个hCard的属性是由hCard内的元素来表现,有下列属性的类别名称的元素表现那些属性的值,某些属性有子属性,并且对该属性来说是由元素内的元素来表现。

属性列表

hCard属性(子属性会像这样括号起来)

需求:

  • fn
  • n1 (family-name, given-name, additional-name, honorific-prefix, honorific-suffix)

可选择的:

  • adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value)
  • agent
  • bday
  • category
  • class
  • email (type, value)
  • geo (latitude, longitude)
  • key
  • label
  • logo
  • mailer
  • nickname
  • note
  • org (organization-name, organization-unit)
  • photo
  • rev
  • role
  • sort-string
  • sound
  • tel2 (type, value)
  • title
  • tz
  • uid
  • url

属性备注

1. ^:假如任意的隐藏的’n’最佳化规则是有效的话,’n’属性是可选择的
2. ^: tel – 作者可能会遵循E.123标准来书写电话号码的值,字母值(例 +1-555-格式) 必须转换为数字,使用abbr来显示字母并同时提供一个数值的值,例<abbr title="+15553676287">+1-555-格式</abbr>

单一属性 vs 多重属性

单一属性:’fn’, ‘n’, ‘bday’, ‘tz’, ‘geo’, ‘sort-string’, ‘uid’, ‘class’, ‘rev’,对单一属性来说,有类别的第一代元素应该开始作用,而其他的会被忽略。

所有其他的属性可能是多重的,像这样属性的每个类别实体会产生那个属性的一个新实体。

人们可读的 vs 机器可读的

一个属性元素的人类可见的文字内容表现该属性的值,只有一些例外:

假如<abbr>元素被用作一个特性,那么<abbr>元素的’title‘属性(如果存在的话) 就是这个特性的值,而不是元素的内容,取代的是一个更像样的版本值。

假如一个<a>元素用于一个或多个特性,必须按照下列处理:

  1. 对于把URL作为它的值的’photo’特性跟任何其它特性,href="..."属性提供了特性值。
  2. 对其它的特性来说,元素的内容就是特性值。

假如一个<img>元素用于一个或多个特性,必须按照下列处理:

  1. 对于把URL作为它的值的’photo’特性及任何其它的特性来说,src="..."属性提供了特性值。
  2. 对其它特性来说,<img>元素的’alt‘属性就是特性值。

假如一个<object>元素用于一个或多个特性,必须按照下列处理:

  1. 对于把URL作为它的值的’photo’特性及任何其它的特性来说,data="..."属性提供了特性值。
  2. 对其它的特性来说,元素的内容就是特性值。

值的筛选

有时候只有部份的元素有等同的特性用于特性值,这通常发生在特性有子型别,像’tel’,为此,这特别的类别名称”value“用来筛选元素子行别的特性值,例如,这里有一个hCard片段用来标记一个家用电话号码:

vCard:

TEL;TYPE=HOME:+1.415.555.1212

hCard:

<span class=”tel”> <span class=”type”>home</span>: <span class=”value”>+1.415.555.1212</span> </span>

hCard片段可以显示成:

home: +1.415.555.1212

特性的例外

vCard有几个特性不是没有意义的,就是已经隐含在网页中的上下文,这一节会说明如何(不)处理他们。

  1. vCard的NAMEPROFILESOURCEPRODIDVERSION特性定义在RFC2426的2.1.2、2.1.3、2.1.4、3.6.3、3.6.9等小节,内容发布者不得使用这些特性在他们的hCard里,因此,hCard用户/剖析器必须 忽略这些特性假如在hCard中有发现这些特性的话,相反地,hCard到vCard的转换器应该使用hCard被找到的页面title(例如,HTML文件中的<title>元素)来建构NAME特性,可能RFC2426输出一个”VCARD“的PROFILE值,应该使用hCard被找到的页面URL来建构SOURCE特性(例如可能是一个参数转换hCard到VCard的URL/服务),对一个输出的vCard串流来说(例如一个.vcf档),只有输出真正的cVard的服务/应用程式应该写PRODID特性,就上述的服务/应用程式的产品识别器来说,同样地,只有这样的服务/应用程式应该写VERSION特性,由RFC2426的3.6.9节的”3.0″值 (没有引号)。

组织机构的联系方式

假如”FN”及”ORG” (organization)特性有完全相同的值(通常是因为他们设为想同的元素,如class=”fn org”),那么hCard表示公司、组织霍地方的资讯应该这样来处理,在这个例子中作者也不得设定”N”特性,或明确地设成(以及任何的子特性)空字串””,因此剖析器应该处理这个错误的”N”特性,在这个例子中可以藉由隐藏所有”N”的子特性的空值来完成。

隐藏的”n”最佳化

虽然vCard需要”N”特性存在,在vCard规格(RFC2426)靠近尾端(p.38)那边他们自己的authors却不包含”N”特性在他们的vCard里,这种明显的矛盾可以在规格提供的一般案例里只要允许”FN”特性暗指”N”特性值就可解决,我们可以明确地在hCard里这样做。

假如”FN”跟”ORG”不相同(见前一节),而且”FN”特性的值刚好是两个字(空白字元分隔),没有明显的”N”特性,那么”N”特性可以由”FN”特性来推测,对于任意字的”FN”见下面,三个或以上的,author 必须明确标记”N”,除了组织机构的联系方式例子,详见前述

  1. “FN”的内容用空格分成两个”字”。
  2. “FN”的第一个字被解译为”N”特性的”给定名称”。
  3. “FN”的第二个/最后一个字被解译为”N”特性的”家系名称”。
  4. 例外:假如第一个字结尾是”,”逗号,那么第一个字(扣掉结尾的逗号)会被解译为”家系名称”而第二个字被解译为”给定名称”。

这允许在人们叙述的典型案例中简化:

  • 给定名称(空格)家系名称
  • 家系名称(逗号)给定名称

隐藏的”nickname”最佳化

由于普遍的使用nicknames/handles/usernames在Web上发布的实际内容(例如reviews的authors),hCard也有隐藏的”nickname”最佳化要处理。

跟隐藏的”n”最佳化类似,假如”FN”跟”ORG”不相同,且”FN”特性值只有一个字,而且没有明确的”N”特性,那么:

  1. “FN”的内容必须被处理成”nickname”特性值。
  2. 剖析器应该对所有的”N”的子特性来指涉空值以处理遗失的”N”特性。

虽然剖析器必须遵照隐藏的nickname最佳化,发布者即使在这例子中也应该明确地指示”nickname”,例如:

<span class=”vcard”> <span class=”fn nickname”>daveman692</span> </span>

hCard可能有额外明确的”nickname”特性值除了隐藏的nickname之外。

隐藏的”organization-name”最佳化

“ORG”特性有两个子特性,organization-name跟organization-unit,作者一般只会公布organization-name,因此假如”ORG”特性没有”organization-name”在里面,那么它的整个内容必须处理为”organization-name”。

标签的分类

hCard的分类可以使用rel-tag标签来表示,当一个分类特性是rel-tag时。标签(用rel-tag定义)用于那个分类。

type子特性值

‘type’子特性有什么值特别取决于它是那个特性的子特性,这些’type’子特性值不分大小写,也就是说”Home”跟”home”一样,以及多值,例如,tel可以是home跟preferred的子特性:

vCard:

TEL;TYPE=HOME,PREF:+1.415.555.1212

hCard:

<span class=”tel”><span class=”type”>Home</span> (<span class=”type”>pref</span>erred): <span class=”value”>+1.415.555.1212</span> </span>

也可以这样显示:

Home (preferred): +1.415.555.1212

没有特定值的type

当一个特性的type被指定,且没有明确值被指定,那么除了type以外的特性每件事会被认为是特性值,例如,

<span class=”tel”><span class=”type”>Home</span> +1.415.555.1212</span>

等同于:

<span class=”tel”><span class=”type”>Home</span><span class=”value”> +1.415.555.1212</span></span>

因此type是”home”且值为”+1.415.555.1212″。

adr tel email型别

下面的列表是有用的讯息,分别见RFC2426的3.2.1 ADR、3.3.1 TEL及3.3.2 EMAIL等节的有用的type值,为了方便他们会重复出现,预设的type子特性值会出现在每个列表前,并且用ALL CAPS表示,types可以是多值的。

  • adr type:INTL、POSTAL、PARCEL、WORK、dom、home、pref
  • tel type:VOICE、home、msg、work、pref、fax、cell、video、pager、bbs、modem、car、isdn、pcs
  • email type:INTERNET、x400、pref

Profile

hCard的XMDP profile在http://microformats.org/profile/hcard

使用hCard的内容应该参考这个profile,例如:

<head profile=”http://microformats.org/profile/hcard”>

<link rel=”profile” href=”http://microformats.org/profile/hcard”>

This content uses <a rel=”profile” href=”http://microformats.org/profile/hcard”>hCard</a>.

内容也可以结合上述的方法。

详细解析

hCard parsing

范例

这一节的资讯是有用的。

vCard范例

vCard的范例:

BEGIN:VCARD
VERSION:3.0
N:Celik;Tantek
FN:Tantek Celik
URL:http://tantek.com/
END:VCARD

在hCard有同样的范例适当地使用不同优化的元素,见 hCard Example 1的推导。

<div class=”vcard”> <a class=”url fn” href=”http://tantek.com/”>Tantek Celik</a> </div>

hCard也可以这样显示:

注意:在hCard标记里版本的资讯不需要因为版本会定义在hCard的profile而这profile用于/参考于<head>元素的’profile’属性>。

例子

这里有Commercenet的联络资料,可以用这一页微格式的解析工具来侦测范例的hCard:

CommerceNet
http://www.commerce.net/
Work: 169 University Avenue

Palo Alto, CA 94301

USA

Work +1-650-289-4040
Fax +1-650-289-4041
Email info@commerce.net

下列的语义改善标记为了清晰省略了强调的显示:

  • abbr是abbreviations缩写
  • 将org名称用url表示
<div class=”vcard”> <a class=”fn org url” href=”http://www.commerce.net/”>CommerceNet</a> <div class=”adr”> <span class=”type”>Work</span>: <div class=”street-address”>169 University Avenue</div> <span class=”locality”>Palo Alto</span>, <abbr class=”region” title=”California”>CA</abbr>&nbsp;&nbsp; <span class=”postal-code”>94301</span> <div class=”country-name”>USA</div> </div> <div class=”tel”> <span class=”type”>Work</span> +1-650-289-4040 </div> <div class=”tel”> <span class=”type”>Fax</span> +1-650-289-4041 </div> <div>Email: <span class=”email”>info@commerce.net</span> </div> </div>

更多的例子

hCard examples有更多例子,包括vCard RFC2426转换到hCard的所有例子。

站外的例子

这一节的资讯是有用的,站外的hCard范例数已经大到无法在这个规格里维护,他们已经移至另一页

站外的hCard范例

实作

这一节的资讯是很有用的,有很多的hCard实作已经扩展到无法在这里维护,他们的资讯已经移到另一页

hCard实作

文章

这一节的资讯很有用,进一步阅读hCard的文章见hcard-articles

按钮

你可以在网页上用hCards来使用这些按钮,见hCard按钮有最近增加的资料。

版权

每个公有领域的发表在作者的使用者页面上(Tantek CelikBrian Suda) 这个规格发表在公有领域中。

Public Domain Contribution Requirement. Since the author(s) released this work into the public domain, in order to maintain this work’s public domain status, all contributors to this page agree to release their contributions to this page to the public domain as well. Contributors may indicate their agreement by adding the public domain release template to their user page per the Voluntary Public Domain Declarations instructions. Unreleased contributions may be reverted/removed.

专利权

This specification is subject to a royalty free patent policy, e.g. per the W3C Patent Policy, and IETF RFC3667 & RFC3668.

参考

引用标准

参考性文献

这一节是很有知识的

使用hCard的规格

类似的工作

这一节是很有知识的

启发灵感的人和感谢

这一节是很有知识的。感谢: 我的好友Vadim他在很多年前介绍给我vCard,假如我当时只是注意更多点,或许我可以帮助更多人避免浪费更多的时间在重塑各种标准的巨轮。

注意vCard的延伸

这一节是很有知识的

更多语义上相同的事物

对有些属性来说会有更适合且更能传达他们的语义的HTML元素,下面的属性应该用下面的HTML来编码:

  • vCard的URL变成在hCard里用class="vcard"的元素里的<a href="...">...</a>
  • 同样地,vCard的EMAIL变成<a href="mailto:...">...</a>
  • vCard的PHOTO变成<img src="..." alt="Photo of ..." /> 或是<object data="..." type="...">Photo of ...</object>
  • vCard的UID简单地变成另一个语义应用到hCard的一个特定的URL (或EMAIL)。

单一和多数的延伸

单一和多重属性列表里有藉着分析vCard RFC2426里单一属性的语义和逻辑地确定他们的每一个语义必须是单一的延伸,见hcard-singular-properties有更多说明。

多重属性单一化

由于多重属性名称变成他们单一的相等物,即使原始的多重性只允许多重组件有一单一的值,那些多重组件用他们自己的单一名称的属性来表现,这个属性是多重值属性的跟上述多重值属性的处理主题。

相关的网页

The hCard specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.

1 則留言

  1. I’m trying to open forum but sometimes there are no images on it 🙁

Comments are closed.