Serial comma——有争议的逗号

2009/09/11 | 21:25 | 分类:文科类文档 | 标签: | 631次阅读

  昨天读师兄的论文时,发现他多次使用“A, B, and C”这样的并列形式。我觉得有点奇怪,记得中学英语老师教的都是:“并列的几个词中,最后两个用 and/or 连接,and/or 前面不加逗号”。我向师兄询问其中的理由,他说很多学术性文章都是这样用的,他也是从他的师兄那里知道这个用法的。师兄打开 Google 的“老三篇”向我证实了这种用法的权威性。我确实很怀疑我的英语能力,平时看论文时能把意思看懂就不错了,这些语法细节没有太多地注意过;但发现问题了还是要刨根问底的,所谓学术用法或权威用法必须有一定的依据才能将我说服。于是 Google 之,找到了逗号这种用法的相关说法。
  根据 Wikipedia 上的条目,在并列结构的 and/or 之前插入的逗号称为“Serial comma”(或 Oxford comma、Harvard comma)。这是一种有颇争议的语法,支持的观点认为 Serial comma 很多时候可以避免歧义,同时使句子具有韵律感;而反对的观点则认为 Serial comma 在不少情况下会引入歧义,同时指责这种用法有悖习惯。该条目列出了 Serial comma 消解歧义和引发歧义的几个例子,同时给出了并列结构中歧义出现的一般性规则。从中我们也了解到,各英语国家不同的政府、学术、出版机构在其规范文件中对 Serial comma 的态度也是不同的。在不引发歧义的大前提下,有的机构(如牛津大学出版社)推崇 Serial comma,而有的机构(如剑桥大学出版社)则要求作者避免这种用法。
  另外我查证了一下计算机科学方面的相关规范。IEEE 的《Preparation of Papers for IEEE TRANSACTIONS and JOURNALS》明确说明“The serial comma is preferred: ‘A, B, and C’ instead of ‘A, B and C’”,ACM 的部分会议、杂志也有类似的要求。既然本领域的两大巨头都要求使用 Serial comma,那么师兄的说法应该是有道理的。仔细阅读了一下 IEEE 和 ACM 的写作规范,发现自己平时没注意到的东西还真不少。虚心学习之,以免这些细节问题成为飘进审稿者眼中的沙子。

Identity 2.0 何时真正到来?(四)用户价值决定前途走向

2009/09/02 | 21:10 | 分类:IT杂谈 | 标签: | 681次阅读

  前面三篇文章分别介绍了三类已经投入实际使用的、独立的 Identity 2.0 机制。与此同时很多在互联网时代既得利益的公司也都试图借助自己庞大的用户资源在身份认证领域分一杯羹。微软的 Windows Live ID(早期称为 .NET Passport、Microsoft Passport Network)算是动手比较早的,Google Account AuthenticationYahoo! BBAuthFacebook Connect 等是各家公司推出的类似的身份认证服务。但这些服务本质上不符合 Identity 2.0“以用户为中心”的精神,它们仍使用原有的集中式用户系统,由这几家大公司自己维护用户数据,仅允许其它网站借助其 API 验证用户身份,读取用户的非敏感信息。这类技术的用户价值在于单点登录和相对安全(类似于 OpenID),单点失效问题通过内部对用户透明的分布或容错机制实现(目前阶段,这几家大型网站的可靠性相比小型的 OpenID provider 更有技术保障,至少用户的心理体验是这样)。对小型网站的经营者来说,让拥有 Google、Yahoo、Facebook 账号的用户直接登录自己的网站,同时能从知名网站获得用户的部分注册信息,确实有一定的吸引力。目前已经有像 clickpass 这样集成各家身份认证的第三方服务。而对于想为第三方网站提供身份认证服务的普通网站来说,开放的 OAuth 协议可以直接在既有系统中集成,twitter豆瓣等是其成功案例。但 OAuth 更多地用于与提供身份认证的网站息息相关的第三方应用开发,还不能算是一种通用的身份认证机制。
