这一篇来自微格的维基网站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>元素用于一个或多个特性,必须按照下列处理:
- 对于把URL作为它的值的’photo’特性跟任何其它特性,
href="..."属性提供了特性值。 - 对其它的特性来说,元素的内容就是特性值。
假如一个<img>元素用于一个或多个特性,必须按照下列处理:
- 对于把URL作为它的值的’photo’特性及任何其它的特性来说,
src="..."属性提供了特性值。 - 对其它特性来说,
<img>元素的’alt‘属性就是特性值。
假如一个<object>元素用于一个或多个特性,必须按照下列处理:
- 对于把URL作为它的值的’photo’特性及任何其它的特性来说,
data="..."属性提供了特性值。 - 对其它的特性来说,元素的内容就是特性值。
值的筛选
有时候只有部份的元素有等同的特性用于特性值,这通常发生在特性有子型别,像’tel’,为此,这特别的类别名称”value“用来筛选元素子行别的特性值,例如,这里有一个hCard片段用来标记一个家用电话号码:
vCard:
TEL;TYPE=HOME:+1.415.555.1212
hCard:
hCard片段可以显示成:
home: +1.415.555.1212
特性的例外
vCard有几个特性不是没有意义的,就是已经隐含在网页中的上下文,这一节会说明如何(不)处理他们。
- vCard的NAME、PROFILE、SOURCE、PRODID、VERSION特性定义在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”,除了组织机构的联系方式例子,详见前述。
- “FN”的内容用空格分成两个”字”。
- “FN”的第一个字被解译为”N”特性的”给定名称”。
- “FN”的第二个/最后一个字被解译为”N”特性的”家系名称”。
- 例外:假如第一个字结尾是”,”逗号,那么第一个字(扣掉结尾的逗号)会被解译为”家系名称”而第二个字被解译为”给定名称”。
这允许在人们叙述的典型案例中简化:
- 给定名称(空格)家系名称
- 家系名称(逗号)给定名称
隐藏的”nickname”最佳化
由于普遍的使用nicknames/handles/usernames在Web上发布的实际内容(例如reviews的authors),hCard也有隐藏的”nickname”最佳化要处理。
跟隐藏的”n”最佳化类似,假如”FN”跟”ORG”不相同,且”FN”特性值只有一个字,而且没有明确的”N”特性,那么:
- “FN”的内容必须被处理成”nickname”特性值。
- 剖析器应该对所有的”N”的子特性来指涉空值以处理遗失的”N”特性。
虽然剖析器必须遵照隐藏的nickname最佳化,发布者即使在这例子中也应该明确地指示”nickname”,例如:
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:
也可以这样显示:
Home (preferred): +1.415.555.1212
没有特定值的type
当一个特性的type被指定,且没有明确值被指定,那么除了type以外的特性每件事会被认为是特性值,例如,
等同于:
因此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,例如:
或
或
内容也可以结合上述的方法。
详细解析
范例
这一节的资讯是有用的。
vCard范例
vCard的范例:
BEGIN:VCARD VERSION:3.0 N:Celik;Tantek FN:Tantek Celik URL:http://tantek.com/ END:VCARD
在hCard有同样的范例适当地使用不同优化的元素,见 hCard Example 1的推导。
hCard也可以这样显示:
注意:在hCard标记里版本的资讯不需要因为版本会定义在hCard的profile而这profile用于/参考于<head>元素的’profile’属性>。
例子
这里有Commercenet的联络资料,可以用这一页微格式的解析工具来侦测范例的hCard:
Palo Alto, CA 94301
USA
下列的语义改善标记为了清晰省略了强调的显示:
abbr是abbreviations缩写- 将org名称用url表示
更多的例子
见hCard examples有更多例子,包括vCard RFC2426转换到hCard的所有例子。
站外的例子
这一节的资讯是有用的,站外的hCard范例数已经大到无法在这个规格里维护,他们已经移至另一页。
实作
这一节的资讯是很有用的,有很多的hCard实作已经扩展到无法在这里维护,他们的资讯已经移到另一页。
见hCard实作。
文章
这一节的资讯很有用,进一步阅读hCard的文章见hcard-articles。
按钮
你可以在网页上用hCards来使用这些按钮,见hCard按钮有最近增加的资料。
- (mirror:
) 

- CSS很有威力的按钮,在http://re-run.com/about/microformat-badges这里可以证明
版权
每个公有领域的发表在作者的使用者页面上(Tantek Celik、Brian 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.
参考
引用标准
- XHTML 1.0 SE
- vCard RFC2426
- 电话号码的ITU recommendation E.123格式(收费文件)
- RFC 2119
参考性文献
这一节是很有知识的。
- hCard历史
- X.520 in Postscript (HTMLization courtesy of Google Cache) – vCard是指ROLE作为”X.520业务分类属性说明的基础”.
- RFC2426的HTML格式化版本
- CSS1
- XHTML 1.1
- Wikipedia summary of ITU-T Recommendation E.123 – for “TEL” values.
- Internet Mail Consortium Personal Data Interchange vCard and vCalendar
- ISO8601
使用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有更多说明。
多重属性单一化
由于多重属性名称变成他们单一的相等物,即使原始的多重性只允许多重组件有一单一的值,那些多重组件用他们自己的单一名称的属性来表现,这个属性是多重值属性的跟上述多重值属性的处理主题。
相关的网页
- hCard
- hCard cheatsheet – hCard properties
- hCard creator (feedback) – create your own hCard.
- hCard authoring – learn how to add hCard markup to your existing contact info.
- hCard examples – example usage of various classes within hCard.
- hCard examples in the wild – an on-going list of websites which use hCards.
- hcard-supporting-user-profiles – sites with user profiles marked up with hCard – a very common example.
- hCard FAQ – if you have any questions about hCard, check here.
- hCard implementations – websites or tools which either generate or parse hCards.
- hcard-implied – a proposal to create a alternative method of marking up a simple hCard
- hCard parsing – normative details of how to parse hCards.
- hCards and pages – semantic distinctions between different hCards on a page, and how to identify each
- hcard-user-interface – techniques and issues surrounding user-interfaces to author, publish, and display hCards.
- hCard profile – the XMDP profile for hCard
- hCard singular properties – an explanation of the list of singular properties in hCard.
- hCard tests – a wiki page with actual embedded hCards to try parsing.
- hCard advocacy – encourage others to use hCard
- hCard “to do” – jobs to do
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.
- hCard brainstorming – brainstorms and other explorations relating to hCard.
- hcard-parsing-brainstorming – brainstorming specific to parsing of hCard
- geo brainstorming
- hCard feedback – general feedback (as opposed to specific issues).
- hCard issues – specific issues with the specification.
- vCard errata – corrections to the vCard specification, which underlies hCard.
- vCard suggestions – suggested improvements to the vCard specification.
I’m trying to open forum but sometimes there are no images on it 🙁