Identity 2.0 何时真正到来?(四)用户价值决定前途走向
  此外还有一系列或是没有走出实验室、或是没有着力推广的 Identity 2.0 技术。关于它们的讨论可以通过以下一些网站获取:
  ● Identity 2.0 Blog
  ● Identity Commons Wiki
  ● Internet Identity Workshop
  我们回过头来看,Identity 2.0 概念的提出大约有五年了,而事实上像 Microsoft Passport Network 之类的原型产品的推出是更早之前的事。但即使是现在发展情况最好的 OpenID,支持它的独立公众网站也维持在三位数之内。而看看上述几个网站,文章和项目的活跃程度也在逐渐下降,不少链接失效。Identity 2.0 为什么没有像 Web 2.0 那样大放异彩?这个问题值得业内人士思考。我列出以下几点:
  “鸡与蛋”的问题——要想让基础设施(互联网标准、客户端软件)支持 Identity 2.0 的特性,就需要用足够的杀手级应用来说明其重要性;而要建立有影响力的杀手级应用,又需要基础设施的原生支持。要让用户接受并广泛使用 Identity 2.0 的个人身份,就需要有大量的既有应用启用 Identity 2.0 机制;而要让现存的网站加入对 Identity 2.0 的支持,又需要广大持有 Identity 2.0 身份的用户来诱发。
  使用的体验的改变——普通用户可能不会理解 OpenID 这种 provider 中介模式的安全优势,因为在用户看来还是要输入一次用户名密码的,而且是把密码交给了第三方。对于 Information Card,用户可能难以习惯长期保存并随身携带 Card 文件的使用模式,在经历了一两次 Card 丢失或一时无法取得的情况,就会打击用户的使用兴趣。而如果在线保存 Information Card,又存在和密码托管网站一样的信任危机。至于基于 XRI 的 i-name,普通用户可能也不愿意为其缴纳年费。
  安全性问题——这是任何一种身份认证机制都必须首先保证的。各类 Identity 2.0 技术都宣称自己的协议比传统方式安全,这不假,但它们的前提假设是:provider 等第三方机构确实可信;用户按照一定的规程来使用(比如不随意复制未加密码的 Information Card)。如果 provider 作恶或者用户不遵守使用规程,同样会造成信息泄露。provider 作恶在其它分布式系统中是存在的(比如 DNS 欺骗、虚假 Tor 节点等),难免在 Identity 2.0 中重演;而引入新的用户体验之后,要求用户掌握其操作原则是有时间成本和运营风险的。
  用户价值的体现——我认为这是核心因素。Identity 2.0 究竟能不能给用户带来全新的使用价值?是否满足普通用户和网站经营者双方的利益需求?身份认证方面的创新能否给互联网带来足够大的积极影响?这些问题不是纯粹的技术问题,有待市场来检验。但 Web 2.0 时代用户是重要的资源,如果将用户系统拱手交出,全线采纳 Identity 2.0,或许是一些既得利益者不愿意看到的。即使对于普通用户,像单点登录、一卡走天下这样的特性真的是大众的需求吗?也许更细的授权粒度、站点独立的密码设置才能让一部分人放下心来。
  我们不能过早地断言 Identity 2.0 会走向失败。也可能是早期定义的 Identity 2.0 过于激进,我们来看看 OpenID 现在的发展:在多数网站中没有完全取代传统的身份认证机制,而是作为它们的补充;通过底层的服务发现协议来和 LID、i-name 等兼容(最近 Windows Live ID 也要和 OpenID 兼容了),力图建立统一且开放的 Identity 2.0 平台。这种渐近式的、开放包容的路线,应该是 Identity 2.0 的生路所在。

vCard Assistant:将 vCard 导入 Nokia S60v2 手机的辅助工具

2009/09/02 | 00:17 | 分类:Web与移动平台 | 标签: | 1,298次阅读

  晚上为 Nokia S60v2 老机型用户写了一个 PC 端的小工具——vCard Assistant,用于将含有中文姓名的 vCard 文件(可以是 GB、UTF-8 或 UTF-16LE 编码的)转换成 ASCII 字节编码 UTF-8 形式;并可将 vCard 3.0 格式转为 2.1 格式,便于在某些对 vCard 中文姓名或 3.0 标签支持不好的手机中导入联系人。效果如下:
  输入:

BEGIN:VCARD
VERSION:3.0
N:;张三
FN:张三
TEL;TYPE=CELL;TYPE=VOICE:13811112222
EMAIL;TYPE=PREF;TYPE=INTERNET:foo@bit.edu.cn
REV:20090901T035836Z
END:VCARD
BEGIN:VCARD
VERSION:3.0
N:;李四
FN:李四
EMAIL;TYPE=PREF;TYPE=INTERNET:bar@gmail.com
REV:20090901T035835Z
END:VCARD
...

  输出:

BEGIN:VCARD
VERSION:2.1
N;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:;=E5=BC=A0=E4=B8=89
FN;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:=E5=BC=A0=E4=B8=89
TEL;CELL;VOICE:13811112222
EMAIL;PREF;INTERNET:foo@bit.edu.cn
REV:20090901T035836Z
END:VCARD
BEGIN:VCARD
VERSION:2.1
N;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:;=E6=9D=8E=E5=9B=9B
FN;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:=E6=9D=8E=E5=9B=9B
EMAIL;PREF;INTERNET:bar@gmail.com
REV:20090901T035835Z
END:VCARD
...

  这种格式可以被 Best vCard for S60 等软件读取,导入手机通信录。
  vCard Assistant 下载地址(包含源代码):
  http://files.linjian.org/dotNet/VCardAssistant.zip
  http://www.linjian.cn/files/dotNet/VCardAssistant.zip
  (需要 .Net Framework 3.5 平台支持)


  我为什么要写这个东西呢?主要还是自己的需求。我使用的 Nokia 6600 的 PC Suite 只支持从 IBM Lotus Notes、Microsoft Outlook 这类庞大的程序或 Windows Address Book 这种已被放弃的格式中导入联系人。我没有使用这两个商业软件,也不愿使用已经失去官方支持的 WAB 格式,而选择使用跨平台的、广为各类软件支持的 vCard 格式管理联系人,以便在多个系统、软件中直接共享。以前同步联系人时,先将 vCard 导出为 CSV,再使用虚拟机中的 Windows XP 通信录将 CSV 转换成 WAB 格式,然后通过 PC Suite 同步,比较折腾。现在只需要将 vCard 转换一次,通过蓝牙或 Email 发到手机上,用手机端的软件做同步,简便不少。
  事实上我以前也尝试过用 Google Sync 服务在线同步联系人(Gmail 也支持 vCard 导入导出),但同步过程总是异常停止。换用其它一些 SyncML 同步服务问题依旧。最终我在 mobical 网站发现一句话:“Nokia 6600: This device has a known issue where the synchronization may stop working at any time. As far as we can tell this is a bug in the Nokia software.”原来这是 Nokia 6600 的 bug……我也没有找到其它免费的 SyncML for S60v2 客户端,只能作罢。

化学出身的计算机达人

2009/08/30 | 12:06 | 分类:学习随感 | 标签: | 921次阅读

  昨天的 Beijing Open Party 上,我听了段炼同学介绍 GWT 的主题。上个月认识他时,我还误以为他是北理工新闻中心专职摄影的段炼老师,但他的真实身份却是华东理工大学制药工程专业的学生,计算机只是其“业余爱好”。段炼的 ID“chemhack”不禁让我猜想他是不是有像刘未鹏的“mindhacks”那样的风范。听了他的演讲、看了他的 blog,发现他确实是一个有 hack 精神的人。
  这是我认识的又一位从事化学相关领域的计算机高手。本科玩计算机博弈时,我认识了复旦大学化学系毕业的黄晨,他是象棋百科全书网站和象棋巫师软件的作者,UCCI 协议的制定者。后来参加中国机器博弈锦标赛时,我又有幸见到了中国电脑围棋的先行者、中山大学化学系退休的陈志行教授(陈老先生已于 2008 年不幸病故)。他研制的《手谈》软件曾多次在国际赛事中夺冠,商业版本也畅销于日本等国。在我决定读研之前,曾想了解一下科研生活,师兄推荐给我的是名曰“学术科研第一站”,实为化学相关专业主导的小木虫论坛,这个论坛也让我收益不少。在中科院研究生院集中教学期间,我又在计算机专业的课堂上认识了多位外专业的同学,他们有冶金化学的、化工自动化的、过程工程的,选择计算机类课程或出于实验室工作的需要,或出于个人兴趣。
  为什么会有这么多化学相关专业的朋友涉足了计算机领域呢?个人兴趣之外,或许最主要的因素是化学的很多研究需要以计算机作为海量数据采集、存储、分析、处理的工具。化学领域作为数据库、数据挖掘、网格计算等技术的重要应用,受益于计算机技术的发展,同时也对通过其复杂的需求引导着计算基础设施及算法的改进与发展。如今化学信息学的引入就是要用计算机来解决化学信息存储与检索的子问题。但除了这些技术上的因素,计算机和化学有没有本质上的相通呢?计算机是公认的人造科学、技术科学,而化学一般被认为是自然科学,尽管它也包含了一些技术科学和工程技术领域的分支。但我的初中、高中化学老师都给我灌输过这种思想:化学只是一系列模型,方便描述自然现象的,有些概念并不反映真实的存在;还说中学化学讲的都是早期的经典模型,为了解释新的现象,模型总在不断修补。我的大学同学,爱好电子、物理与计算机的 m100 则直接认定“化学是骗人的”。但我想,无论化学家们的科学信仰和主观意愿如何,化学和计算机科学在客观呈现上有两点是共通的:一是抽象建模,二是实用主义。计算机中只有线性的指令流和数据流,人们用结构化编程语言和文件系统的抽象将它们变得易于理解和使用;同样化学元素也不是什么微观物质,但化学家可以用这一抽象来表示特定原子组成,构建宏观世界到微观世界的桥梁,便于统一研究物质的性质。这种方法论上的相似或许是化学专业的朋友们乐于钻研计算机的原因之一。
  学术的火花往往都是在交叉领域中迸发的,黄晨的《电脑象棋和量子化学——计算量子化学的新思路》(黄晨网站原文无法找到,请看 google 到的转载结果)就是一例有益的探索。做计算机的人,不要耻笑个别外专业人员写的蹩脚的代码,也不要不屑于倾听外行对计算机技术看似幼稚的见解。内行最容易犯的毛病就是被既有知识的“框框”限制住,多看看外行在本领域的工作,听听他们大胆的思路,也许就能为自己的科研创新另辟蹊径。

消除 koomail 的“余孽”

2009/08/27 | 22:55 | 分类:Windows应用 | 标签: | 477次阅读

  koomail 曾是一个简洁小巧的 Windows 邮件客户端,是抵制 Foxmail 的良好选择,我使用它大约有两年了。但自从某个版本开始,koomail 界面变得花哨,不断增加一些华而不实的功能,还在主界面弄出了“山寨酷友”之类的 SNS 广告。相反地,我发现并上报的一些 bugs(涉及远程邮箱管理、RSS 阅读等)它却迟迟没有修复;我在其论坛提出的一些建议(诸如回复邮件时给原文前加上“>”这样的基本功能)也没有得到过作者的重视。于是,今天决定抛弃 koomail,在 Wikipedia 上另找一些优秀的邮件客户端。
  在研究这些客户端的过程中,发现老外们整出来的 mboxMaildirMH 等一系列邮件存储格式还是比较有用的。使用这些规范的格式毕竟有助于软件更替和数据移植,因此格式支持成为我考虑的重要因素。在将 koomail 的邮件导入其它客户端时,我发现部分邮件会被报告 MIME 错误,或者只能看到邮件头而看不到正文。经查这是因为 koomail 保存邮件时,将 SMTP(RFC 2821)中表示通信结束的“.”也存入了邮件文件,还在后面追加了一行不知做什么用的“k[0x01]m”。而 mbox 等格式规定文件只需存储 RFC 2822 消息本身。明白了原因,就可以写一个 bash 脚本来处理所有的邮件,消除 koomail 留下的两行“余孽”,让其它客户端可以正常读取:

  1. #!/bin/bash
  2.  
  3. for file in *; do
  4.     echo "$file"
  5.     sed -i 's/^k\x01m\x0d$/\x0d/g' "$file"
  6.     sed -i 's/^\.\x0d$/\x0d/g' "$file"
  7. done

  这时使用 Claws-Mail 客户端读入邮件(因为它和 koomail 一样,每封邮件是一个独立的文件),导出为 mbox 之后再在 Thunderbird 等其它客户端中阅读也是正常的。

页面存档: 上页 1 2 3 4 5 6 7 8 ...44 45 46 下页