作者：Rachel Lovinger，美国最大的互动广告公司Razorfish（睿域营销咨询公司）的内容策略领导人。

不知道什么是“内容策略”？这很正常。我在公司的头衔里就有这个词组。每当有人问起我靠什么过活时，我心里都十分纠结。许多人对这个词组没有什么概念，但在谈话间，我发现多数人对它的理解都是错误的。这些人觉得“内容策略”就是写文案的意思。虽然不能说完全不着边，但总归还是没说到点子上。

近来，我经常使用一个类比，我认为内容策略之于写稿，就像信息架构之于设计。我为自已能想到这个类比感到很满意，毕竟在6年前，当Web发展的第一波开始退潮时，“信息架构”到底是什么意思也没有几个人知道。

当前的问题在于，必须想办法向不理解内容策略的人解释清楚：内容策略的主要目标是使用文字和数据，创造出没有歧义的内容，从而为有意义的交互体验提供支持。为此，我们必须成为善于跟形形色色的人有效沟通的专家。

然而，到底是什么原因导致了我们的工作那么难于跟别人解释呢？

问题或许在于，内容是无处不在的，所以任何人都认为自己很明白。只要你能读会写，就可以制造内容，对吧？（近6000个博客可以证明这一点。）但事实上，随着交互体验变得日益复杂，内容的本质也变得越来越复杂了。这时候，只从表面上来理解内容已经远远不够了。数字时代的内容策略专家必须成为数据方面的哲学家，努力探寻有关内容的抽象理论，而这一切就要从回答“什么是内容”这个问题开始。

一切皆内容

在我们为一家国际娱乐杂志的网站开发复杂的元数据系统时，我的同事也是好朋友Chris Sizemore说：“一切皆内容。”我还比较认同这个观点。

一切皆内容吗？设计是吗？是。结构呢？也是。元数据呢？当然也是了。你可能觉得对这句话还应该有更深刻的解释。好吧，那就只能说：“准确地讲，一切皆内容。”

你可能会问，在崇尚视觉效果的Web设计领域，着意关注内容的需求源自何处呢？随着网站功能的日益丰富，Web用户的品味也越来越高。要想吸引人，你的站点就必须提供到位的交互体验，以及更多配套的内容。但简单地增加内容是不行的，你必须让内容有的放矢、言之有物，而且还要有意义。

提到决定事物是否有意义的因素，我可以罗列出一大串，但就Web应用而言，我认为最主要的一个因素是联系。Z文章与点击的主题有关系吗？给我看看。B图片与我已经见过的一样吗？拜托，我可不想再看到同一张图片了！诸如此类微妙、动态而又复杂的关系，都需要找到一种计算机能够遵照执行的方式精确地表达出来。那我们就举个看起来似乎很直观的例子，比如说“相同”：你怎么确定两段内容是相同的？

你可能会说任何数据记录都是唯一的，因此是否相同一看便知。但这对于找出两段无论从哪方面说都完全一样的文字之间的关系却毫无帮助。噢，大概在内存中的字节相同可以说明两段内容相同罢。那么一篇文章与它的翻译版呢？一张图片与它的缩放版呢？从读者角度说，它们是相同的，只不过有一张小一些。还是那张图片，它与它的裁切版相同吗？

问到这，“相同意味着什么？”这个命题合乎有点像推理了。然而，在构建CMS（内容管理系统）的时候，这个问题却有着非常实际的含义。你怎样取得一篇文章及其翻译版，会对文章的编排、发表以及最终在站点上使用的方式造成巨大差异。而一张图片与它的缩放版、裁切版在CMS中保存的方式，则很可能会对呈现及访问它们产生意想不到的影响。

临界量

如果你只想展示非常短的一条信息，那（也许）可以随便把它一放，然后让用户自己去理解就行了。

图1 极其简单的网站用不着IA或内容策略

随着要展示的信息不断增多，用不了多久，就需要运用某些结构来组织这些信息，以方便用户找到它们。而这正是信息架构要解决的问题，即通过应用组织原则和视觉提示，让用户一打开站点就能迅速定位目标，而不必多费脑筋。如果碰巧赶上信息架构师（IA，Information Architect）对文字有兴趣，那么他可能会仔细地考虑按钮上的文本到底用什么语言最有利于传达信息。如果信息架构师没有这份心思或者经验，那么这时候就可以轮到内容策略专家（CS，Content Strategist）上场了。CS此时也要与IA密切协作，以确保站点的组织井然有序，同时还要确保相应的内容各就各位。

图2 复杂一些的站点就需要组织了

在设计和构建内容量极大的网站时，我们发现单靠手工组织这些内容是不现实的。在这种情况下，就需要用到自动化的、复杂的算法来解放人类了。为此，内容中必须包含机器能够识别的固有信息，例如通过搜索、浏览和相关链接来维系数据驱动的应用。内容策略专家的责任就是专注于怎么才能让内容有意义，同时也让站点的设计最恰当地利用内容。

实战演练

在经过了一番哲学思辨之后，我们终于搞清楚了谁要为内容负责了。那么，到底怎样才能让内容有意义呢？

为了让人们感觉内容与他们有关，必须选择那些对实现沟通目标效果最好的词汇和句子结构。至于表达方式，应该在深刻理解内容创作者的意图和内容消费者的需求的基础上来确定。为此，可以借助类似于编辑指南的手册来提供指导，或者提供一些让别人能够按照相同表达方式组织内容和消息的示例。

为了让机器更好地处理内容，需要将内容结构化并定义标准的元素，从而方便内容的使用和重用。需要对内容分门别类，为不同类别添加相应的元数据，以便于识别。需要在内容之间建立关联，使得它们的背景丰富，不显得单薄，同时也能支持各种复杂的功能。

为了保证创建内容的效率，需要评估和推荐一些解决方案，用于创建、增强、组织和使用内容，包括内容管理系统、元数据相关的工具、搜索引擎及方便的导航应用程序。需要创立业务规则及工作流，进一步优化这些工具和系统的使用。

为了保证内容面面俱到，需要确定站点的内容需求，清查已有的内容，发现缺口，落实新增内容的补给渠道，并控制将这些内容融合到产品中去的整个过程。在既定的背景和参考资料支持下，可能还要编写标签、概述，甚至更长的内容。

在做以上这些事并创造相应成果的过程中，不要因为过时的哲学问题而让实际上简单的问题复杂化。试试这个脑筋急转弯：“具备什么样品质的内容才能历经三个月都不会磨灭其价值，而又是什么样的品质会导致内容甫一问世就面临过时的危险？”（提示：没有唯一的答案。）

内容策略专家的策略

如果你是一名内容策略专家。

• 问自己或同事一些有关内容的难题（例如：“内容是什么？”“什么因素会提升内容的价值？”）。
• 头脑风暴，探讨怎样生成更有意义的内容，如何确定质量好与坏的标准。落实到一个投入/产出分析模型上。
• 比较不同的内容模型并确定各自适合的用途。
• 关注一些新出现的能够有效解决内容问题的工具。创造性地使用这些工具，包括发现新用途和新用法，然后把这些创意告诉工具的开发人员，以促进工具改进。

如果你与内容策略专家合作。

• 花点时间认真严肃地思考一下内容。在讨论内容问题，而内容又似乎不是问题的直接诱因时，请保持几分耐心——有时候，只有这种态度才能拿出理想的内容方案。
• 在开始规划站点之初，就在项目中考虑内容。千万不要在站点已经构建和设计完成后，才意识到需要找些内容来填充页面。

如果你没有与内容策略专家协作，但有这个意愿。

• 向组织的负责人说明内容策略专家扮演的角色，以及他们为什么可以节省时间和精力，可以帮助避免问题，可以提升最终产品的品质。在项目收尾时，可以举出一些能够说明“如果早点想到这一点就好了”的例子。根据这些与内容相关的例子，你会发现自己可能成功了一半了。
• 如果不行，再了解组织中哪个人对内容理论更感兴趣，鼓励他们多做一些相关的研究。过一段时间后，再给他们摆事实，讲道理，然后你的心愿就可以达成 了。

内容策略并没有一个放之四海而皆准的定义，不同的人对它的理解也不怎么一致，但这可不是对内容策略视而不见的理由。只有深刻认识到内容的重要性，像个哲学家一样思考问题，你才能够做到随机应变。

loop、iterate、traversal和recursion这几个词是计算机技术书中经常会出现的几个词汇。众所周知，这几个词分别翻译为：循环、迭代、遍历和递归。乍一看，这几个词好像都与重复（repeat）有关，但有的又好像不完全是重复的意思。那么这几个词到底各是什么含义，有什么区别和联系呢？下面就试着解释一下。

• 循环（loop），指的是在满足条件的情况下，重复执行同一段代码。比如，while语句。
• 迭代（iterate），指的是按照某种顺序逐个访问列表中的每一项。比如，for语句。
• 遍历（traversal），指的是按照一定的规则访问树形结构中的每个节点，而且每个节点都只访问一次。
• 递归（recursion），指的是一个函数不断调用自身的行为。比如，以编程方式输出著名的斐波纳契数列。

有了以上定义，这几个概念之间的区别其实就比较清楚了。至于它们之间的联系，严格来讲，它们似乎都属于算法的范畴。换句话说，它们只不过是解决问题的不同手段和方式，而本质上则都是计算机编程中达成特定目标的途径。

寻人启示

lyongde 同学，请尽快将你的名字发到我的邮箱里面（lsf.email[at]gmail.com），以便在第二次印刷时加到译者序中以表感谢。

儒家经典《大学》将“格物致知”奉为做学问、养身性的最高境界。

尼古拉斯•扎卡斯重新修订的这个最新版本，为各层次的JavaScript爱好者和Web前端开发人员提供了一条“格物致知”的捷径。

新版本的原书不仅篇幅由原来的600多页增加到800页，而且几乎全部更新、重写了上一版的内容，删除了上一版中与今天的职业需求无关的主题，新增了大量比上一版更有价值、更能反映JavaScript最新发展成果的内容。从颇具深度的JavaScript语言基础到作用域（链），从JavaScript引用类型到面向对象编程，从极其灵活的匿名函数到闭包的内部机制，从浏览器对象模型（BOM）到客户端检测，从文档对象模型（DOM）到基于事件的Web脚本编程，从错误处理到前端调试，从XML（E4X）到Ajax及JSON，从高级前端开发技术到前沿的客户端存储，从最佳编程实践到展望即将成为现实的API，直至JavaScript未来的发展。全书基本上囊括了JavaScript技术的各个方面，几乎涉及到了Web前端开发的所有热门话题。值得一提的是，本书还涵盖了当前最受开发人员关注的HTML5和移动设备（如iPhone）开发的内容。可以预见，本书一定会成为Web前端开发人员不可多得的经典之作。

需要提请读者注意的是，本书第22章讲到了JavaScript未来的变化，里面大部分讲的是ECMAScript 4/JavaScript 2，而ECMAScript 4已经被放弃了，新标准是ECMAScript 5。请读者参考http://www.ecmascript.org/。感谢周涛（Snandy）指出此问题。

本书文前和第1章至第17章由李松峰翻译，第18章至第22章及附录由曹力翻译。武卫东老师审读斧正了序的翻译，责任编辑朱巍为本书早日出版多方协调，执行编辑毛倩倩发现了译稿中多处错译和漏译，排校负责人董秋霞、谢凌老师严把三道排校质量关、谢廷晟全面审校了第1章至第17章，吴玺喆（George Wing）、吴生辉（千年一梦）、周裕波、梁超（LC）、张树恒(shuzai)、罗永德（lyongde）也审校了前17章的部分内容，为确保本书翻译质量起到了重要作用，在此对上述老师和同学致以深深的谢意。

译者
2010年5月

第5章中有这样一句话：“this是函数在执行时所处的作用域”（《JavaScript高级程序设计（第2版）》第5章5.5.4节正文倒数第3段中）。我觉得作者的这种说法大有问题。对JavaScript不熟悉的读者会越看越糊涂。这里首先需要明确两个概念：函数执行时所处的作用域、在哪个作用域中调用函数函数调用发生的作用域，否则讨论就无法继续深入。把后一概念明确为“函数调用语句所处的那个作用域”应该没有问题。而前一个概念，实际上就是函数的定义所处的那个作用域。以下面的代码为例：

function a() {
// …
}

function b() {
/// …

return function c() {
// …
};
}

var d = b();
a();
d();

在这里，函数a、b和d（实际上就是c）都是在全局作用域中调用的。a和b执行时所处的作用域都是全局作用域。但是d执行时所处的作用域并不是全局作用域，而是函数b的局部作用域。说到这里，就可以看到“this是函数在执行时所处的作用域”这一说法的不妥了。假如函数c中引用到了this（在本例中，d是直接调用的，所以this指向的是全局对象），那么按作者的说法，c 岂不是直接运行在全局作用域中而不是b的局部作用域中了？再看下述例子：

var greeting = ‘Hello from global scope!’;

function e() {
alert(greeting);
alert(this.greeting);
}

var tom = {
greeting:’Hello from Tom!’
};
tom.f = e;
tom.f();

这个例子中的this指向的是什么？显然是tom。那么f（即e）执行时所处的作用域是什么？显然是全局作用域。假如f执行时所处的作用域如作者所说为this所指对象的话，那就意味着在本例中f执行时所处的作用域为tom，也就是说在f执行过程中，与其作用域链相对应的那个变量对象链的最前端那个对象是tom，而这就意味着在此时函数体内对名称greeting进行解析时首先遇到的是tom中定义的greeting，于是两条输出语句的结果都应该是“Hello from Tom!”，这不符合事实，所以按作者的说法所做的那个假设是错误的。

对于this这个关键字，我认为不应该扯什么作用域的事儿，只要向读者说明以下几项这样一句话就够了：函数作为哪个对象的方法调用，函数体内的this（不包括嵌套定义在其中的函数中的this）指向的就是那个对象。直接调用一个函数，相当于把它当作全局对象的方法调用。JavaScript 中没有类作用域的概念，因此方法内部要访问据以调用此方法的那个对象的属性，必须使用this关键字，按‘this.属性名’的语法来访问

1. 函数作为哪个对象的方法调用，函数体内的this（不包括嵌套定义在其中的函数中的this）指向的就是那个对象。
2. 结合new运算符调用一个构造函数时，系统会先自动生成一个对象，然后在该对象上调用构造函数。此时在构造函数体内，this指向的就是这个对象。
3. 直接调用一个函数，相当于把它当作全局对象的方法调用。
4. JavaScript中没有类作用域的概念，因此方法内部要访问据以调用此方法的那个对象的属性，必须使用this关键字，按“this.属性名”的语法来访问。

与这个问题相关的还有一个函数体内的名称解析的问题。我看过的JavaScript教材上都说得不太全面。实际上，那种直接引用的名称，其名称解析是在作用域链上进行的；而那种按“obj.属性名”方式引用的名称，其名称解析是在obj的原型对象链上进行的（首先检查obj是否直接定义了同名属性，如果没有，则在其原型对象链上逐层查找）。理解了这一点，就更能搞清前面的this与作用域的瓜葛。

谢廷晟，《JavaScript设计模式》和《深入浅出HTML》的译者。

    

1. 启动 Eclipse，然后选择 Help > Software Updates…。在出现的对话框中，单击 Available Software 选项卡。
2. 单击 Add Site…
3. 在 Add Site 对话框的 Location 字段中输入下面的 URL：https://dl-ssl.google.com/android/eclipse/ 注意：如果访问该插件时遇到问题，可以将 URL 中的 https 改成 http（使用https会更安全一些）。单击 OK。
4. 回到 Available Software 界面，应该可以看到 URL 中包含的插件列表，其中有 Developer Tools 一项。选择 Developer Tools 旁边的复选框，单击 Install…。
5. 在接来下出现的安装窗口中，应该会出现被选中的 Android DDMS 和 Android Development Tools。单击 Next。
6. 阅读并接受许可协议，然后单击 Finish。
7. 重新启动 Eclipse。

1. 启动 Eclipse，然后选择 Help > Install New Software。
2. 在 Available Software 对话框中，单击 Add…。
3. 在 Add Site 对话框的 Name 字段中，输入远程站点的名称（例如“Android Plugin”）。在 Location 字段中，输入下面的 URL：https://dl-ssl.google.com/android/eclipse/注意：如果访 问该插件时遇到问题，可以将 URL 中的 https 改成 http（使用https会更安全一些）。单击 OK。
4. 回到 Available Software 界面，应该可以看到列表中的 Developer Tools 选项。选择 Developer Tools 旁边的复选框，会同时选中 Android DDMS 和 Android Development Tools。单击 Next。
5. 在最后的 Install Details 对话框中，会列出 Android DDMS 和 Android Development Tools 等特性。单击 Next 阅读并接受许可协议，同时安装所有依赖组件，然后单击 Finish。
6. 重新启动 Eclipse。

* 译自http://developer.android.com/sdk/eclipse-adt.html。

之所以想到公开征寻技术审稿人，一是上一本书的样章吸引了120多位朋友的热情参与（“经典名著，精选样章”），几位热心的朋友在出版前也为我指出了一些问题，而这些问题在出版前都得到了妥善解决，保证了最终出书的质量；二是在今天这个开放的环境下，如果还延续那种一个人关起门来翻译的模式，不仅会显得译者自己缺乏公开的勇气，更会拖延译稿中问题的解决（译者无法解决书中全部问题很正常），影响出书进度。况且，样章早晚都是要放出来给潜在读者先睹为快的，后放不如早放，这样也有利于潜在读者提前了解这本书的价值所在和翻译质量——“先尝后买”嘛。

当然，征寻技术审稿人的主要目的，还是为了请领域专家来给译稿把关，尽最大努力来消除翻译中存在的错误或问题，确保最终出书的质量。下面就说一说对技术审稿人的要求：

1、对Android开发有浓厚的兴趣和一定的开发经验；
2、愿意花时间“先睹为快”并有能力指出错误和问题；
3、有一定的中文文字表达能力，能够看懂英文原文。

有意参与这本书技术审校的朋友，请给我发邮件（lsf.email[at]gmail.com）吧，邮件标题请填“Beginning Android 2审校”（以便过滤归类）。

声明一下：对所有参与审校的朋友，我会在译者序中具名致谢。对参与审校而且指出问题较多的朋友，届时将赠送样书（样书可以是本书中文版，或者我翻译过的其他图书，或者图灵公司出版的其他图书——届时我们可以再商量）。

另外，对于只是想“先睹为快”的朋友，也可以给我发邮件，邮件标题请填“Beginning Android 2试读”，我会给大家共享部分样章。

期待Android开发专家、高手、大牛、爱好者，伸出援手、不吝赐教！让我们共同携手，为Android开发社区和爱好者又快又好地奉献一本优秀的引进版图书。

Beginning Android 2

原文链接：http://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/
迈克·泰勒（Mike Taylor），2010年4月19日
翻译完成：2010年4月20日

有一些讲编程的图书，我会从头到尾、一字不落地反复研读；还有一些讲编程的图书，我已经看过好几遍了，但每次差不多都是只看其中的一章。乔恩·本特利（Jon Bentley）1986年的经典名著《编程珠玑》（Programming Pearls）则是少数几本能同时归入上述两类的编程图书之一，我手里这本书的封面已经严重磨损，下图可以为证（点击看大图，注意左下角。——译者注）。

（我有这本书的第1版[amazon.com，amazon.co.uk]，上面就是扫描的这一版的封面，好像我该买一本又新又便宜的第2版了[amazon.com，amazon.co.uk]，第2版比第1版多了3章内容。）

我打算最近再专门写一篇关于这本书的文章（我已经为Coders at Work、The Elements of Programming Style、Programming the Commodore 64 和The C Programming Language专门写了几篇书评），但今天我只想就这本书中的几段话谈谈自己的想法。这几段内容有点骇人听闻。

只有10%的程序员可以写出二分查找

每次翻开《编程珠玑》，我都会先看一看下面这几段文字：

几个小时！90%！老兄，严肃点！难道这还不够骇人听闻吗？

之所以想看这本书的第2版，原因之一就是想看看这几段文字有没有修订过，看看从1986年到1999年出第2版，这个数字有没有变化。直觉告诉我，这个数字一定向好的方向变化了，事物都是向好的方向发展的嘛。但理性却告诉我，在一个程序员把更多的时间都花在摆弄库上，而不是编写实际代码的时代，重现核心算法的能力即使有也一定会弱化。别忘了，本特利提到的那些家伙可都不是等闲之辈，他们都是贝尔实验室和IBM的专业人员。所以，我们有理由相信他们的成绩实际上已经是最好的了。

好，下面就做一个二分查找的测验

我跟你一样（如果你是这么想的），想马上就试一试。（好啦，不是马上。先看完这篇文章！）我相信看这篇文章的人都知道什么是二分查找算法，即使你不知道，上面引用的本特利的描述也应该够了。请你打开编辑器，编写一个二分查找例程。什么时候觉得没有任何问题了，保留那个版本。然后测试，然后通过在下面留言的方式告诉我你是不是第一次就做对了。我们肯定能打破本特利10%的纪录吗？

规则如下。

1. 使用你喜欢的任何编程语言。
2. 不要剪切粘贴或以任何方式复制别人的代码。甚至在你写完之前，都不要参考其他的二分查找代码。
3. 甚至于我不得不强调，别调用bsearch()，或使用其他瞒天过海的手法
4. 时间自己来定：5分钟不短——只要你能保证写完写对；8小时不长——只要你愿意（而且有那么多闲工夫）。
5. 可以使用编译器消除一些无意识的错误，如语法错误或变量初始化失败，但……
6. 在确定程序正确之前不要测试。
7. 最后，也是最重要的：如果决定参与这次测验，就必须报告。成功也好，失败也罢，甚至半途而废也要给我个话儿。否则，就无法保证测验结果的准确性了。

（考虑到这只是一次测验，可以忽略计算索引时导致的数值溢出。这里描述了相应的情形，但打算参加这次测验的人在编完程序之前不要看，因为那篇文章里包含一个正确的二分查找的实现，想洁身自好的朋友一定是不屑为之的。）

如果你的代码经验证确实正确，那么如果你愿意的话，欢迎你在留言里贴出自己的代码。不过，假如你这样做了，而后来的留言给你挑出了bug，请你一定想好怎样为维护自己的形象而自圆其说

更酷的玩法：对于那些信心十足的人，如果你真敢肯定自己的程序没有问题，可以先把代码贴在留言里，然后再测试。当然，你必须要在留言里说明这一点，以便大家发现你的bug时，会考虑多少给你留些情面。

我会在某个时间总结一下这次测试的结果——比如说，一周以后。

行动吧！

第一次更新（一个半小时后）

感谢朋友们的积极响应，这么快就有那么多留言！我得提醒大家，WordPress的留言系统会解释HTML，因此会吞掉类似下面的代码段

if a[mid] < value

最好的办法就是把源代码放在{source}…{source}标签之间，注意用方括号代替这里的花括号。（我第一次想告诉大家这一点时，使用的是方括号，结果我写的规避标记的说明，反而被当成了标记——悲哀呀！）这样做还可以保留缩进，否则我还不知道有什么办法可以做到这一点。

替WordPress向大家致歉：我真的希望这个平台允许留言者预览留言和/或在发表后还能编辑留言，这样就可以避免出现乱七八糟的代码了。我也想了办法自己动手解决这个问题，但WordPress不仅会错误地显示带有<符号的代码，它实际上会丢弃该符号后面的所有内容，唉，我想我是没折了。

第二次更新（在原文章发表4个小时后）

哈哈，你们这些家伙太出人意料了。仅仅4个小时，这篇文章的留言数就超过了以前的一篇文章保持的纪录（Whatever Happened to Programming此时的留言有206条）。

如果想看到相关的更多讨论，Hacker News中有不少不错的留言，另外Reddit的留言质量虽然差一点，但也值得一看。这些讨论把实际地编写代码看成只有精英程序员才会干的事。

原文链接：http://carsonified.com/blog/dev/john-resig-on-advanced-javascript-to-improve-your-web-app/
录音整理：http://carsonified.com/blog/author/keir-whitaker/
在线演示：http://ejohn.org/apps/workshop/adv-talk/index2.html

谢谢。感谢邀请我来这里的所有人。真的非常感谢。今天，我想谈两个话题，基本上是围绕jQuery展开的，但我会尽量照顾到那些没有使用jQuery的朋友，希望这两个话题对你们开发Web应用也会有所帮助。

在座的所有朋友在开发Web应用时，可能都要用到几种技术。我们总想提升JavaScript代码的性能，总想增强易访问性，让代码更简单一点。最后，我们还想让设计过程再容易一些。

说到性能，在JavaScript中有很多技术可以运用，其中有三个比较容易，而通过jQuery来实现则会更容易。一个就是事件委托。事件委托是一种绕过传统方法的事件绑定技术。我的意思是说，通常在为某个元素添加单击处理程序时，你都是为每个需要绑定单击事件的元素，分别绑定单击处理程序。这样做真的很浪费。如果有一个包含上千个单元格的表格，那么你就要添加大量的单击处理程序。

事件委托，就是在你添加处理程序时，要添加到DOM树上层的某个父元素上。比如，添加到表格上，而不是添加到每个单元格上。这样就可以利用浏览器原生的事件冒泡机制。也就是说，用户在单击某个单元格时，事件会沿DOM树向上冒泡，冒泡到表格，而你可以在这个时候再处理它。这就是事件委托。

这样一来，你只要为文档添加一个事件就行，根本用不着添加几千个。而且速度又快，灵活性又高。为此，jQuery提供了两个方法；一个是“dotlive”（.live()）。另一个则是我们前几天刚刚添加的方法，即“delegate”（.delegate()）。关于委托，除了它的速度快之外，我认为真正有价值的地方在于，它对所有当前乃至未来的元素都有效。即便现在文档中只有一千个单元格，而你又添加了一千个，它照样还是有效。你不用为处理新增的单元格而添加新处理程序。

委托方法（.delegate()）是这几天我们刚刚加进来的。这个方法的本质就是将委托的概念具体化了。下面我想讲一个实际的例子。假如你想为某个核心元素，例如表格，添加单击事件。然后你还要监视（这个表格中）任意单元格上的悬停事件。那么，只要编写短短几行代码，很快就可以实现你的意图。

$(“table”).delegate(“td”, “hover”, function(){
$(this).toggleClass(“active”);
});

实时事件（.live()）则是另外一种编写和实现委托的方式，但关键是它能起作用，并且看上去与事件绑定的效果还完全一样。你可以使用相同的语法，可以使用选择符，然后可以直接给它添加事件，或者至少看起来是直接的。而在后台，jQuery会帮你周旋并确保一切都各就各位。

举个例子，我们这里在鼠标悬停时会显示一些菜单，子菜单在消失时带一个小动画。有意思的是，如果我们又添加了新菜单，这个新添加的菜单也会带有相同的动画。这时候，动画效果的添加就是实时的。而且，不管是对页面中当前还是将来的元素，也都会持续有效。（点击这里查看交互演示。）
$(“a.menu”).live(“hover”, function(){
$(this).next().toggle(200);
return false;
});

[未完待续……]

前不久，杰夫、我，还有埃里克一块参加Stack Overflow Podcast的在线聊天。哥几个针对版本控制问题，狠狠地发了一通牢骚。特别是大批特批了以Mercurial和Git为代表的、新潮的DVCS（Distributed Version Control System，分布式版本控制系统）。

聊天中，我说：“我觉得，用它们来做分支和合并更简单，恰恰说明了你的同事可能会做更多的分支和合并。结果呢，就是你会把自己绕进去，最后非晕菜不可。”

说实话，你们也猜得到，参加那种聊天活动，不需要事先准备什么，不过是几个人东拉西扯地闲聊天而已。既然是闲聊天嘛，就免不了说错话，或者用技术术语来说就是——犯错误。要么哪句话里有错误，要么出发点有错误，要么就是出发点和话里都有错误。但这一次，我犯了一个低级错误。就像草莓配比萨、辣椒配面包，属于那种低级得不能再低级的错误。

在这次聊天之前，我们团队已经切换到Mercurial很长时间了，但这次切换真的把我搞晕了，我不得不花钱请人替我check in代码（开个玩笑）。不过，有一段日子我确实不好过，因为我得记住几个关键的命令，想象着自己是在Subversion中使用它们，期待能看到熟悉的结果。可是，一旦碰到结果跟我想象得不一样，我就会大惑不解。为此，我经常得颠儿颠儿地跑到楼下大房间里，请教本杰明或者雅各布。

你猜我的团队怎么说，“哎，乔总，这‘水银果汁’^[注1]太神了，我们打算用实际的产品代码来测试一下它。另外，还有，这一点更重要，我们发现了一个大市场，我们可以为它提供有偿技术支持和托管服务。”（Mercurial是基于GPL的自由软件，但有不少公司在决定使用什么之前，总会需要某种支持。）

我心里想，你们问我，我问谁？你们都知道，我在公司并不真正作主，因为“管理的职能就是提供支持”嘛。然后，他们就把所有6名实习生都组织起来，动手开发基于Mercurial的产品。

真不能再拖下去了，我必须得尽快弄明白，所谓的“分布式版本控制”到底咋回事。免得我们公司的产品都上市开卖了，人家让我介绍产品，我自己都说不出个子丑寅卯来。那样的话，博客圈里又会有人跳出来，对我指手画脚，说我糟蹋好东西了（junking the sharp）。

于是，我学呀，学呀，最后终于闹明白了。今天，我想跟大家在这里分享一下。

在分布式版本控制系统中，所谓的“分布式”其实不是最关键的。

最关键的是在使用这些系统时，你时刻要想着“更改”，而不是“版本”。

我明白，这里边其实有几分“道可道，非常道”的意味。在使用传统的版本控制系统时，你会想：嗯，这是版本1，这是版本2，这是版本3。

而在使用分布式版本控制系统时，其实我不用想版本。我只要想，我做了这些更改，我又做了另一些更改。

“程序模型”变了，“用户模型”也得跟着变。

在Subversion中，你可能会想，“要保证我的版本跟主版本随时一致”，或者“恢复到前一个版本”。

在Mercurial中，你会这样想，“看看雅各布的更改”，或者“我们先不用考虑那些更改”。

如果你在使用Mercurial时，心里想的是Subversion，多数情况下倒也问题不大；但是，万一出了问题，你就会找不着北、会不高兴，最后因为无计可施而恨上Mercurial。

可是，如果你能够解放思想，换一个角度来看版本控制，就能悟出管理“版本”与管理“变更”的差异所在。你会觉得豁然开朗，由衷地感叹这才是控制版本的最佳方式。

没错，是有点异样的感觉——从1972年至今，所有人关注的都是怎么管理版本，而今天，人们突然要去关注更改本身了，能不感觉异样吗？而且，关注更改解决了一个非常重要的问题：合并分支代码。

这一点最重要了。没错，在长达10年的时间里，我们深刻地体会到，这一点对提高开发效率最为重要。重要到了什么程度呢？重要到在我今天最后一次谈软件时，必须要反复强调它。好了，如果你只想记住一句话，那就记住下面这句：

在管理更改而非管理版本时，合并很容易做到，你可以根据工作需要随时创建分支，因为合并已经是小菜一碟了。

记不清有多少个使用Subversion的用户，曾对我说过下面这番话：“用它创建分支代码的时候，没什么问题。但是，等到要把分支合并到一块时，那个费劲啊，我们不得不手工重新应用每一次更改。我们发誓，这种蠢事一辈子也不会再干了。结果，我们想出了一个开发软件的新主意，就是用if语句，不用分支。”

有时候，他们在提到自己发明的这种一个主干的做法时，甚至还有几分得意。好像弥补了自己版本控制工具的不足，就可以流芳百世了。

使用分布式版本控制系统，合并简单，还不会出错。所以，你可以创建一个稳定的分支、一个开发分支，还可以为QA团队创建一个长期使用的分支，以便在实际部署之前进行测试。当然，还可以创建一个临时分支，用它来验证各种想法，观察结果。

这一点太重要了，怎么强调它都不算过分。自从我10年前开始写博客以来，这恐怕是我笔下的软件开发技术领域中最大的进步了。

或者，可以换一种说法，如果我要放弃Mercurial，除非是我想再使用C++。

如果你还在使用Subversion，停止使用。马上停止使用。Subversion＝水蛭。Mercurial＝抗生素。我们现在有更好的技术了。

很多人在没有完全理解这种新程序模型的情况下，往往会盲目地使用Mercurial，而这容易让人觉得它有问题，不可靠。为此，我专门写了一套Mercurial教程，叫做HgInit^[注2]。

如今，要是有人问我那次聊DVCS时为什么要贬低DVCS，我会告诉他们那是我精心设计一个圈套，我是在放烟雾弹，目的是要迷惑我的老朋友和老竞争对手埃里克——他在开发一个非分布式的版本控制系统。就像上一次他要卖bug追踪软件一样。那一次，为了惩罚他，我们用一个特制的信封寄给他一个非常值钱的Fog Creek双肩背包。让他觉得我们会在圣诞节的时候，也会把这么值钱的背包作为圣诞礼物，送给所有FogBugz软件的客户。

我的博客写到今天，时间已经够长了。10年来，大家能够坚持阅读我写的文章，是我莫大的荣幸。这个博客的读者群能达到今天这个规模，是我当初做梦也想不到的。无论你是谁，是花自己的时间把我的文章翻译成40多种语言的那几百位志愿者中的一员，是给我写过电子邮件的22 894位朋友中的一位，是订阅了我的邮件简报的50 838名订阅者之一，还是每年2 262 384位访问这个站点并阅读了我写的1 067篇文章中哪怕只言片语的读者中的一位，我都要由衷地感谢你，感谢你对我的关注。

翻译无小事：要有使命感

当你录入每一个字的时候，无论正确或者错误，优雅或者蹩脚，它都有可能（如果没有在你自己日后的审查或者出版社的编审环节中被发现和解决的话）变成历史，保存在大大小小的图书馆里，被成千上万的（纸书和网络连载、电子版的）读者看到并对他们产生影响。

很多技术书，首印以后可能不会重印，所以，错误可能永远留在那里。勘误表当然能起到一定作用，但是请注意，我们没有办法将勘误表送到每个读者手里。而且，想想拿着勘误表在书上改正，该是一件多么痛苦的事情。

翻译无易事：不要过于自信

著名翻译家傅雷当年全职在家里专事翻译，呕心沥血，不过“日译千字 ”。（当然，我们毕竟翻译的是技术文档，难度和要求都小得多，我见过有经验的译者全职翻译每日万字左右的。）

有的译者会说：“这本书我读起来很轻松啊，翻译没问题！” 其实，翻译和阅读不同，能差不多看懂，和逐字逐句转变成地道流畅的中文，让读者（可能包括基础稍差的）在不接触原文的情况下容易地理解原作者所说的意思，基本上不是一回事。

有的译者会说：“这本书里的技术我很精通，翻译起来很容易。” 其实，翻译书的时候，所面临的技术问题相对较少（因为书往往是自成一体的，凡事多有来龙去脉。但是注意，只是相对！你很可能遇到自己不熟悉甚至根本不懂的技术领域），除了有些原书代码、叙述等等本身就有错，一般不难解决。毕竟你把开发环境架起来，试一下，基本上都可以搞定。 常见的错误，反而更多是因为英文本身不理解或者误解造成的。往往一个小小的复数、this、the、被动语态、and等连词的翻译或者理解错误，会造成整句、整段甚至多段的译文难以理解，或者逻辑错误。

翻译之难在于，它不仅考验你的：

1. 技术能力 。一本书涉及的技术内容可能很丰富，一个译者不见得能够全部精通。
2. 英文水平 。我们这一代的人所受的英文教育，基本上是不能轻松应付翻译这种工作的。
3. 中文水平 。理工科出身的我们，语文最多只是中学水平，而且教法学法很畸形。大家应该都有同感。

更考验你的：

4. 研究能力 。翻译中肯定会遇到技术或者非技术的词和短语你没见过、不知道的，而且有不少词和短语字典里也没有现成答案。
5. 逻辑思考能力 。英语很多句子里的代词和其他意义不那么明显的表达，需要通过上下文的逻辑思考进行推断。
6. 知识面 。原作者会追溯历史，讲很多老的技术，也会纵横开阖地进行横向比较，涉及很多其他平台或者技术（有些还很冷僻）。原书里还会有很多仅限于欧美文化 （名人名言、历史、地理、游戏、影视、歌曲……）的比喻、闲话等等。比如计算机书里常常出现的Yogi Berra。
7. 耐力 。翻译往往要持续数月，而且大部分同学肯定都是业余工作，深夜孤灯，而且一本书里肯定有你不喜欢或者没感觉的部分，但是还是得翻译出来，其辛苦程度可知……
8. 细心 。毛糙的译者交出的稿子，错别字、标点符号、术语一致性都会是大问题，更令编辑头疼的，还可能存在大量零散的漏译、英文拼写错误，以及最严重的，因为 粗心而造成的严重漏译（有时候单复数没有看清楚，指示代词没有理解对，会造成整句的误译；有时候连词的误译，会弄反整段话的逻辑）。
9. 沟通能力 。翻译往往不是一个人完成的，而且所有译者都要和编辑打交道。不及时沟通，可能造成整个项目的失败——因为交稿延期或者稿件不符合出版社要求、编辑工作时间很长，最终出版进度一拖再拖，出书的时候已经过时或者没有市场了。
10. 交际圈 。遇到自己无法解决的问题，尤其是特定领域的问题，需要相关的专家支援。

翻译无难事：也没什么大不了的

翻译毕竟只是一种转换别人现成文字的工作，并没有什么完全无法克服的困难，何况我们面对的知识技术文献而已，含义基本准确固定，对艺术性没有太多要求。

只要做到以下这几点，翻译就没什么大不了的。

1. 多想：带着逻辑思考去翻译。

翻译本身大多时候是在词、短语和子句的层次工作，但是思考层次必须提高。一本书都是从总到分逐层细化的树状结构，翻译时脑子里要有更大范围的上下文。

和 阅读时应该在脑子里读出作者的逻辑脉络（这一章先讲了什么，又讲了什么，这一点又分为几部分、几个步骤……，对于这个问题，先说了Solution A，然后又说了Solution B，C，A的问题是……，B的问题是……，C克服了这些毛病……作者对这些选择的态度是A不好，B不好，C好……）一样，翻译时也要有类似的脑图。

翻译一个词时，要考虑全句、全段、上下几段甚至全节、全章和全书的整体思路和作者倾向。

另 外，原书是肯定会有错的，像Effective Java那样的名著，曾经被日文版译者找出大量错误。我们所出的《SQL解惑》一书，作者虽然是世界级权威，但是我们的译者也发现了大量错误。按照逻辑， 根据自己的技术基础，可以发现各种错误。整理勘误表，提供给编辑，反馈给原作者。

2. 多查：善于利用工具。

傅雷当年“日译千字 ”，有论者说，是因为没有那么方便的工具。的确如此。今天，任何问题在没有充分查找的情况下，就说无法解决，都是不负责任的。

图灵公司的论坛 （实名制，需要提供自己的个人信息进行申请）上有一个网上的词汇表 ，收集了很多常见的不容易处理、有歧义的术语、习语以及其他词语的译法，请优先参考。

我们不仅有很好的英语字典、够用的中文字典，而且有方便的网上内容，Wikipedia、FreeDictionary。当然，还有Google等等搜索引擎。有了Google、有道这样的语料库，基本上没有什么问题是无法解决的。请参考：图灵推荐工具 。

高效查询的关键在于，该查的时候一定要查！其次，要知道上哪里查比较权威。直接Google的结果，往往会误导你，迷糊你。

专有名词（人名、公司名、电影名……）不知道一定要查，否则你很可能连他说的是什么都没有搞清楚！这种笑话非常常见，我见过一个稿子，把某乐队的专辑翻译成什么纪念册的……

当然，知道这是个专有名词，有时候也是需要智慧的。

不熟悉的术语、领域名词一定要查，否则就会翻译得牛头不对马嘴，轻者也是外行话。

译文里想用成语、典故或者比较少见的自己不太有把握的词，也请查中文字典。这些少见词往往不能望文生义，往往感情色彩比较特别（贬义多）。对自己的中文水平要有正确认识。比如“明日黄花”而不是“昨日黄花”。再比如“望其项背”只能用否定。

3. 多问：善于利用别人。

谁也不是全知全能，百科专家。有时候，问对了人，比自己查找、研究半天，效果好得多。

请记住，你不是一个人在战斗。

图灵公司有经验丰富的编辑，他们看过无数类似或者相关的稿件，很可能你的问题早已经被解决了。遇到问题，请多多与编辑沟通，不要企图隐藏或者糊弄过去 。对编辑的修改意见，不要轻易否定，尤其是标准、规章、规矩性的要求，请尽量遵守。
如果在稿件中对原文有比较特殊的处理（原文有错，对原文的句序、句式、说法等等有较大改变，原文某句不宜翻译，或者翻译出来对中国读者无用、无效、无意义，等等），没有按照原文翻译，请在稿中用批注说明，不要让编辑再浪费时间琢磨 。
请一定加入图灵俱乐部论坛 ，有许多和你一样在翻译和曾经翻译过书的译者以及行业内的专家，会为你分忧，和你讨论。

4. 开放：多一双眼睛总是好的。

我们要求译者将序、前言、致谢和前三章内容翻译完毕之后，尽快贴到图灵俱乐部论坛 上，接受内部审读。

我们也要求编辑将修改意见更多地开放，接受更多人的检查。

我们鼓励译者在个人网站、blog、论坛等等场合在征得编辑的同意后，公开少量章节的翻译草稿，听取广大读者的意见。一般章节开放数量不能超过原书的四分之一。而且必须在最前面写上：
“本文节选自即将由人民邮电出版社图灵公司出版的《XXX》（英文版XXXXXX）一书，已经过图灵公司授权，如需转载，请与contact@turingbook.com联系。”

5. 翻译完了自己再看一遍

这一点虽然容易，但是一般都做不到。许多错误被编辑发现之后，译者第一个反应会是，啊，这个怎么都错了！为了防止自己犯被读者痛骂、被啐一脸口水、被扔一身鸡蛋的错误，谨记。

最后两点重要的说明

1. 翻译中，发现任何涉及意识形态（说到中国、共产主义、共产党、社会主义、马克思主义等等）、政治、民族（尤其是藏族、维吾尔族、回族）和宗教以及其他敏感话题，请在稿中突出（颜色、下划线加批注）标出，提醒编辑，由编辑来处理。

2. 翻译中，遇到自己不懂、不好解决的问题，首先要多查多问。如果在交稿前仍然没有解决，请在稿中突出（颜色、下划线加批注）标出，提醒编辑，由编辑来处理。千万不要掩饰、隐藏起来，铸成大错。

另外，特别推荐思果先生的翻译原则 ，请反复体会：

上个月，我又参加了Mozilla公司组织的一次研讨会，这一次讨论的是Web数据库。虽然研讨会的议题很有意思，但我觉得会议期间大家对另一个问题的争论似乎更值得关注。争论中，与会者针对浏览器到底应该为JavaScript提供什么样的API分成两派。一派坚持认为原生的JavaScript API应该尽量保持低级化，然后由库开发者在低级API基础上再去构建更好用的接口。另外一派，也是我所在的阵营，则认为中级API才是大势所趋。没有人认为浏览器应该向开发人员提供高级API。所谓低级、中级、高级到底都是什么意思呢？

低级API

低级API仅为提供基本功能而设计。由于只要能实现相应功能即可，因此这种API不需要很直观或者很好理解。有时候，低级API确实会给初级甚至中级开发人员造成理解上的困难。这样一来，借由人们频繁使用来发现相应API问题的机会就大为减少了。大家都会指望库开发者在这些低级API基础上实现直观、好用的API，以便于普通开发人员使用。doument.cookie就是说明低级API最好的一个例子。

作为JavaScript开发人员操作cookie的唯一接口，document.cookie可谓有史以来最难使用的一个API。关于cookie，我专门写过一篇文章，还探讨过它的安全性问题，其中都涉及到如何在JavaScript中使用它们；因此，这里只能算是一个简单的介绍了。要设置cookie，必须以正确的cookie格式来设置document.cookie属性，例如：

document.cookie = “name=Nicholas; domain=nczonline.net; path=/; expires=Sat, 02 May 2009 23:38:25 GMT

要取得cookie，则需要读取document.cookie，返回的字符串是如下列所示的名值对格式：

name1=value1; name2=value2; name3=value3; name4=value4

而为了得到想要的值，必须先从这个字符串中查找相应的名字，然后再解析出相应的值。

之所以把这种API归类为低级API，是因为其实现要求你必须先了解cookie的内部格式，然后才能使用它。实际上，document.cookie属性只是在简单地模仿Set-Cookie和Cookie这两个对开发人员不可见的HTTP首部。为了写cookie，必须要理解字符串的确切格式，这涉及到其中的名和值必须采用URI编码形式，而其他片段之间必须以一个分号和一个空格来分隔，此外还必须知道设置过期日期的正确日期格式。反过来也一样，在读cookie时，你同样需要知道返回的字符串是什么格式，然后才能从中解析出想要的数据。这就是所谓的“遇繁不简，遇简也不简”。一句话，这种API对于不了解cookie的人根本没有用。

如果大多数开发人员都不会直接使用某个API，你就可以说它是低级API。不用，是因为使用它们所需的知识储备（Cognitive Overhead）太多了。绝大多数开发人员在使用JavaScript读写cookie时，最终都会求诸于一个JavaScript库例如YUI中的Cookie工具（YUI2和YUI3），这些工具把那些令人讨厌的实现细节都隐藏起来了。

这正是那些低级API的支持者所愿意看到的：浏览器应该只提供基本功能，而基于这些功能开发易用API的任务应该交给开发人员社区。这些人支持低级API有一个主要的理由，即围绕基本功能可以实现任何层次的抽象，开发人员也会因此获得更多选择，从而更好地利用基本功能。

低级API的问题在于浪费时间。如果你创建了低级API，那结果就是潜在用户的数量会很少。至于什么时候能够出现好用的抽象工具，只能指望某一天这些用户中有（一个或几个）人会意识到确实有必要去做这件事，以便其他社区人员更好地利用该API。如果你想让新API尽快地被别人使用，你就会明白应该怎样去改进它，低级API根本不合适。

提示：大多数服务器端语言（如 ASP.NET、JSP、PHP）都提供了读写cookie的原生抽象，但JavaScript始终都没有。

高级API

这一争论的另一个极端是高级API。高级API设计出来就是为了让开发人员直接使用的，并且一般都非常直观。这种API不仅要考虑提供某种功能，而且还要提供使用相应功能的友好、易用的接口。高级API设计首先考虑的是开发人员的方便，因而通常需要对开发人员使用API的方式从理论上作出归纳。显然，这又是一个问题：谁能确切地知道某个人希望怎么去使用一个API呢？因此，在浏览器中提供原生的高级API几乎就是一个不可能完成的任务。

各式各样的JavaScript库就是高级API的典型例子。这些库都面向相同的浏览器，但为实现相同功能而提供的接口却差别很大。使用jQuery的方式与使用YUI截然不同；这是件好事，因为开发人员可以选择。可是，如果你告诉YUI开发人员必须使用jQuery语法写代码——因为只能使用一种语法；或者相反，会怎么样呢？相信对此提出抗议的开发人员一定会成群结队。强迫人们必须以某种方式开发是不幸之源。只有抽象，或者说只有随时都可以提高和降低抽象级别，才会让开发充满乐趣，也才能激励开发人员不断地创新。

高级API要求的知识储备非常低，因此开发人员无需了解太多就可以直接使用。但值得高兴的是，没有人认为浏览器应该提供高级AIP。大家都希望有所选择，都希望不同程度的抽象。

中级API

折衷方案是中级API。以我的观点来看，中级API是浏览器所应该研究和实现的。顾名思义，中级API处于低级和高级之间，兼具二者之长。所谓中级API，（我的定义）就是针对最常见的应用提供简单的接口，同时能够通过扩展实现更强大的操作和对不常见应用的支持。第一部分，常用的接口，是非常简单、无需抽象即可直接使用的。而不常用接口可以更复杂一些，甚至可以“让人摸不着头脑”，因为很少会有人用。

XMLHttpRequest是不错的中级API中最出色的例子。使用它最常见的情形就是发送一次GET请求，然后取得XML数据。实现这个过程的代码不多：

var xhr = new XMLHttpRequest();
xhr.open(“get”, “/somexml”, true);
xhr.onreadystatechange = function(){
if (xhr.readyState == 4){
if (xhr.status == 200){
process(xhr.responseXML.getElementsByTagName(“item”));
}
}
};
xhr.send(null);

虽然有人会说onreadystatechange这个事件处理程序看起来有点麻烦，但实际上，你要做的不过是检查一点信息，以确定是否接收到了正确的数据。可是，所有必需的信息都已经各就各位了，而且也已经转换成了方便访问的格式：HTTP状态就在那摆着，而XML也已经转换成了DOM格式。为了给你提供这些数据，API已经做了不少的工作了。

另一种不太常见的用法就是在URL中包含提交的表单数据。虽然代码难看点，但仍然可以接受：

var xhr = new XMLHttpRequest();
xhr.open(“post”, “/add”, true);
xhr.setRequestHeader(“Content-type”, “application/x-www-form-urlencoded”);
xhr.onreadystatechange = function(){
if (xhr.readyState == 4){
if (xhr.status == 200){
signalComplete();
}
}
};
xhr.send(encodeURIComponent(name) + “=” + encodeURIComponent(value));

除此之外，你当然还可以把XMLHttpRequest对象用于更复杂的处理中，例如Comet。问题的关键在于，它在常用情形下很简单，而且还能轻易地支持更复杂、更不常见的用例。这样一来，JavaScript库也容易在后台构建一个比较好用的接口，帮我们处理那些复杂应用下的琐碎细节。尽管每个JavaScript库在如何发起Ajax通信方面各有各的方式，但XMLHttpRequest接口的设计能够很好地适应所有方式。

注意：有些人认为XMLHttpRequest也属于低级API。我承认它不是最清晰的API，但在常见用例中它确实非常简便易行。不要忘了，最初在设计这个对象的时候，常见用例就是从服务器上取得XML数据。从那个时候到现在，常见用例已经变了，但人们照样还在使用同一个API。在我看来，这恰恰表明了它是一个不可多得的中级API。

总结

我主张浏览器应该原生提供中级API，这样才能自如地应对常见用例，同时还可以为不常见的用例留下扩展的空间。API的抽象程度太低，不利于广泛流传，更不容易引起开发社区的重视；API的抽象程度太高，由于限制的用例太专，人们要么能用，要么根本就用不了。目前来看，较新的API似乎有低级化的倾向，如此一来，开发人员在实际使用它们之前，往往需要有第三方来实现一些必要的抽象。我希望能够阻止这种趋势，好让常见用例实现起来更简单，以便人们能够立即使用它们，同时还可以对它们加以扩展。而中级API能够同时满足这两个条件。

从诞生至今的大部分时间里，焦虑、抨击、蔑视和误解一直与JavaScript如影随形。JavaScript刚刚问世那几年，很多“严肃的程序员”都认为它不够严肃。

相比之下，.COM泡沫时期加入Web开发行列的许多文科生，则普遍觉得JavaScript深不可测、晦涩难懂。就算那些耐力和韧性俱佳者能够把JavaScript琢磨得很透，但仍然摆脱不掉竞争性浏览器提供的不同实现给他们带来的麻烦。凡此种种，最终导致粗制滥造的脚本越来越多。另一方面，拜Web前端代码的无比开放性所赐，各种坏习惯不断从一个站点被粘贴进另一个站点的源代码中。那些实现活该臭名昭著，可是，JavaScript这门语言也因此被严重拖累，背上了不该有的坏名声了。

2001年前后（随着Internet Explorer 6的发布），浏览器实现已经大为改进，Web开发实践也开始得到改善，呈现出了二者水乳交融的局面。作为Ajax核心的XMLHttpRequest对象正慢慢地为人们所发现，一种新的桌面风格的用户交互模式出现在浏览器中。允许JavaScript操作Web文档结构和内容的DOM API已经定型。而CSS，不管人们如何曲解或者无视它，也无论浏览器开发商怎样丧心病狂地实现它，都已经成长得足够茁壮，它的美妙和反应敏捷令它能够与新的Web交互能力配合无间。最终，JavaScript一扫颓势，变得令人惊诧、让人兴奋、使人敬畏。想想2004年第一次使用Google Maps时的情景吧，那种感觉你或许还记忆犹新。

Google Maps是新兴应用程序的典型代表。这类浏览器编程与后端编程并重的应用程序，不禁令人对Web浏览器窗口中那块“画布”的未来浮想联翩。（除Google Maps之外，早在2003年就基于网页邮件客户端提供类似Outlook功能的Oddpost，也是这类应用程序的一个了不起的先驱。）随着这类应用程序如雨后春笋般大量涌现，以及支持它们的浏览器的市场份额不断攀升，一个Web应用全面复兴的时代真的到来了。“Web 2.0”诞生了，Ajax也成了“IT”技术。Web似乎在一夜之间脱胎换骨，重新激发起了人们的兴趣。而JavaScript作为唯一的Web编程语言，也变得更有意思了。

有意思，但用好它却不简单。JavaScript以及在DOM和BOM中为其定义的API不一致的实现，给跨浏览器编程造成了比原本大得多的困难。前端设计行业还远未成熟。大学教学计划并没有（至今仍没有）做出相应的调整，以满足相关的培训要求。

到2004年底，JavaScript无疑已经成为最重要的编程语言。但从学术角度看，它依然不具备进入一类学科的资格。Web虽然已经翻开了新的一页，但在培养足够的知识全面、训练有素的人才方面，我们依然面临着严峻的挑战。

为此，很多技术作者挺身而出，撰写了不少有关JavaScript的图书。几年来，这类书虽然也出了不下几十本，但总体来说仍然不尽如人意。其中有的在推销与落伍的浏览器有关的技术，有的则在卖弄容易剪贴但却不好扩展和维护的技术。让人想不通的是，许多JavaScript图书让人觉得作者好象并不真正喜欢JavaScript，或者他们不认为读者应该喜欢它，再或者他们根本不相信读者能够完全理解JavaScript。

2005年，Nicholas C. Zakas这本书的第一版面世，为前端工程领域奉献了一本真正的好书。当时，我和雅虎的同事们正在创建YUI（Yahoo! User Interface Library，Yahoo!用户界面库），打算将其作为公司前端工程的基础，同时也借以推广我们这门新学问的最佳实践。每到周五，我们就聚到一间教室里讨论前端工程，也向大家讲解JavaScript、CSS以及在浏览器中创建Web应用程序的知识。我们从已出版的高级JavaScript及DOM脚本编程方面的图书中认真挑选了几本，想让新工程师通过它们掌握如何构建耐用、基于标准且容易维护的Web应用程序。Zakas的书一出版，马上就被选为我们的JavaScript内部培训课本。

从那时起我们就一直使用他的书。我们一致认为这本书太有用了，于是就跟Zakas商量，让他加入雅虎帮我们建立公司的前端工程社区。

Zakas在书中传达的理念与众不同——JavaScript既需要严肃认真地对待，但也是完全可以理解和掌握的。如果你是个程序员，这本书会告诉你JavaScript与各种编程语言的关系，以及如何运用你已经习以为常的各种编程模式。你可以理解JavaScript的继承机制及其固有的动态特性（虽不合传统，但却十分自由十分强大），可以从Zakas这位尊重和理解JavaScript的同道那里学会欣赏JavaScript这门语言。

如果你曾经是一名文科生，在网络泡沫时期步入了这个行业，至今也没有转行，而且想要弥补自己在JavaScript方面的不足，你会发现Zakas是一位难得的良师益友。他可以帮你实现从“会做”到“做好”的转变。他能让你认真地理解这门严肃的学问。最重要的是，他不会让你先入为主地产生对这门语言应该理解多深的想法。相反，通过他严肃、耐心、通俗易懂的讲解，你自然而然地会对这门语言有同样深刻的认识。

本书是经过扩展、更新和改进后的第二版，删除了上一版中与今天的职业需求无关的主题，并用我们在2005年至2008年学习的新知识更新了剩余的内容。这几年是JavaScript发展的重要时期，Zakas则始终位于最前沿孜孜不倦地学习这些新知识。他这些年一直在致力于建造新一代最流行的Web个人门户（My Yahoo!），以及开发Web上最受欢迎的站点（Yahoo!主页）的新版本。Zakas以他作为老师和作者的独特视角，筛选出由这些超复杂、超大型应用程序磨砺出的经验，并将这些经验融入到了本书的字里行间。

他给出的解决方案远远超出了一本好书的范畴，只有每天都与代码同呼吸共命运的人，才有可能与读者分享如此具有实用价值的知识。

说实话，本书新版的面世对我和各位读者而言真是个莫大的喜讯。因为它的内容比上一版更有价值、更能反映JavaScript最新的发展成果，因此也更加令人不可错过。

埃里克·米拉利亚（Eric Miraglia）
YUI高级技术经理 哲学博士
于加利福尼亚州森尼维耳市

昨天，我负责了Yahoo!公司组织的一次面试活动，感触颇深的是其中的应聘者提问环节。我得说自己对应聘者们提出的大多数问题都相当失望。我希望听到一些对在Yahoo！工作充满激情的问题。在昨天的应聘者中，只有一个人的问题是我认为最好的，那个人问我：“你觉得怎么才能成为优秀的前端工程师？”我觉得很有必要把这个问题从面试房间里拿出来讨论一下。

首先，前端工程师必须得掌握HTML、CSS和JavaScript。只懂其中一个或两个还不行，你必须对这三门语言都很熟悉。也不是说必须对这三门语言都非常精通，但你至少要能够运用它们完成大多数任务，而无需地频繁地寻求别人的帮助。

优秀的前端工程师应该具备快速学习能力。推动Web发展的技术并不是静止不动的，没错吧？我甚至可以说这些技术几乎每天都在变化，如果没有快速学习能力，你就跟不上Web发展的步伐。你必须不断提升自己，不断学习新技术、新模式；仅仅依靠今天的知识无法适应未来。Web的明天与今天必将有天壤之别，而你的工作就是要搞清楚如何通过自己的Web应用程序来体现这种翻天覆地的变化。

计算机科学这个大门类下面的许多分支在人们眼中实际上都不外乎科学。但是，我们所说的前端不是什么科学，而是艺术。艺术家不仅要掌握谋生的技术，还要懂得如何运用。对同一个问题的解决方案在这种情况适用，在另一种情况下可能就不适用。对Web应用程序的前端而言，解决同一问题的方案经常会有很多。没有哪个方案是错的，但其中确实有一些是更合适的。优秀的前端工程师应该知道在什么情况下使用哪种方案更合适，而在什么情况下应该重新选择。

优秀的前端工程师需要具备良好的沟通能力，因为你的工作与很多人的工作息息相关。在任何情况下，前端工程师至少都要满足下列四类客户的需求。

1. 产品经理——这些是负责策划应用程序的一群人。他们能够想象出怎样通过应用程序来满足用户需求，以及怎样通过他们设计的模式赚到钱（但愿如此）。一般来说，这些人追求的是丰富的功能。
2. UI设计师——这些人负责应用程序的视觉设计和交互模拟。他们关心的是用户对什么敏感、交互的一贯性以及整体的好用性。他们热衷于流畅靓丽但并不容易实现的用户界面。
3. 项目经理——这些人负责实际地运行和维护应用程序。项目管理的主要关注点，无外乎正常运行时间（uptime）——应用程序始终正常可用的时间、性能和截止日期。项目经理追求的目标往往是尽量保持事情的简单化，以及不在升级更新时引入新问题。
4. 最终用户——当然是应用程序的主要消费者。尽管我们不会经常与最终用户打交道，但他们的反馈意见至关重要；没人想用的应用程序毫无价值。最终用户要求最多的就是对个人有用的功能，以及竞争性产品所具备的功能。

那么，前端工程师应该最关注哪些人的意见呢？答案是所有这四类人。优秀的前端工程师必须知道如何平衡这四类人的需求和预期，然后在此基础上拿出最佳解决方案。由于前端工程师处于与这四类人沟通的交汇点上，因此其沟通能力的重要性不言而喻。如果一个非常酷的新功能因为会影响前端性能，必须删繁就简，你怎么跟产品经理解释？再比如，假设某个设计如果不改回原方案可能会给应用程序造成负面影响，你怎么才能说服UI设计师？作为前端工程师，你必须了解每一类人的想法从何而来，必须能拿出所有各方都能接受的解决方案。从某种意义上说，优秀的前端工程师就像是一位大使，需要时刻抱着外交官的心态来应对每一天的工作。

我告诫新来的前端工程师最多的一句话，就是不要在没有作出评估之前就随便接受某项任务。你必须始终记住，一定先搞清楚别人到底想让你干什么，不能简单地接受“这个功能有问题”之类的大概其的说法。而且，你还要确切地知道这个功能或设计的真正意图何在。“加一个按钮”之类的任务并不总意味着你最后会加一个按钮。还可能意味着你会找产品经理，问一问这个按钮有什么用处，然后再找UI设计师一块探讨按钮是不是最佳的交互手段。要成为优秀的前端工程师，这种沟通至关重要。

无论从哪个方面讲，我都觉得前端工程师是计算机科学职业领域中最复杂的一个工种。绝大多数传统的编程思想已经不适用了，为了在多种平台中使用，多种技术都借鉴了大量软科学的知识和理念。成为优秀前端工程师所要具备的专业技术，涉及到广阔而复杂的领域，这些领域又会因为你最终必须服务的各方的介入而变得更加复杂。专业技术可能会引领你进入成为前端工程师的大门，但只有运用该技术创造的应用程序以及你跟他人并肩协同的能力，才会真正让你变得优秀。

延伸阅读

• Nicholas C. Zakas如何面试前端工程师
• 如何通过Nicholas C. Zakas的面试

Nicholas C. Zakas的书

早就打算写这篇文章了，但时至今日才决定动笔。如果你投了简历，那么应该会在面试你的人名单里找到我的名字。你现在就有点紧张了，（好啦，别不好意思）面试总会让人感觉有点不舒服。作为面试官，我其实并不算难对付，但如果你想在我们谈话之后让我放你过关，你确实得做一些必要的准备。

• 回答问题。我问你一个问题，你必须要回答它。我遇到应聘者在回答我问题时顾左右而言他的情况太多了。我知道你会有些紧张，说几句不着边际的话可能有助于缓解，但请你不要喋喋不休，要赶快回到正题上来。我不想知道你的宠物猫最近又出了什么新状况，我只想听到你的回答。假如你没有听明白我问的是什么，可以要求我再解释一下，重复几遍问题或者换一种问法，对我而言没有什么。

• 告诉我你不知道什么。如果我问到了你不知道的问题，一定要告诉我。我不认为你的大脑里可以装得下百科全书。在知道了你不知道什么以后，我对你的评估才会更加公平。问题仍然要回答，但我会给你一些提示，同时也可以考察一下你解决问题的能力。

• 不要放弃。在我面试你的过程中，不要总想着放弃。如果你被我前面的话不幸言中，那么你可能会面对一个让你不知所措的问题，而且你也告诉我你答不上来了。此时此刻，千万不要打退堂鼓！我会尽力提醒你，让你找到正确答案；因此不要随随便便打断我说：“我真的不知道。”在我们这个行业，你经常会遇到没有现成解决方案的挑战，到时候你会轻易放弃吗？我必须知道你具备解决问题的能力，而不是遇到一点挫折就轻言放弃。

• 不用担心怪问题。有些公司的确有吓唬应聘者的传统，他们会让你回答一些类似脑筋急转弯似的稀奇古怪的问题。对那种面试方式，我不敢苟同。我提的所有问题都有答案，而且绝大多数还不止有一个正确答案；我保证一个怪问题也不会问你。因为这样既会让你难堪，又对我毫无意义。你大可放心，我的每个问题都至少会有一个正确答案。

• 自圆其说。如果你提到了某个解决方案或者强调自己掌握了某方面知识，请做好进一步讨论它的准备。假设我问了一个问题，你在回答这个问题时提到：“对，因为IE不支持CSS3……”然后，你最好能够跟我讨论一下要是IE支持CSS3你会怎么办。

• 不要说自己是专家。大多数面试中可能都需要注意这一条，但我对这一条尤其敏感。我从来不会把应聘者划分为三六九等，因此你也不必告诉我你属于哪个等级。一旦你声明自己已经跻身“专家”的行列，我怕有些问题会让你下不来台。我确实见过自称专家而又确实是专家的人。但是，我认为真正的专家不会自己说出来，而是会做给你看。

• 不要靠卖弄赚取我的好印象。如果我想知道什么，我会问。我知道在面试时需要了解哪些信息，只要一听到有人说“想不想看一个绝妙的技巧？”或者其他类似的话，我都有一种立即中断面试的冲动。所以，请尽力回答好我的问题即可。

• 充满激情。如果你想得到跟我一起工作的机会，请给我一个愿意跟你共事的理由。最好的理由就是要有激情，把你主动、积极学习的热情展示出来。希望你能谈一谈产品、公司，以及为什么想得到这份工作。尤其要注意最后一点，我不想听你说你当前的工作如何如何讨厌。当然，可以解释一下为什么现在或者过去没有从事你喜欢的工作，但你一定要告诉我你对自己今后的成长有何打算，还有为什么你应聘的这个职位能够有助于你的成长。

没错，我确实希望将来有可能被我面试的所有人都看到这篇文章。我希望你能在我面试你时表现得非常好，真的，确实如此。说来也简单，只要你留意上述这些常见的问题，并且原原本本地展示你自己就足够了。说不定哪一天，你就会跟我坐到同一间办公室里了。

注意，My Yahoo!团队正在招聘呢。如果你是一位有才华的软件工程师，又对创造价值和Yahoo!公司充满激情，请跟我联系，咱们谈谈。

延伸阅读

• Nicholas C. Zakas如何面试前端工程师
• Nicholas C. Zakas谈怎样才能成为优秀的前端工程师

Nicholas C. Zakas的书

面试前端工程师对我来说是一件非常有意思的事，因为面试过程很大程度上也是自我提升的过程。无论大公司还是小公司，之所以在如何招聘到真正有能力的前端工程师方面会遇到同样的问题，就是因为负责招聘的那些人不知道自己公司需要什么样的人，结果问问题时也问不到点子上。经过这几年在行业里的摸索，我总结出了自己的一套很有效的面试前端工程的方法。

有的应聘者说我不好对付，但留给他们这样的印象也并非我所愿。我觉得之所以他们说我不好对付，主要是因为我问他们问题时问得太细了。以前我曾专门写过一些东西，告诉应聘者怎么才能通过我的面试以及怎样才能成为优秀的前端工程师应该具备什么样的素质，而我的面试可以说完全是按照那两篇文章的标准进行的。我不会问一些特别偏门的问题，也不认为出几道逻辑题就能考出人的真实水平。我唯一的想法就是确定你能否胜任我们要招的这个职位。为此，我需要简单地考察如下几个方面。

基本知识

我们生活在互联网时代，你想知道的任何事情几乎都能在15分钟内找到相关信息。可是，能找到信息并不等于你会使用它。我认为所有前端工程师至少都应该掌握某些基本的知识，才能有效地完成自己的工作。如果一遇到问题，就停下工作上网四处搜索解决方案，怎么可能保证按期完成工作呢？听听，还有谁在说“我不知道，但我可以上网搜到。”请这些同学把手举起来，让大家认识一下（immediately raises a flag for me.）。下面我列出一些基本的知识点，这些都是我认为一名前端工程师（无论工作年头长短）在没有任何外来帮助的情况下就应该知道的。

• DOM结构——两个节点之间可能存在哪些关系以及如何在节点之间任意移动。
• DOM操作——怎样添加、移除、移动、复制、创建和查找节点。
• 事件——怎样使用事件以及IE和DOM事件模型之间存在哪些主要差别。
• XMLHttpRequest——这是什么、怎样完整地执行一次GET请求、怎样检测错误。
• 严格模式与混杂模式——如何触发这两种模式，区分它们有何意义。
• 盒模型——外边距、内边距和边框之间的关系，IE < 8中的盒模型有什么不同。
• 块级元素与行内元素——怎么用CSS控制它们、它们怎样影响周围的元素以及你觉得应该如何定义它们的样式。
• 浮动元素——怎么使用它们、它们有什么问题以及怎么解决这些问题。
• HTML与XHTML——二者有什么区别，你觉得应该使用哪一个并说出理由。
• JSON——它是什么、为什么应该使用它、到底该怎么使用它，说出实现细节来。

重申一下，上述这些知识点都应该是你“想都不用想”就知道的东西。我一开始问的所有问题都是想摸清你对所有这些领域知识的掌握程度。虽然上面列出的这些知识点并没有面面俱到，但我觉得你至少应该掌握这些，才有可能跟我坐到一间办公室里来。

少量提问

我非常赞同面试者问的问题越少越好。反复问应聘者各种问题既不公平，也很无聊。我在任何一次面试中，通常只问三个大问题，但每个问题又会涉及我所能想到的多个方面。回答每个大问题一般要经过几个步骤，这样我就可以在每个步骤中穿插着问一些小问题。比如说：

这个问题牵扯到一组我想要考察的基本知识点：DOM结构、DOM操作、事件处理、XHR和JSON。如果我要求你换一种处理股票价格的方式，或者让你在页面中显示其他信息，就可以把更多的知识点包括进来。对于经验比较丰富的应聘者，我也可以自如地扩展要考察的知识范围，最简单像JOSN与XML的区别、安全问题、容量问题，等等。

我还希望应聘者给出的任何解决方案中都不要使用库。我想看到最原生态的代码，你就当页面中没有包含任何库。你说你对哪个库了解多少多少，但我不能把关于库的知识作为评判能力的因素，因为库是会随时间变化的。我需要的是真正理解库背后的机制，特别是能够徒手写出一个自己的库的人。

解决问题

做为一名前端工程师，最值得高兴的事莫过于解决同一个问题会有很多种不同的方法，而你要做的就是找出最合适的方法来。我在提问的时候，经常会在应聘者解释完一种方法后问他们还有没有第二种方法。此时我会跟他们说，假设你的这个方法由于种种原因被否决了，那么你还能不能给出另一种方法。这样做可以达到两个目的。

首先，可以测试出他们是否在毫无意义地复述书本中的东西。不能不承认，某些人确实有过目不忘的天赋，听他们在那里滔滔不绝地讲，你会觉得他们什么都明白。可是，只要一跟这些人谈到怎么查找方案无效的原因，以及能否拿出一个新方案来，他们往往就傻眼了。这时候，如果我听到“我不明白这个方案为什么不够好”之类的反问，心里立刻就明白我的问题已经超出了他们的能力范围，而他们只是想拿自己死记硬背的结论来蒙混过关。

其次，可以测试出他们已经掌握的（还是那句话，“想都不用想”就知道的）浏览器技术知识。如果他们对浏览器平台的核心知识有较好的理解，想出解决同一问题的不同方案根本没有那么难。

对一名前端工程师来说，这绝对是最重要的能力。前端工程师在工作中遇到本该如此却并未如此的难题（说你啦，IE6），应该说是一件很平常的事。一个方案无效就无计可施的人，做不了前端工程师。

考核应聘者解决问题能力的另一层原因，与我的个人喜好有关。在搞清楚应聘者知道什么不知道什么之后，我就会想着问一个他们知识领域之外的问题。这样做的目的，就是想看看他们怎样运用已有的知识解决新问题。在解决问题的每一步，我也准备了一些提示，以防有人会卡壳打艮（在我面前15分钟一言不发，对我评价这个人毫无帮助）。我真正感兴趣的，是他们能够从上一步前进到下一步。我希望看到一个人就在我眼前学到新知识。

注意：所有问题都与浏览器技术相关。我不相信出几道抽象的逻辑题，就能够考出某人解决Web技术问题的能力。在我看来，这无异于让素描大师画肖像（或者让刘翔跟博尔特同场竞技），没有意义，也得不到任何有价值的信息。

有激情

要成为一名优秀的前端工程师，最重要的莫过于对自己做的事要有激情。我们的技能都不是从学校中或者研讨会上学来的，因此前端工程师必须具备自学能力。浏览器技术的变化可谓日新月异，所以也只有不断提升自己的技能才做得到与时俱进。我虽然不能强迫谁必须多看博客、不断学习，但想应聘前端工程师的人恐怕还是必须得这么做。

你怎么知道谁对这种工作有没有激情？实际上非常简单。我只问一个简单的问题：“目前你对什么Web技术最感兴趣？”这个问题永远不会过期，而且也几乎不可能出错……除非你答不上来。就眼下来说，我希望你对这个问题给出的技术中包括WebSocket、HTML、WebGL、客户端数据库，等等。只有对Web开发充满激情的人，才会坚持不懈地学习新知识、掌握新技能；这些人才是我真正想要的。当然，我会让他们详细解释自己提到的技术，以保证他们不是随口念叨了几个时髦的新词汇。

最后一点

计算机科学或者Web设计方面的知识当然也有用，但那都是基本知识之外的东西。只要基本知识在那儿了，一切就都有了基础，想扩充知识面也不难。可是，如果等到正式上班以后，还得从头学习基本技能，那种难度是不可同日而语的。另外，高级前端工程师与一般工程师相比，肯定需要掌握更多的技能。而面试几乎没有经验的大学毕业生，我也会有一套完全不同的程序。我在这篇文章里列出来的都是一些最基本的东西。

对于那些还没有多少面试经验的人，我总是喜欢告诉他们，面试完了只要问自己一个问题就行：你想以后跟这个人在一起共事吗？如果不管为什么，回答是不，那就是不。

延伸阅读

• 如何通过Nicholas C. Zakas的面试
• Nicholas C. Zakas谈怎样才能成为优秀的前端工程师

Nicholas C. Zakas的书

请看
命名函数表达式探秘

原文链接：http://yura.thinkweb2.com/named-function-expressions/
本文链接：http://www.cn-cuckoo.com/2009/12/22/named-function-expressions-demystified-1320.html

Table of Contents

1. 前言
2. 函数表达式与函数声明
3. 函数语句
4. 命名函数表达式
5. 调试器中的函数名
6. JScript的bug
7. JScript的内存管理
8. 测试
9. Safari中存在的bug
10. SpiderMonkey的怪癖
11. 解决方案
12. 替代方案
13. WebKit的displayName
14. 对未来的思考
15. 致谢

看来（根据一位专家的说法是这样，不过还是感觉有点言不由衷），JavaScript最后真的流行起来了。

[此处是youtub.com中一段视频，可惜被"墙"了]

对我这个从小就呆头呆脑的人来说，这段视频像是咒语又像是玩笑。（这要看你是否跟我站在了相同的立场上：绿壳鸡蛋不就流行过吗？）

我搞不清楚为什么道格（Doug）要编故事。他并不在网景公司。他亲耳听到过我回忆JavaScript诞生的经过，我在Ajax大会的发言中也讲过了。难道是想混淆视听，想在Web开发人员中掀起一股提前讨论MicroHoo C#语言的风潮？

谁知道呢，要计较这些就没完了。不过，鉴于本周是我参与创立的mozilla.org 10周年，我打算讲一点历史。

正如我多次重申过的，而且Netscape的其他人也可以证明，我是因为Netscape要在浏览器中“实现Scheme”才被招聘进公司的。当时，至少负责客户端技术的汤姆·帕坎（Tom Paguin）、迈克尔·托伊（Michael Toy）和瑞克·谢尔（Rick Schell），以及一个叫马克·安德森（Marc Andreessen）的家伙认为Netscape应该在HTML中嵌入一种语言，一种源程序式的编程语言。而我这个新人要去说服“尖脑壳”的老板几乎是不可能的——实际上更多的则是他们在向我解释问题。

到底是不是要基于Scheme并没有定论，但Scheme确实是吸引我加入Netscape的一个原因。在此之前，我在SGI公司期间，尼克·汤普森（Nick Thompson）引导我学习了SICP（Structure and Interpretation of Computer Programs，《计算机程序的构造和解释》）。

当时真正需要的是一种有说服力的概念验证，也就是一个演示程序。在我交付演示程序之后，这个程序在极短的时间内就变为了既成事实。

没错，在加入Netscape后不久，我被调出服务器团队——由于人员不足，我在这个团队干了一段时间，在那里与麦库尔·吐温斯（McCool Twins）和阿瑞·卢奥托嫩（Ari Luotonen）有了一段时间不长但很快乐的合作；1995年下半年，阿瑞和我创建了PAC（Proxy Auto Config，代理自动配置）——的时候，Oak语言已经改名为Java，而Netscape正与Sun协商将该语言包含在Navigator中。

Netscape公司内部争论的最大焦点变成了：“为什么要包含两种语言？为什么不只用Java？”得到的回答是：必须有两种语言分别面向编程圣殿中的两类最不可能走到一块的开发人员：组件开发人员——这类人使用C++或（我们希望的）Java和脚本开发人员（爱好者或专业人员）——这类人编写直接嵌入在HTML中的代码。

至于是否使用已有的语言，而不发明一门新语言，也不是我说了算的。上峰的“军令”就是这门语言必须“看起来像Java”。这样，不仅排除了Perl、Python和Tcl，也排除了Scheme。后来，1996年，约翰·奥斯特豪特（John Ousterhout）前来推广TK时，还曾因Tcl错过机会而惋惜过。

谈不上自鸣得意，但我确实为自己吸收了Scheme式的一类函数和Self式的原型（尽管不那么主流）而感到高兴。至于Java的影响，特别是Date的Y2K bug和原始类型与对象类型（如string与String）差异的影响则是非常不幸的。

时光倒转回1995年春天：我记得在此期间见到了比尔·乔伊（Bill Joy），我和他讨论了垃圾收集的细节（card marking for efficient write barriers）。比尔一上来就完全理解了我们所说的一门易用的“脚本语言”与Java的关系，他还拿微软平台的VB与C++之间的关系作类比。据我所知，比尔是我们在Sun公司的支持者。

基普·希克曼（Kipp Hickman）和我在1995年4到5月间研究了Java，基普也开始写他自己的JVM。他和我编写了NSPR的第一个版本，作为他的JVM之下的可移植层。而我在5月中上旬创建Mocha的原型时，也将该版本用作了相同的目的。

比尔说服我们放弃基普的JVM，因为它会导致与Sun的JVM中的bug无法兼容（在那个时候可谓智慧的预言）。而此时此刻，Mocha已经通过在Netscapte Navigator 2.0（的初期测试版）中的快速原型和嵌入证明它自己。

除此之外，应该说都是对历史的歪曲和调侃。JS在客户端打败了Java，只有Flash能与其竞争，而Flash又支持JS的一个衍生品——ActionScript。

现在再回到流行的问题上。其实谈不谈这个问题都无所谓。然而，那些散布于互联网的流行的Ajax库，却经常以被掰碎了、压扁了，然后再以链接形式挑出来的纯文本的形式存在。难道不可以共享吗？

有一种想法——受到了不少人的质疑，最近一次发出质疑声音的人是道格——在可能将会非常长寿的script标签属性中嵌入“神秘的散列码”（crypto-hashes）。这是个好主意吗？

恐怕不是。一方面因为“神秘的散列码”理论上的完备性问题，另一方面则因为其广为人知的药饵攻击（poisoning attacks）。

还有一个主意倒是不错，这个主意我是先从罗布·塞尔（Rob Sayre）那里听说的：通过HTML5中script标签的share属性支持一种可选的“公认的URL”：
<script src=”http://my.edge.cached.startup.com/dojo-1.0.0.js”
shared=”http://o.aolcdn.com/dojo/1.0.0/dojo/dojo.xd.js”>
</script>

如果浏览器首先下载了共享的URL，而且根据HTTP的缓存规则它依然有效，那么就可以使用缓存（及预编译）的脚本，而不必从src属性指定的URL中下载。

这就避免了散列药饵的问题。这个方案只要求内容作者保证src属性指向的文件与share属性指定的这个库的公认（或流行）的版本相同即可。不过当然，我们必须信得过相应的DNS。（Ulp.）

这个方案可以避免在script标签属性值中嵌入不可预测的散列码。

欢迎大家就此问题给我留言。

好了，这次真的回到JavaScript流行的问题上了。我们都知道有些Ajax库的确流行。那JavaScript流行吗？很难说。有些Ajax开发人员表示（也证明）了对它的喜爱。但也有很多人骂它，也骂我。我依然认为JavaScript是C和Self草草结合的结果（或一个私生子）。我又想起了约翰逊博士（http://en.wikipedia.org/wiki/Dr._Samuel_Johnson）的那句话：“好的不是原创的，而原创的都不好。”

不过，这没什么。Web总要发展，否则只有死路一条。JS也一样，要不就不会有ES4了。说到ES4，很快将有下文。

Firefox 3好像也会流行的， 它的空间与时间性能测试预示了这一点。相关内容呢，我以后还会陆续地谈到。

中文链接：www.cn-cuckoo.com/css/thesis-of-Hakon-Wium-Lie/

原文链接：people.opera.com/howcome/2006/phd/

翻译进度列表：

• 2009-1-7，“灵感”
• 2009-11-1，“第1章 导言”

Håkon Wium Lie出生于1965年7月26日，是土生土长的挪威人。现为Opera Software的CTO（Chief Technology Officer，首席技术官）。他的个人页面、维基百科词条。

1994年，Håkon Wium Lie提出了层叠样式表的概念，并于当年10月提交了他的样式表建议——Cascading HTML style sheets。1996年12月，他亲自主持并以他的建议为基础创建的Cascading Style Sheets, level 1，正式成为W3C的推荐标准。后来，几乎所有主要浏览器都实现了CSS。CSS的普及，结束了长达数年之久的“表现性HTML”的历史，开创了标准Web开发中结构、表现、行为分离的新时代。

1995年， Håkon Wium Lie针对测试Web浏览器在呈现HTML标记、CSS2.1样式、PNG图像及数据URI方面的支持情况，提出了Acid2建议。该建议后来由Web标准组织开发并发布，成为判定新（版）浏览器对Web标准支持情况的一个重要依据。

另外，Håkon Wium Lie与另一位CSS标准的制定者Bert Bos合著的Cascading Style Sheets: Designing for the Web, 3rd Edition 2005年5月由Addison-Wesley Professional出版。也是学习CSS的一本优秀图书。这里还有一篇发表于A List Apart的他们合写的文章：Printing a Book with CSS: Boom!

总而言之，翻译这篇论文的想法由来已久了。原因很简单，这篇论文是Håkon Wium Lie在他提出CSS的建议10年后写就的，其中全面翔实地包含了大量与CSS及Web发展有关的珍贵资料，是研究和学习CSS不可多得的重要参考文献。翻译这篇论文的过程，也是学习和研究的过程。希望自己在翻译完这篇论文后，对CSS和Web的理解能上升到一个新的层次。

想知道怎样在今天的Web上创造伟大的用户体验吗？UI专家Bill Scott和Theresa Neil通过本书向读者展示了超过75种基于富交互构建Web界面的模式。作者以自己在Sabre、Yahoo!和Netflix多年的工作经验为依托，把精挑细选的各种最佳实践归结为6个重要原理，深入浅出地向读者阐释了如何有效利用当前的Web技术。本书每一部分都围绕一个设计原理展开讨论，通过学习本书，读者可以掌握以下原理。

直截了当：通过页内编辑、拖放和直接选择等模式实现基于上下文的内容编辑。
简化交互：借助“轻量级”上下文工具，有效减少用户与站点的不必要交互。
足不出户：采用覆盖层、嵌入层、动态内容和页内流程模式保证访问者不离开当前页面。
提供邀请：向用户发出进入下一级交互的邀请，帮助用户发现站点的功能。
巧用变换：学习何时、何地、以何种方式使用动画、电影转场效果及其他变换手段。
即时反应：以实时搜索、实时建议、实时预览及更多模式，为用户提供丰富的交互式体验。

本书以当前最流行的Web站点为例，介绍了大量行之有效的Web界面设计模式。如果你想构建或重构站点，并希望站点以丰富的交互为特色，那本书就是你出奇制胜的宝典。

“本书提供了富因特网应用程序（RIA）设计人员和开发人员（或开发团队）作出明智选择时必须知道的一切。对于当今主流的Web设计师而言，（本书）应该人手一册。”

——Erin Malone，Tangible UX负责人

当当网读者评论

读者：Drek
来自：广州市
标题：很多新的，流行的理念
评分：4星
发表于 2009-10-11 23:53
我是个程序员，可惜在的公司太小，美工，前台，后台，设计，样式都要一手包办。其实挺郁闷的，为了在点脱离这情况，学多点广博的知识，早日飞翔，成就梦想。
而涉及到的知识都要去看，去学。
界面也要自己去处理。所以看到了本书，站在一个程序员的角度考虑，里面的设计思想其实很潮的。没有你想不到，只有你做不到的。书是针对界面设计，没有任何提及程序，代码如何实现的，也没有提及美工方面如何处理的。
可以说同一个设计相思，可以用不同东西去实现，只要你会的。
所以感觉如果作为程序员，又要考虑界面设计的朋友，本书值得一看。如果就美工和单纯是界面设计的，也给予了你不同的设计思想。
当然，世事没有完美的，程序，界面或者流行一时，2，3年间也许变化很大，为了适应自己的工作，或者适应这个时代，可以得到的资源都不要放过哦

读者：斯泰普斯
来自：上海
标题：赏心悦目
评分：5星
发表于 2009-09-11 09:16
书不错，材质也不错，很有手感。
价格比china-pub贵几块，但我还是等待当当出来才买的。
是一本值得收藏的借鉴的书。
个人推荐。
注：可结合另一本《网站优化》一同阅读。

http://product.dangdang.com/product.aspx?product_id=9345032

卓越亚马逊读者评论

读者：微微
来自：
标题：设计手段与模式
评分：5星
发表于2009-09-08 10:31:23
大凡设计师都是这样来的：先学会对付细节问题，然后尝试系统解决，最后学会总结问题与应对手段。
这本书讲述了6个界面设计原理，对应14种设计模式，以及提供了超过70种具体设计手段。
书中的实例来自flickr, yahoo, google等国外比较大型的网站，部分细节已经不复存在。刚好，你可以通过观察现在的设计，对比书中留存的旧时实例，去思考背后的设计思路。
模式和具体手法都是在不停变化的。
读完这本书，希望大家可以总结出自己网站适用的新的手段、模式。

目录

序
前言
原理一：直截了当
第1章：页内编辑
1.1 单字段行内编辑
1.2 多字段行内编辑
1.3 覆盖层编辑
1.4 表格编辑
1.5 群组编辑
1.6 模块配置
1.7 选择编辑模式的原则
第2章：利用拖放
2.1 趣味瞬间
2.2 拖放的用途
2.3 拖放模块
2.4 拖放列表
2.5 拖放对象
2.6 拖放操作
2.7 拖放集合
2.8 实现拖放的挑战
第3章：直接选择
3.1 切换选择
3.2 集合选择
3.3 对象选择
3.4 混合选择
原理二：简化交互
第4章：上下文工具
4.1 上下文交互
4.2 费茨定律
4.3 上下文工具
4.4 实时可见工具
4.5 悬停即现工具
4.6 开关显示工具
4.7 级联递进工具
4.8 二级菜单
原理三：足不出户
第5章：覆盖层
5.1 对话框覆盖层
5.2 详情覆盖层
5.3 输入覆盖层
第6章：嵌入层
6.1 对话框嵌入层
6.2 列表嵌入层
6.3 详情嵌入层
6.4 标签页
6.5 嵌入层与覆盖层
第7章：虚拟页面
7.1 虚拟滚动
7.2 内置分页
7.3 滚动分页：传送带
7.4 虚拟摇摄
7.5 伸缩式用户界面
7.6 分页与滚动
第8章：流程处理
8.1 Google Blogger
8.2 魔法原理
8.3 交互式单页
8.4 嵌入式部件
8.5 对话框覆盖层
8.6 配置程序
8.7 静态单页
原理四：提供邀请
第9章：静态邀请
9.1 引导操作邀请
9.2 漫游探索邀请
第10章：动态邀请
10.1 悬停邀请
10.2 预期功能邀请
10.3 拖放邀请
10.4 推论邀请
10.5 更多内容邀请
10.6 邀请的优点
原理五：巧用变换
第11章：变换模式
11.1 加亮和减暗
11.2 扩展与折叠
11.3 自恢复式淡出
11.4 动画效果
11.5 聚光灯效果
第12章：变换的目的
12.1 增添魅力
12.2 增进沟通
原理六：即时反应
第13章：查询模式
13.1 自动完成
13.2 实时建议
13.3 实时搜索
13.4 微调搜索
第14章：反馈模式
14.1 实时预览
14.2 渐进展现
14.3 进度指示
14.4 定时刷新
尾声：富交互的原理和模式
索引

本书作为《jQuery基础教程》的升级版，涵盖了 jQuery 1.3的全部新特性，特别是新增了介绍 jQuery UI（jQuery官方用户界面插件库）的内容。本书前 6章以通俗易懂的方式介绍了 jQuery的基本概念，主要包括 jQuery的选择符、事件、效果、DOM操作、AJAX支持等。随后 3章从理论到实践，通过表格操作、构建功能型表单、实现滑移和翻转效果等实例，深入浅出地讲解了如何创造性地运用 jQuery提供的丰富而强大的 API。本书最后两章专门介绍了如何使用和编写 jQuery插件。值得一提的是，本版新增的附录 D分门别类地列出了所有 jQuery API，为高效使用 jQuery提供了方便。

本书内容

第1章将带领读者对jQuery有个大概的了解。这一章先简单介绍jQuery及其用途，然后的内容主要涉及如何下载和设置jQuery库，同时也会指导你使用jQuery编写第一个脚本。

第2章讲述如何通过jQuery中的选择符表达式及DOM遍历方法，在页面中的任何地方找到想要的元素。这一章将展示如何使用各种选择符表达式为页面中的不同元素添加样式，其中一些是通过纯CSS方式做不到的。

第3章介绍如何通过jQuery的事件处理机制，在浏览器发生事件时触发行为。同时，还会介绍如何以不唐突的方式添加事件（甚至在页面加载完成之前）。此外，这一章还将深入更高级的主题，例如事件冒泡、委托和命名空间。

第4章介绍通过jQuery实现动画的技术，从中我们能够体会到隐藏、显示和移动页面元素时那种轻松自如的感觉。

第5章讲述如何通过命令改变页面。本章讲述的是动态修改HTML文档结构及其内容的技术。

第6章讨论通过jQuery轻松地访问服务器端功能的各种方法，而且不用像过去那样刷新页面。

接下来3章（第7、8、9章）主要以实例为主，即在前几章学习的基础上，创建常见问题的稳健jQuery解决方案。

第7章“表格操作”，讲述排序、筛选和为信息添加样式并创建优美实用的数据布局。

第8章“创建功能性表单”以客户端数据验证为主题。届时，将设计一个具有适应能力的表单布局，还会实现基于客户端与服务器通信的交互式表单功能，例如自动完成。

第9章“滑移和翻转”介绍如何在显示页面元素时增强它们的美感和实用性。其中，动态显示和隐藏信息的方式既可以是自动的，也可以是用户控制的。

第10和11章的主题是jQuery库的第三方扩展，将向读者展示扩展这个库的各种方式。

第10章“使用插件”介绍Form插件和官方用户界面插件集合jQuery UI。同时，还将介绍到哪里寻找其他流行的jQuery插件并了解它们的功能。

第11章“开发插件”将讨论如何利用jQuery强大的扩展能力，从头开发自己的插件。不仅包括创建自己的实用函数，还有添加jQuery对象方法、添加自定义选择符表达式，等等。

附录A“在线资源”提供了很多与jQuery、JavaScript以及通常的Web开发有关的内容丰富的网站信息。

附录B“开发工具”推荐了一些有用的第三方程序和实用工具，用于在个人的开发环境中编辑和调试jQuery代码。

附录C“JavaScript闭包”将帮助读者理解闭包——什么是闭包，怎么利用闭包。

附录D“快速参考”提供了jQuery的简明参考，包括所有方法和选择符表达式。在实际开发中，在明确自己目标的情况下，通过这个简单明了的附录，能够方便快捷地找到正确的方法和选择符。

本书能够为您节省宝贵的Web开发时间。有了这些针对真实问题的解决方案放在手边，大多数编程难题都会迎刃而解。
今天，用PHP开发的2000万个网站充分表明，PHP已经成为一门最流行的脚本语言。本书将PHP的特性与经典实例丛书的独特形式组合到一起，足以帮您成功地构建跨浏览器的web应用程序。在这个修订版中，您可以更加方便地找到各种编程问题的解决方案，本书中内容涵盖了：

• 表单处理
• session管理
• 数据库交互
• 使用Web 服务

从初学者常见的问题到高级Web编程技术，这本问题指南中包含了丰富的、具有实际应用价值的实例，可以满足使用PHP生成动态Web内容的任何人的需要。书中的每个实例都细致地讨论了所提供解决方案背后的逻辑和思想，用源自PHP专家的洞察力帮你轻松地掌握这门语言。书中更新了PHP5的有关内容，并详细地解释了如何使用新增的语言特性，比如面向对象能力的巨大改进和新的PDO数据访问扩展等。书中特别增加了有关类和对象的部分，包含了以下基本内容：

• 处理XML
• 与JavaScript交互
• 用PHP构建Web 服务
• 使用SOAP和REST架构

《PHP经典实例（第二版）》中超过250个实例，为你每天都要面对的诸多问题提供了足够丰富的解决方案。而且，每个实例的讨论部分都浸透着对每个PHP开发人员极为有益的理念。
David Sklar 是Ning的一名软件开发人员。在1996年发现PHP能够满足他编写web编程需要的时候，他创建了PX（http://px.sklar.com），这是一个可以让PHP用户交换程序的场所。此外，他还是《Learning PHP5》（O’Reilly）和《Essential PHP Tools》（Apress）的作者。

Adam Trachtenberg 是eBay的一名技术讲师，也是《Upgrading to PHP5》（O’Reilly）的作者。他经常会在O’Reilly Conference和LinuxWorld上发表演讲。他还拥有科伦比亚大学商学院的MBA学位。

前言
第1章字符串
第2章数字
第3章日期和时间
第4章数组
第5章变量
第6章函数
第7章类和对象
第8章Web基础
第9章表单
第10章访问数据库
第11章Session和数据保持
第12章XML
第13章Web自动化
第14章消费Web服务
第15章建立Web服务
第16章互联网服务
第17章图形
第18章安全和加密
第19章国际化和本地化
第20章错误处理，故障排除和测试
第21章性能调谐和负载测试
第22章正则表达式
第23章文件
第24章目录
第25章命令行PHP
第26章PEAR和PECL

我在高教自考《英汉翻译教程》一书中推荐过一位英国学者，名叫西奥多•萨沃里（Theodore Savory）。他在1957年发表的The Act of Translation 一书中写道：

A fair conclusion from these ideas is that the translator’s work may be analysed into the answering of three questions. Faced with a passage in its original language, he must ask himself:

(ⅰ) What does the author say?

(ⅱ) What does he mean?

(ⅲ) How does he say it?

This method of analysis may be applied to the paragraph, to the sentence, or even to the phrase.

要想翻译意思，必须先弄清楚原文的意思。正如萨沃里所说，译者必须先问自己第一个问题：作者说的是什么？但若到此为止，那是很不够的。因为这时你看到的只是字面上的意思，若动手翻译，难免弄出机械的字对字的译文。因此，译者还必须问自己第二个问题：作者的意思是什么？只有正确地回答了这个问题，才抓住了作者所要表达的意思。这时动手翻译，才能真心做到翻译意思。

一．深入考虑关键词语的含义。我们学英语，往往喜欢在一个英语词和一个汉语词之间划等号，对一个词的某一个意思印象较深，一见这个词，须首先想到这个意思。这就会妨碍我们深入考虑这个词在这个上下文里的含义。

例1 He wasn’t drinking that night because he was the designated driver .

那天晚上他没有喝酒，因为他是指定的司机。

例2 He’s always lethargic after little sleep.

小睡之后他总是懒洋洋的。

例3 The thought of going out in the rain and fog discouraged him.

到雨中和雾里去的想法使他打了退堂鼓。

例4 Our teacher has a true interest in her students.

我们的老师对学生有真正的兴趣。

例5 He speaks out about problems in government.

他坦率指出政府中存在的问题。

例6 the history of the church from the middle ages down to the present.

这个教堂从中世纪到目前的历史。

例7 That’s the last we’ll hear of it.

这将是我们最后一次听到。

这7个例子，译文的问题都出在名词没有处理好。driver不等于司机。英语喜欢用名词来表示人的某种能力。a good cook 是指很会做菜的人，a good singer 是指唱歌唱得好的人。after little sleep 相当于when he doesn’t get enough sleep。the thought of …相当于when he thought of…。interest 在这里是concern。government 一词在这里没有冠词，是一个不可数名词，相当于governance, 意思是“治理国家”。the church 是指the whole body of Christian believers。the last 在这里得意思是a final mention。基于以上的理解，我们可以把上述7个例子的译文修改如下：

⒈ 那天晚上他没有喝酒，因为已确定由他开车。

⒉ 他一睡眠不足，就无精打采。

⒊ 一想到外面又是雨，又是雾，他就打退堂鼓了。

⒋ 我们的老师真正关心自己的学生。

⒌ 他坦率指出治理国家方面存在的问题。

⒍ 基督教从中世纪到现在的历史。

⒎ 以后不要再提这件事了。

下面请看另一组例子。

例8 I’ll have a dozen eggs.

我将有一打鸡蛋。

例9 Well, mate, let’s get going.

好吧，伙计，我们走。

例10 She suffers from arthritis.

她饱受关节炎的痛苦。

例11 Training to be a doctor is tough.

培训医生是非常艰苦的事情。

例12 The car doors lock automatically.

车门自动锁上了。

例13 Drop me a note.

给我留个条。

例14 She emptied her glass.

她倒空了玻璃杯。

这7句话，译文的问题都在于动词没有处理好。例8这句话，十有八九是在小商店对售货员说的，如果是这样，I’ll have 的意思就是“我要买”。Longman Dictionary of Contemporary English 对这一短语的解释是say this to ask for something that you have chosen in a restaurant or shop (见have 2条，义项34)。例9有mate 一词，这句话可能是领班或组长对一起干活的人说的。如果是这样，get going 的意思就是“开始干活儿”。The Dictionary of Contemporary American English 对这个短语的解释是to begin work on something (见get 条，义项17)。单说suffer, 是有遭受痛苦的意思。但suffer from 一种疾病，则只表示患有这种疾病。 Training是从动词train演变出来的动名词。train作为及物动词，意思是训练别人，作为不及物动词，意思就是接受训练。例11就是用的第2个意思，因为没有宾语。例12值得注意的是动词的时态，lock是一般现在时，而不是过去时或现在完成时，因此这不是已经完成的一次性动作，而是可以反复做的动作，也就是说这是车门具有的一种能力。根据Oxford Advanced Learner’s Dictionary 的解释，drop sb. a line/note 意思是to send a short letter to sb. 例14有代词her, 这就表明她不是在洗杯子，而是在和别人喝酒或其他饮料，各人有自己的杯子。既然这样emptied 就不是把杯子里的东西倒掉，而是喝光。基于以上的理解，这7个例子的译文可修改如下：

8． 我买一打鸡蛋。

9． 好吧，伙计。咱们开始干吧。

10．她患了关节炎。

11．学医是非常艰苦的事情。

12．车门能自动锁上。

13．给我写封短信。

14．她一饮而尽。

英语的动词是最活跃的一个词素。从以上几个例子看，首先要判断一下这句话可能是在什么情况下说的，接着就要看动词是及物还是不及物动词，用的是什么时态，还要看动词跟什么词搭配，有没有什么特殊的含义。这些因素都考虑到了，就能比较准确地把握这句话的意思了。

二．充分发挥汉语的表达力。汉语历史悠久，具有极强的表达力，翻译时也不必给原文里的每一个词提供对应词。每个词都能对上，不一定就是好的译文，过于机械的译文并不可取。抓住了原文的意思之后，就要反复思考怎样用汉语表达最好。

例15 We gave the sick boy special attention.

我们给病孩特别关照。

例16 She lectured her children on good table manners.

她告诫孩子们要有好的餐桌礼仪。

例17 She takes in stray cats who have no homes.

她收养无家可归的流浪猫。

例18 His death in a car accident was just another statistic in the death rate.

它在车祸中的死亡不过是死亡率中的另一个统计数字。

例19 It was two Decembers ago when she visited us.

她来我们这里做客是在两个十二月份之前。

例20 He put his arms around his girlfriend and squeezed her.

他搂住女友用力挤。

例21 She is full of stress because her boss gives her too much work.

她充满压力，因为老板给她干的活太多。

从the sick boy 可以看出这句话比较正式，是大夫或护士在向领导汇报工作，或向参观者客观地介绍情况，而不可能是对家长说话，因为面对家长就要说your boy。“病孩”是逐字翻过来的，而汉语里现成的说法是“患儿”。“餐桌礼仪”和“流浪猫”也都是逐字翻译，汉语里常说“吃饭要有吃饭的样子”，也常说“野猫”，为什么不用呢？亦步亦趋地跟着英文走，生造一些刺耳的字眼，是不可取的。后四个例子，词不达意，十分费解，有的甚至可笑。纵然字面上与原文对得很紧，又有什么用呢？仔细思考一下，这些例子的译文可改为：

15．我们给这个患儿特别关照。

16．她教训孩子们吃饭要有吃饭的样子。

17．她收养无家可归的野猫。

18．他死于车祸，不过是给死亡统计数字增加了一个数。

19．她来我们这里做客是前年十二月份的事了。

20．他搂住女友，搂得紧紧的。

21．她的压力很大，因为老板给她干的活太多。

下面再看一组例子。

例22 While I do not agree with what you say, I understand your reason for saying it.

虽然我不同意你说的话，但我理解你这样说的原因。

例23 She worries about the safety of her children at school.

她担心在学校上学的孩子们的安全。

例24 We have grave doubts about his honesty.

我们对他的诚实性有很大的怀疑。

例25 The injured horse was dispatched by its owner.

受伤的马被他的主人杀死。

例26 I told my son to watch out for ice on the road ahead.

我告诉儿子提防前面道路上的冰。

例27 He has youthful good looks.

她长着年轻英俊的脸。

例28 We listened to the plane engine drone on until we fell asleep.

我们听着飞机引擎不停地嗡嗡叫直到睡着。

例29 He started to cry.

他开始哭。

例30 My stubborn little boy would not put his coat on; he said, “No, no.”

我那倔强儿子不愿意穿外衣，他说，“不，不。”

例31 I’ m tired of standing; let’s find some chairs.

我站累了。我们找些椅子吧。

这10个例子译文都很别扭，究其原因，都是跟原文跟的太紧。前3例中reason, safety和honesty都是名词，但在这种场合，汉语要用疑问词才比较通顺。汉语不像英语用那么多代词，尤其是物主代词。“主人”前面“它的”二字显然是多余的。英语往往以介词短语作修饰语，若照样译成汉语，则显得死板；若用个动词，句子就活了。对人或物的描写，英语多落在名词上，汉语多落在形容词上。英语多用主从结构，在许多情况下，靠的就是until, before 之类的连词。翻译时，不能看见until 就译“直到”，看见before就译“之前”，必须灵活处理才听着顺耳。这10个例子中，最别扭的就是例29了。虽然译文每个字都和原文相对应，但其节奏让人听了实在难受。最后两句表达不充分。不要把no和“不”划等号，既然这里说的是孩子不愿穿衣，“穿”字为何不说出来呢？找椅子，无非是为了坐坐，为何不说出来呢？加上“坐坐”二字，和前半句有所呼应，意思也完整。根据以上情况，译文可改为：

22．虽然我不同意你说的话，但我理解你为什么这样说。

23．她担心自己的孩子们在学校是否安全。

24．我们对他是否诚实有很大的怀疑。

25．受伤的马被主人宰了。

26．我告诉儿子提防前面路上有冰。

27．他又年轻，又漂亮。

28．我们听着飞机引擎不停地嗡嗡叫，后来就睡着了。

29．他哭起来了。

30．我那倔强儿子不愿意穿外衣，他说，“不穿，不穿。”

31．我站累了，咱们找两把椅子坐坐吧。

要想提供好的译文，弄清原文的意思之后，不能逐字照译，而要把原文撇开，反复思索怎样才能最好地把这个意思用汉语表达出来。词语怎样处理，语序如何改变，结构怎样调整，加不加语气词，都要考虑。语气词是汉语特有的，运用得当，可为译文增色不少。一个呆板的句子，加一个“了”字就全活了。有时顺不顺要靠耳朵来决定，读出声来，听一听，很有用。自己拿不定主意，还可以问问周围的人，听听他们的感觉。我就常问家里人，特别是体育方面的问题问儿子，服饰方面的问题问老伴。有时在一个地方卡住了，那就先放一放，不定什么时候，灵机一动，想出一个好的译法来。这时候，心中的喜悦真是难以用语言来形容。你有过这样的体验吗？

1922年，茅盾在“‘直译’与‘死译’”一文中写道：“近来颇有人诟病‘直译’；他们不是说‘看不懂’，就是说‘看起来很吃力’。我们以为直译的东西看起来较为吃力，或者有之，却决不会看不懂。看不懂的译文是‘死译’的文字，不是直译的。

1934年，茅盾在“直译•顺译•歪译’一文中写道：“‘直译’这名词，在‘五四’以后方成为权威。这是反抗林琴南氏的‘歪译’而起的。我们说林译是‘歪译’，可丝毫没有糟蹋他的意思；我们是觉得‘意译’这名词用在林译身上并不妥当，所以称它为‘歪译’。”

1980年，茅盾在《茅盾译文选集》序中回忆这一段往事，他写道：“后来有的译者随意增删原著，不讲究忠实原文的‘意译’，甚至‘歪译’，那就比林译更不如了。”

从以上情况看，在二三十年代，反对直译的人所反对的是看不懂或看起来吃力的译文；反对意译的人所反对的是随意增删原著、不讲究忠实原文的译文。

鲁迅也是积极主张直译的。

后来有人提出直译和意译是一回事，是无法区分的。

1946年，朱光潜在“谈翻译”一文中写道：“所谓‘直译’是指依原文的字面翻译，有一字一句就译一字一句，而且字句的次第也不更动。所谓‘意译’是指把原文的意思用中文表达出来，不必完全依原文的字面和次第。‘直译’偏重对于原文的忠实，‘意译’偏重译文语气的顺畅。哪一种是最妥当的译法，人们争执得很厉害。依我看，直译和意译的分别根本不应存在。……想尽量表达原文的意思，必须尽量保存原文的语句组织。因此直译不能不是意译，而意译也不能不是直译。”

1953年，林汉达在“翻译的原则”一文中写道：“正确的翻译是直译，也就是意译。死译和胡译不同，呆译和曲译不同，这是可以划分的，它们都是错误的翻译。正确的翻译是分不出直译或意译的。”

1959年，周建人为《外语教学与翻译》写了一篇文章，题目是“关于‘直译”’。他在文中写道：“直译既不是‘字典译法’，也不是死译、硬译，它是要求真正的意译，要求不失原文的语气与文情，确切地翻译过来的译法。换一句话说，当时所谓直译是指真正的意译。”

如果说四五十年代人们认为直译也就是意译，二者无法区分，那么到了七八十年代人们又对直译和意译分别作了分析。

1982年，周煦良在“翻译三论”一文中写道：直译可以分为三类：第一类是译音而不译意。如democracy译为“德谟克拉西”，而不译为“民主”。第二类是照字面译。如crocodile tears译作“鳄鱼的眼泪”，而不译作“虚伪的眼泪”。第三类是不按照中国语言习惯和词序而按照原文的结构或词序的翻译。如“‘你来了，’她说”。最后，他指出“这样一些直译好像为数不少，但就一篇文章，一部书来看，直译的成分毕竟是少数。”

1978年，许渊冲在“翻译中的几对矛盾”一文中也谈到直译与意译的问题，他说：“直译是把忠实于原文内容放在第一位，把忠实于原文形式放在第二位，把通顺的译文形式放在第三位的翻译方法。意译却是把忠实于原文的内容放在第一位，把通顺的译文形式放在第二位，而不拘泥于原文形式的翻译方法。”最后他得出五点结论，归纳成两点就是：一．译文和原文相同的形式能表达和原文相同的内容时，可以直译，不能表达时就意译；二．原文的表达形式比译文精确、有力时，可以直译，译文的表达形式比原文精确、有力时，可以意译。

1979年，王佐良在“词义•文体•翻译”一文中写道：“要根据原作语言的不同情况，来决定其中该直译的就直译。该意译的就意译。一个出色的译者总是能全局在胸而又紧扣局部，既忠实于原作的灵魂。又便利于读者的理解与接受的。一部好的译作总是既有直译又有意译的：凡能直译处坚持直译，必须意译处则放手意译。”

从以上情况看，七八十年代的译者对直译和意译作了分析和比较，采取了兼容并蓄的态度。这说明当代的译者比二三十年代乃至四五十年代的译者在理论上都更加成熟了。

在国外，译界的同行也同样在这一方面进行探讨。英国剑桥大学乔治•斯坦纳教授主张意译。他在1975年发表的After Babel一书中发挥了17世纪英国学者约翰•德莱顿关于意译的主张。他写道：“翻译的正确道路，既不应是直译，也不应是模仿，而应是意译(paraphrase)。所谓意译，就是‘译者有一定限度的自由，他要时刻看到作者，这样就不至于迷失方向，但他主要是紧跟作者的意思而不死扣字眼，他可以对作者的意思加以引伸，但不能改变。’据德莱顿说，这就是埃德蒙•沃勒和西德尼•戈多尔芬1658年翻译维吉尔的史诗《伊尼德》(Aeneid)第四卷时采取的方法。更重要的是，德莱顿本人翻译维古尔、贺拉斯、奥维德、朱文纳尔、乔叟等人的著作时，也采用了这种方法，在他评论 别人的译作时(如1685年出版的Sylvae一书的序言)所阐述的也是这种方法。通过意译，‘作者的精神可以得到传播，而不会遭受损失。’好的翻译好比是‘一种写生’。最理想的情况是，译作不剥夺原作的权威，而能向我们表明假如原作本来就是用我们的语言创作的，它会是个什么样子。”

国外还有一些学者表达了类似的看法。你同意他们这种看法吗？

一

许多人写文章讨论翻译中的风格问题，倒也的确大都涉及文学作品的翻译。风格能不能译，大体上有两种意见。

一种意见认为风格是能译的。早在1922年茅盾就曾写道：“直译的意义若就浅处说，只是‘不妄改原文的字句’；就深处说，还求‘能保留原文的情调与风格’。”

1954年茅盾在全国文学翻译工作会议上的报告中说道：“文学的翻译是用另一种语言，把原作的艺术意境传达出来，使读者在读译文的时候能够像读原作时一样得到启发、感动和美的感受’。这样的翻译，自然不是单纯技术性的语言外形的变易，而是要求译者通过原作的语言外形，深刻地体会了原作者的艺术创造的过程，把握住原作的精神，在自己的思想、感情、生活体验中找到最适合的印证，然后运用适合于原作风格的文学语言，把原作的内容与形式正确无遗地再现出来。”

1980年茅盾在“《茅盾译文选集》序”中写道：“很重要的一点是能将他的风格翻译出来。譬如果戈理的作品与高尔基的作品风格就不同，肖伯纳的作品与同样是英国大作家的高尔斯华绥的作品的风格也不同。需将一个作家的风格翻译出来，这当然是相当困难的，需要运用适合于原作风格的文学语言，把原作的内容与形式正确无遗地再现出来。除信、达外，还要又文采。这样的翻译既需要译者的创造性，而又要完全忠实于原作的面貌。这是对文学翻译的最高要求。”

这个意见是有人支持的。1961年刘隆惠在“谈谈文艺作品风格的翻译问题”一文中写道：“对于文学翻译，不仅要求通顺流畅，而且要求表达原作的风格。”他还说：“我认为风格并不是不能译，而是难译。其所以难是在于译者必须具备两个条件。其一是要有认识风格的水平；其二是要有表现风格的能力。”

另一种意见认为风格是不能译的。1959年周熙良在“翻译与理论”一文中写道：“有人自诩翻译哪一个作家就能还出这个作家的面目或风格，我看这只是英雄欺人语；据我所知，就有翻译家对本文还不大能弄懂得，就大吹自己的翻译是旨在表现原作诗一般美丽的风格。依我看，对一个作家或者风格的认识也还是根据对作品本文的理解而来的，否则便是空话。教外国文学的人最喜欢谈风格，但是，对于一个搞实际翻译的人来说，风格却是一个最难谈得清楚的东西。我觉得，在通常情形下，它好像只是在无形中使译者受到感染，而且译者也是无形中把这种风格通过他的译文去感染读者的，所以既然是这样情形，我看就让风格自己去照顾自己好了，翻译工作者大可不必为它多伤脑筋。……我觉得翻译工作者如果要花许多功夫去钻研作品的风格，还不如花点功夫去培养自己的外语感受能力好些，因为翻译工作究竟是和语言文字打交道的工作，而语言却不止是数字符号那样抽象而无情的东西。”

二十多年以后，周熙良依然坚持自己的这一看法。1982年他在“翻译三论”一文中写道：“严复只提雅，而不提原文风格，我们现在提文学翻译要有风格，也不宜要求译出原文风格：原文风格是无法转译的。……我仍旧认为风格是无法翻译的，风格离不开语言，不同的语言无法表达同样的风格。”

这一种意见也是有人支持的。1961年张中楹在“关于翻译中的风格问题”一文中写道：“在同一语言的领域里，尚且不宜摹访一个作者的风格；在翻译方面，把原作译成另一种语言而要保持同一风格，这是更不易做到的工作。……我是极为赞同周熙良同志的‘不必多伤脑筋’的说法的。”

总起来看，持第一种意见的人较多，持第二种意见的人较少。我的看法是，第一种意见恐怕只是一种理想，未必能够达到，或者说很难实现；第二种意见又未免过于极端。

1979年罗新璋在“读傅雷作品随感”一文中说过这样一句话：“服尔德的机警尖刻，巴尔扎克的健拔雄快，梅里美的俊爽简括，罗曼罗兰的朴质流动，在原文上色彩鲜明，各具面貌，译文固然对各家的特色和韵味有相当体现，拿《老实人》的译文和《约翰•克利斯朵夫》一比，就能看出文风上的差异，但贯穿于这些译作的，不免有一种傅雷风格。”可见即使是名家的译作也难免既有原作的风格，又有译者的风格，而不可能是单纯的原作的风格。

二

翻译非文学作品，是否也有一个如何对待风格的问题呢？有的。

1979年，王佐良在“词义•文体•翻译”一文中说道：“一篇文章的风格只是作者为表达特定的内容而运用语言的个人方式，它与内容是血肉一体的，而不是外加的、美化的成分。”我的理解，这里所谓“一篇文章”泛指任何用文字写成的东西，非文学作品也不例外。在同一篇文章里，他还写道：“在翻译工作里，也必须注意语言与社会场合的关系。译文同样有一个适合社会场合的问题。译者同样必须能根据原文的要求，写出各种不同的语类、文体。例如翻译请贴、通知、布告、规章、病历与病情公告之类的“应用文体”，译者应该知道在译文里怎样寻到相等的内行的格式和说法。”

1982年，周熙良在“翻译三论”一文中写道：“实际上，许许多多的翻译只要文字通顺，就达到要求了，并不需要译成文学，也不可能译成文学。社会科学文章、报纸社论、科技文章、调查报告、都属这一类。”他还说：“美既不能用，雅又不能照严复当时提出的那样去理解，那么究竟应当怎样理解呢？我认为应当作为‘得体’来理解。得体不仅仅指文笔，而是指文笔基本上必须根据内容来定；文笔必须具有与其内容相适应的风格。”

我觉得，文学作品的风格可能因人而异，每个作家都有自己的风格。而非文学作品则往往是某种类型的文章具有一些共同的特点，形成这类文章的共同风格。无论是谁写作，都会采用这种风格。比如科学论文和法律文件，在用词方面力求准确，在表达方面力求清楚易懂，着重客观叙述，不带感情色彩，好像一个人在板起面孔来说话。而科普文章或普法读物则要使用生动的语言，灵活的句子，让读者觉着你在微笑着向他传授知识，或说明道理。用中文写文章是这样，用英文写文章也是这样，这两种语言是相通的。例如《世界版权公约》第二条第二款：

Unpublished works of nationals of each Contracting State shall enjoy in each other Contracting State the same protection as that other State accords to unpublished works of its own nationals, as well as the Protection specially granted by this Convention.

任何成员国国民未出版的作品，在其他各成员国中均享有后者给予其国民之未出版的作品同等的保护，并享有本公约所专门授予的保护。

这段译文既符合原文的风格，也符合中文法律条文共同的风格。如此说来，你看到文字如此谨严的原文时，只要译成同样谨严的文字就行了。所以，在风格问题上，翻译非文学作品比翻译文学作品简单多了。风格也不是那么虚无缥缈、不可捉摸了。你说是不是？

“对于我们并非专门从事文学翻译的初学者来说，在表达方面只要做到两点就够了。第一，能区别口语与书面语，该文的时候文，该白的时候白，翻译对话像对话，翻译叙述像叙述；第二，能根据不同的文体使用不同的语言，翻译新闻像新闻，翻译文件像文件，翻译故事像故事，翻译诗歌像诗歌。如果在正确理解原文的基础上，能使译文做到这两点，这就很不错了。”这段话是我在《英汉翻译教程》一书中提出的目标。你同意吗？

⒈一词多义。弄清原文的意思，在汉语中选用适当的词语。例如：
Born in 1879 in Ulm, Germany, Albert Einstein was two years old when his parents moved to Munich, where his father opened a business in electrical supplies.
阿尔伯特·爱因斯坦于1879年出生在德国的乌尔姆城。在他两岁的时候，父母移居慕尼黑。他的父亲在慕尼黑开了一家工厂，生产电气器材。（句中business一词，据有关资料介绍是指factory，而不是store，故译作“工厂”。

⒉英语名词和介词用得多，汉语动词用得多。
Psychologically there are two dangers to be guarded against in old age. One of these is undue absorption in the past.
从心理方面来说，到了老年，有两种危险倾向需要注意防止。一是过分地怀念过去。（如译作“对过去的过分怀念”，则不顺。

⒊英语代词用得多，汉语实词用得多。在一个句子里，英语可以先出代词，后出实词；汉语则先出实词，后出代词。
One day, while I was playing with my new doll, Miss Sullivan put my big rag doll into my lap also, spelled “d-o-l-l” and tried to make me understand that “d-o-l-l” applied to both.
有一天我正在玩一个新娃娃，沙利文小姐把我的大布娃娃也放在我腿上，然后写了“d-o-l-l”这几个字母，她是想让我知道“d-o-l-l”既可以指新娃娃，也可以指旧娃娃。（如译作“指二者”，就不顺；如译作“两个都指”，意思既不清楚，句子也压不住。
If they are disappointed at one place, the drillers go to another.
钻探石油的人如果在一个地方得不到预期的结果，便到另一个地方去钻探。

⒋英语动词有时态，时间概念往往通过时态表现出来：汉语动词没有时态，表示不同的时间，往往需要加时间状语。
It is like a dream to me now, floating through my mind in slow motion. Many children were playing close to the water, and we were stunned by their ignorance and daring.
现在回想起来，就仿佛是一场梦，当时的情景还在我脑海里缓缓浮动。那一天，许多孩子在靠近水边的地方玩耍，他们那样大胆，不知道危险就在眼前，使我们非常吃惊。（译文加了“那一天”。

⒌英语被动语态用得多，汉语被动式用得少，有时不用被动形式也可以表示被动的含义，有时可以用无主语句。
When the whale is killed, the blubber is stripped off and boiled down, either on board ship or on shore.
鲸鱼杀死以后，把鲸脂剥下来熬油，这项工作有的是在船上进行的，有的是在岸上进行的。（不一定译成“鲸鱼被杀死以后”，不用“被”字仍可表示被动的含义。
Great sums of money have been spent, for example in the deserts of Egypt, in “prospecting” for oil.
在石油“勘探”方面，已经花了大笔的钱，比如在埃及的沙漠里进行的勘探工作就是如此。（原文是被动语态，但未说明谁是施动者。译文用了无主句。

⒍英语并排用几个名词、动词或形容词时，其排列顺序可能要考虑到词的长短（长的放在后面，这样节奏较好或分量的轻重（重的放在后面，这样不显得头重脚轻。汉语除了考虑常用的顺序以外，还常常考虑词的音调。分量的轻重关系不大，常把分量重的词放在前面。
…setting aside big tracts of land where nobody can fish, shoot, hunt, nor harm a single living creature with furs, fins or feathers.
……圈出大片土地，不准钓鱼，不准打鸟，不准打猎，凡是长皮的，长毛的或者长鳃的动物，一概不许伤害。（原文fish, shoot, hunt,由轻到重，feathers最长，放在最后。汉语则“长皮的，长毛的”连下来较顺。

7.英语一般避免重复，代称用得多，不但名词可以用代词来替代，动词、形容词也有相应的词来替代。汉语则不怕重复，实称用得多。
English grammar is very difficult and few writers have avoided making mistakes in it.
英语语法十分困难，作家很少不犯语法错误的。（译文重复“语法”二字。

8.英语连词用得多，汉语连词用得少。例如表示条件或原因，汉语不一定用“如果”或“因为”之类的词，意思就包含在上下文里面了。
This film showed how they put aside a thousand acres out West where the buffaloes roam and nobody can shoot a single one of them. If they do, they get in jail.
电影演的是他们怎么在西边儿把一千英亩土地划出来，让水牛自由行动，谁也不准开枪打死一只。打死了，就得坐牢。（译文第二句没有用连词，没有用主语，重复了第一句里的“打死”二字。

9.词的搭配，如形容词与名词的搭配，副词和动词的搭配，主语与谓语的搭配等，英语可以用的搭配，往往不能直接译成汉语，这就需要选择适当的词语，或者改变句子的结构。

The road we have long been traveling is deceptively easy, a smooth superhighway on which we progress with great speed, but at its end lies disaster.
我们一直在走的这条路表面上很好走，是一条平坦的超级公路，我们可以高速前进，但是走到尽头却要遇到灾难。（原文lies disaster 不能直译，只好改变句子结构，译作“遇到灾难”。

10.英语常以抽象名词做主语，后面接表示具体动作的动词。这种主谓搭配，在汉语里是很少用的，一般都要改变句子结构。
Anger and bitterness had preyed upon me continually for weeks and a deep languor had succeeded this passionate struggle.
几个星期以来，我又气又恨，感到非常苦恼，这种感情上的激烈斗争过去之后，我感到浑身无力。

11.英语有些副词和动词的搭配无法直接译过来，可将原文副词的含义译成谓语或分句，放在句末。
So heedful a writer as Henry James, for instance, on occasion wrote so ungrammatically that a schoolmaster, finding such errors in a schoolboy’s essay, would be justly indignant.
就拿亨利·詹姆士来说吧，连他这样细心的作家写的东西，有时也不合语法。要是小学老师在学生的作文里发现那样的错误也会生气，而生气是完全应该的。

12.英语有些副词放在句首，具有丰富的内容，译成汉语可以适当地加以发挥。
Ideally, one day, researchers will know enough about the genesis of earthquakes……
最理想的情况是，有朝一日研究人员能够对地震的成因……有足够的了解。

13.主语的位置。英语往往把目的状语或其他成分放在句首，然后再出主语，主语与动词靠得较近。汉语则往往先出主语。
To protect the whale form the cold of the Arctic seas, nature has provided it with a thick covering of fat called blubber.
大自然为了保护鲸鱼，使它不致在北冰洋受冻，便让它长了厚厚的一层脂肪，叫做鲸脂。

14.英语的书面语差不多每个句子都要有主语，汉语的主语则不那么重要，如果前面已把主语说清楚，后面的句子不一定用主语。甚至在一个句子里应该出现另外一个主语的时候，这个主语仍然可以省略。
They used this kind of scare tactic when I was growing up. I wonder what they use today.
我小的时候，他们用过这种吓唬人的办法。现在用什么办法，就不得而知了。（译文第二句，两个主语“他们”和“我”都没有出现。

15.英语有who, which等词,可以引出定语从句，汉语多用并列分句，或单成一句，有时可把定语从句先处理。
Richardson, who served as both Secretary of Defense and Secretary of Health, Education and Welfare during the Nixon Administration, was talking about the negotiations for a Law of the Sea treaty, which came to a virtual conclusion last week after six years of deliberations.
理查森曾在尼克松政府中担任国防部长和卫生、教育和福利部长，他是在谈到关于海洋法条约的谈判时说这番话的。（译文用了并列分句
I have never had much patience with the writers who claim from the reader an effort to understand their meaning.
有些作家，读者要费力气才能看懂他们的意思，我对这样的作家一向是没有多少耐心的。（原文中的定语从句在译文中提前处理。

16.英语的主语部分可以很长，其中包括几个介词引导的短语作定语，汉语往往用分句来表达，或者独立成句。
The 180-page document, with more than 300 articles and eight annexes, definitively covers every conceivable issue dealing with the seas, from the definition of what constitutes an island to the jurisdiction over fish that live in fresh water but spawn in the ocean.
这份长达一百八十页的文件，有三百余条，并有八个附件。它涉及能够想到的每一个与海洋有关的问题，从岛屿的定义，到对在淡水生长而在海洋产卵的鱼类的管辖权，都做了明确的规定。（原文中的主语部分独立成句。

17.英语除了有who, which等词外，还有动词的-ing形式，因此句子可以很长，但组织得很严密。汉语叙事，则多用并列结构，一层一层地把事情说清楚。有时可以把较长地句子译成几个短句。
In the winter of 1879, James Lecky, exchequer clerk from Ireland, and privately interested in phonetics, keyboard temperament, and Gaelic, all of which subjects he imposed on me, dragged me to a meeting of a debating society called The Zetetical: a junior copy of the once well known Dialectical Society founded to discuss John Stuart Mill’s Essay on Liberty when that was new. 　　1879年冬天，詹姆斯·莱基拉我去参加一次辩论会。莱基是爱尔兰人，在财政部门当职员，有空喜欢研究语音，练习弹琴，学习盖尔语，他还硬让我也学这些东西。这次他带我去参加的辩论会是一个名叫“探索学会”的团体举办的。当年约翰·斯图尔特·米尔的文章《论自由》刚刚发表时候，成立过一个“辩证学会”来讨论这篇文章，这个学会曾名噪一时。探索学会就是仿照这个学会建立起来的，只是没有它那么有名罢了。（原文虽然较长，但并不很复杂。主语部分有一个同位语和一个定语从句，谓语部分有一个同位语和一个状语从句。译文则分成了五个句子。

18.汉语一般不用一连串的定语，一连串的“的字。适当地在“的”字前增加动词，就显得有些变化，不那么单调。
The resounding success of the Curacao experiment whetted the appetites of Florida livestock raisers for a similar feat that would relieve them of the scourge of screw-worms.
库拉索岛上的实验取得巨大的成功.引起了佛罗里达州牲畜饲养者的兴趣.他们也想以同样的办法消除螺旋锥蝇这一祸害.(原文主语部分是一名词定语,若译作“库拉索岛上的实验的巨大成功”,就连用了两个“的”字.如在第二个“的”字前面加上“取得”二字，就好一点。现在把这一部分译成一个分句就更好了。

19.英语在一个句子里往往先说个人的感受，再说与感受有关的动作，最后才说最初发生的事情。汉语则相反，往往按照事情发生的顺序来叙述，最后才说个人的感受。
The most important day I remember in all my life is the one on which my teacher，Anne Mansfield Sullivan, came to me. I am filled with wonder when I consider the immeasurable contrast between the two lives which it connects.
在我的记忆里，安妮·曼斯菲尔德·沙利文老师来的那一天，是我一生中最重要的日子。从这一天开始，我的生活和以前迥然不同，一想到这一点，我就感到非常兴奋。

20.表达同样的意思，英语的结构比较紧，汉语的结构比较松。
A gang of men, under the direction of their energetic and likeable foreman, 25-year-old Phineas P. Gage, was working on a new line of the Rutland and Burlington railroad.
一伙工人正跟着他们的领班在拉特兰－伯灵顿铁路的新线路上干活。这位领班名叫菲尼斯·P·盖奇，二十五岁，他精力充沛，待人和气。（原文是一简单句，有一个主语，一个谓语动词，却包含了这么多内容，结构显得比较紧。译文分为两句，第二句还包含两个并列分句，结构显得比较松。

21.拆句的情况多，合句的情况少。
Poets as we know have always a made great use of alliteration. They are persuaded that the repetition of a sound gives an effect of beauty.
我们知道，诗人一般总喜欢押头韵，觉得重复一个声音会产生美的效果。（原文两句都比较短，译文合成一句，语气较顺。

22.注意文体，应该用口语的地方，选用适合口语的词句。
“I remember thinking, ‘No. No. It’s not Jackson, it’s not my husband, it’s not my Jackson,’” she said. “But it was. He was lying in the street, right across from our house. The police said a man shot him over a parking space.”
“记得我当时就想:‘不，不。不是杰克逊，不是我丈夫，不是我的杰克逊’”她说。“可是，那不是别人，正是他。他躺在大街上，就在我们的房子对面。警察说，为了争一块停车的地方，人家把他打死了。”

23.一段文章的最后一句，特别是全文最后一段的最后一句，要比较有力，否则文章煞不住。中英文都是这样。翻译时就要把这最后一句的分量表达出来，给人以深刻的印象。
Words have weight, sound and appearance; it is only by considering these that you can write a sentence that is good to look at and good to listen to.
词具有一定的分量、声音和形状，只有考虑到这些因素，写出来的句子才能既好听，又好看。（若把“好听”放在最后，就压不住了。

24.题目可以照原文译，也可以根据文章的内容拟定。
A Valentine to One Who Cared Too Much.
衷肠曲（这个题目是参照文章的内容拟定的。原题的意思是：在情人节写给一个人的信，这个人关心的事情太多了。

25.遇到中国读者可能不熟悉的典故、人名、地名等，除了加注以外，还可以在译文中加几个字，略加说明。
I learned a great many new words that day. I do not remember what they all were; but I do know that mother, father，sister, teacher were among them — words that were to make the world blossom for me, “like Aaron’s rod, with flowers.”
那一天我学了许多新词，也记不清都有哪些词了。但是其中肯定有“母亲”、“父亲”、“姐姐”、“老师”——后来就是这些词把一个美好的世界展现在我的面前，就像《圣经》上说的“亚伦的杖开了花”一样。（这个典故出自《旧约·民数记》第17章第8节。为了帮助中国读者了解，译文加了“就像《圣经》上说的”几个字。

定语如果不译成定语，又能译成什么呢？

关于定语从句的译法，已经看到不少文章。各种教程和专著中也有专门的章节加以论述。这里只举两个例子。

例1 The police are concerned for the safety of the 12-year-old boy who has been missing for three days.
那个12岁的男孩失踪三天了，警方对他的安全感到担忧。

例2 Each of London’s districts had a distinct character that marked it off from its neighbours.
伦敦的每个区都有鲜明的特征，与邻近地区不同。

例1的译文用了两个主谓结构，也可以说是两个并列短句。若译作“警方对那个已失踪三天的12岁男孩的安全感到担忧”，异文就因定语太长而不顺了。例2的译文用了一个主语带两个并列的谓语。总之，这两个例子，原文都是主从结构，而译文都是并列结构。这也正是英汉两种语言在句子结构方面最大的区别。

例3 Police investigating the train derailment have not ruled out sabotage.
警方调查火车出轨事件，没有排除人为破坏的可能。

例4 Any event attended by the actor received widespread media coverage.
这位演员参加任何一项活动，媒体都作了广泛报道。

例3和例4，原文各有一个分词短语*作定语：investigating…和attended by …。例3的译文用了一个主语带两个并列谓语，例4的译文用了两个主谓结构，这和上回所说的定语从句的译法是完全一样的。译文中没有出现“调查火车出轨事件的警方”之类的话。

例5 He was the only one to speak out against the decision.
只有他站出来反对那项决定。

例6 He had long coveted the chance to work with a famous musician.
他长期渴望有机会与著名音乐家一起工作。

例5和例6，原文各有一个动词不定式短语作定语：to speak out … 和 to work with …。例5的译文直接把定语变成了谓语。例6的译文用了一个“连动式”（参看胡裕树《现代汉语》第363页），把原文动词不定式短语化作“连动谓语”的一部分。这样处理，译文比较简洁。我们设想一下，假如例5保持原文的结构，译为：“他是唯一一个站出来反对那项决定的人”，一个17个字的句子里，定语竟占了14个字，是不是显得长了一点？

例7 The cut in interest rates is good news for homeowners.
降低利率对于私房买主来说是个福音。

例8 I admire her coolness under pressure.
我佩服她在压力下能保持冷静。

例7和例8，原文各有一个介词短语作定语：in interest rates 和 under pressure。译文没有按原文的结构，译作“利率的降低”和“在压力下的冷静”，而是加了动词，译为“降低利率”和“在压力下能保持冷静”。我感觉，相对而言，英语名词用的多，汉语动词用的多。英语里常见一个句子只有一个谓语动词，剩下一大堆名词，用介词串连起来。这种句子译成汉语时，往往需要增加一些动词，这样才能使译文顺畅。

最后谈一谈单词作定语的问题。有人可能觉得，遇到单词作定语时，主要是个选词问题，只要选一个适当的词放在那里就行了。在有些情况下，也的确是这样，但有时也不这么简单。

例9 Loose clothing gives you greater freedom of movement.
衣服宽松，可以活动自如。

例10 I don’t want you mucking up my nice clean floor.
我这地板又干净，又漂亮，不想让你弄脏。

这两句译文都把定语变成了谓语，句子中间有停顿，听起来从容、自然。若照原文的结构，译成“宽松的衣服使你活动起来更为自在”和“我不想让你弄脏我干净漂亮的地板”，倒显得过于拘谨了。

例11 A few cushions formed a makeshift bed.
临时用几个垫子拼了一张床。

例12 His mere presence made her feel afraid.
他当时在场，这就足以让她害怕了。

这两句译文都把定语变成了状语，这也是翻译过程中常用的一种方法。汉语总说“拼了一张临时床”，听起来很怪，那就不如说“临时……拼了一张床”了。mere是用来加强语气的，但mere presense 在汉语里很难找到相应的搭配，只好在后半句用“足以”来加强语气了。

例13 With a few notable exceptions, everyone gave something.
人人都给了些东西，只有几个人例外，很是显眼。

例14 It’s been a nail-biting couple of weeks waiting for my results.
这两个星期等结果，弄得我坐卧不安。

这两句译文都把定语放到句子末尾来处理。notable和nail-biting在原来的位置上是很难译的，那就最后来处理吧。在汉语句子里，往往先说具体的事情，最后才评论、表态，或说出自己的感受。

定语是一种修饰语，状语也是一种修饰语，和定语有相似之处，这里就不多说了，请读者自己去琢磨。

在英译汉方面，除了理解问题外，我集中谈了一个定语问题。这是因为我在审订译稿的过程中发现，许多句子问题就在于定语没有处理好，或者放大一点说，修饰语没有处理好。因此，把修饰语处理好，译文的质量就能提高一大步。不知你有没有同感。

看一篇东西，可以有不同的目的。若为获取信息，抓住大意就可以了。

若是为了消遣，那就可以看懂多少算多少。若是为了翻译，那就非透彻理解原文不可。

有时似乎觉得懂了，但翻译起来还是不知如何下手，究其原因，可能仍是未能真正理解原文。在这种情况下，若勉强去译，便会采取机械的办法，逐字翻译，许多误译就是这样产生的。

例1  We want to get all the parties back to the negotiating table.
例2  Their differences have been thrown into sharp relief by the present crisis.

虽然party一词可以指“政党”，但此处与negotiating table相联系，便指“谈判的一方”了。所以，例1的意思是：我们想把有关各方拉回到谈判桌上来。Differences一词本身是有“差别”的意思，但在这个上下文里，它却指“意见分歧”。例2的意思是：目前的危机使得他们的分歧更加引人注目。

例3  He was found guilty of murder.
例4  There is no right of appeal against the decision.

涉及法律时，find不一定表示“发现”，而可以指“裁决”、“判决”。Appeal也不一定表示“呼吁”，而可以指“上诉”。因此，例3的意思是：经裁决，他犯有谋杀罪。例4的意思是：关于这项判决，没有上诉权。

例5  The end result of her hard work was a place at medical school.
例6  To graduate with honors from college

在学校教育方面，work就指学习，a place就是an opportunity to study at a university,也就是一个入学名额，而不是一个工作职位。With honors指的是“以优异的成绩”，而不是“感到荣幸”。因此，例5的意思是：她勤劳学习，终于进了医学院。例6的意思是：以优异的成绩从大学毕业。

例7  This new production radically reinterprets the play.
例8  The doorway is a 19th century reconstruction of Norman work.

在文化方面，production和戏剧相联系，就指“一次演出”。因此，例7的意思是：这次演出体现了对这部戏的全部理解。例8是什么意思呢？能不能译作：门廊是19世纪罗马建筑的翻版？不行。首先，Norman不是罗马，而是指11世纪欧洲大陆的诺曼人征服英国后在英国流行的诺曼式建筑风格；其次用“19世纪”修饰“罗马建筑”也是不行的。例8的意思是：门廊是19世纪时模仿诺曼式建筑修建的。

例9   You’ll be expected to replace any broken glasses.
例10  Round here, you leave school at sixteen and next thing you know, you’re married with three kids.

在生活方面，所谈内容往往与当地的风俗习惯相联系。二十年多前，我在澳大利亚到一位朋友家去做客。主人从商店租了一百只玻璃杯，打碎了一只，归还时就照价赔偿。例9就是店主对顾客说的一句话，意思是；玻璃杯如有损坏，你要负责赔偿。例10的用词很简单，但究竟是什么意思呢？能不能译作“这儿，你十六岁时离开了学校，接着，你带着三个孩子结了婚。”？或译作“……你和有三个孩子的人结了婚。”？从原文的时态看，这里说的不是一次性的已经完成的动作，而是一种反复出现的现象，句中的you也不是指具体的某人，而是泛指。这样就可以看出这句话说的是当地一种普遍的生活方式。因此，例10的意思是：这一带的人十六岁中学毕业，接着就结婚，生三个孩子。

例11  I hate to say I told you so.
例12  Ed couldn’t make it so they sent me instead.
例13  Go on – read it to us.

英语有许多习语（idioms）, 其含义往往不是从字面上可以看出的。以上三例中的I told you so，make it和go on都是习语，翻译时，不能取其字面上的含义，而要把它看作一个整体来处理。如果不知道它的意思，那就要到词典里去查一查。

如果你手边有一本Oxford Advanced Learner’s Dictionary,在词条tell里就可以查到I told you(so), 解释为：used when sth. bad has happened, to remind sb. that you warned them about it and they did not listen to you.得到这个解释之后，就能看出例11的意思不是“我真不想说是我告诉你的”，而是“我不愿意显得自己有先见之明。”

用同样的办法查make it, 可以查到4条解释，第3条解释为：to be able to be present at a place. 因此例12的意思就不是“埃德做不出来……”, 而是“埃德去不了，所以他们就派我去了。”

Go on共有8条解释，最后一条是：used to encourage sb. to do sth.因此，例13的意思就不是“继续—给我们读下去”，而是“念吧—念给我们听听。”

综上所述，一个词用在不同的场合会有不同的含义，译者不能只想到自己最熟悉的那个含义，而要充分利用上下文，依靠能够获得的相关信息，判断出词的确切含义。遇到习语，更要勤查词典，切忌忘文生意。

近年来，我参加了几本双语词典的审订工作，上面所举的例子都是我在实际工作中遇到的。我还发现，经我审订的译文，有的也还有改进的余地，甚至还有些错误没有改掉。这一方面说明个人的能力总是有限的，另一方面也说明保证译文不出错是很不容易的，翻译过程中需要照顾的地方很多，精力一分散，顾此失彼，便会出错。要想少出错误，译者必须兢兢业业，认真从事，慎之又慎。

上面说的是如何确切理解原文，以免误译。下面谈一谈怎样避免因表达不当而造成的误译。

例14  His novels nicely describe life in Britain between the wars.
他的小说细致地描述了两次大战期间英国的生活状况。

例15  No dessert for me, thanks. It was as much as I could do to finish the main course.
谢谢，别给我甜食了。我只能吃完主食。

看来译者不一定没有看懂原文，只是在用汉语表达时用词不精确。例14只要把“期间”改为“之间”就行了。例15把main course机械地译为“主食”，字面上好像是对应的，但译者忘了“主食”是与“副食”相对而言的，通常指“用粮食制成的饭食”，和main course不是一回事儿。因此，例15后一半可改为“我吃完这道主菜就不错了。”

要想避免这样的误译，可以倒回去，把译文和原文对照一下，看它是否和原文的意思相吻合。这样做，你觉得很困难吗？

1980年出版了张培基等四位学者编著的《英汉翻译教程》。作者在“翻译的标准”一节中写道：“我们主张把翻译标准概括为‘忠实、通顺’四个字。”“所谓忠实，首先指忠实于原作的内容。”“忠实还指保持原作的风格。”“所谓通顺，即指译文语言必须通顺易懂，符合规范。”

1983年出版了吕瑞昌等五位学者编著的《汉英翻译教程》。关于翻译标准的论述，与第一本书是一致的。书中写道：“我们不妨用‘信、顺’两字来概括我们今天汉英翻译的标准。所谓‘信’是指忠实于原文的内容，包括思想、感情、风格等，即把原文完整而准确地表达于译文中，对原文内容尽可能不增不减。所谓‘顺’，是指用词正确得体，行文流畅通顺，符合英语习惯;避免逐字死译、生搬硬套，使不懂汉语的英语读者也能看懂。”

这两本书是受教育部委托编写的高校通用教材，一本讲英译汉，一本讲汉译英，二十多年来，一直在我国高校广泛使用。

我基本上同意这两本书关于翻译标准的提法，但我不赞成把风格放在忠实里面来谈。我们不必因为严复提出了“信、达、雅”，谈翻译标准就一定要谈风格。因为风格是一个比较复杂的问题。把原文的风格完全翻译过来，这恐怕是不大可能的，但也不是说风格就完全不能翻。译者只能尽力而为。译文的风格除了包含一部分与原文一致的风格，必然还包含其他因素。而且翻译不同类型的作品，对风格的要求也不尽相同。英译汉还比较好办，汉译英就更难把握了。

我在99年为全国高等教育自学考试编写了一套教材，题为《英汉翻译教程》。关于翻译标准，我是这样写的：“对我们初学翻译的人来说，我想可以提出两条要求：（一）忠实；（二）通顺。‘忠实’主要是指内容……要力求准确地表达原作者的意思。‘通顺’指的是语言。如果原文是通顺易懂的，那么译文也要尽量做到通顺、易懂。”我认为，真正做到上述两条，也并不容易。风格在翻译过程中是个不可回避的问题，但可以慢慢展开讨论，而不必写在翻译标准之中。

十多年前，我对外国译者关于翻译标准的看法作过一些探讨，写过一篇文章，题为“外国译者追求什么样的译文？”， 发表在《中国翻译》1992年第4期上。现将其中的部分引文介绍如下。

K. J. Maidment 在其所译Minor Attic Orators写的序言（1940）中说道：“关于译文本身，我只需要说我的目标一直是既确切（accurate）,又通顺(readable),但我充分意识到往往二者都没有做到。”

G. P. Goold 在为其所译Propertius的Elegies一书写的序言（1990）中说道：“我在本书中主要是力图以可靠的拉丁文本和优美、确切的（graceful and accurate）英译本把普洛佩提乌斯介绍给尽可能多的读者：当然首先是介绍给古典文学学者和研究人员，但也同样介绍给一般的文学爱好者。”（这个版本是拉丁文和英文对照本。）

Michael R. Katz and William G. Wagner 在为车尔尼雪夫斯基的《怎么办？》英译本写的前言（1989）中说道：“出版这个新译本，是为了提供方便，使英国和美国读者第一次看到车尔尼雪夫斯基的《怎么办》一书的完整译本……我们希望这个完整、确切、通顺的（complete, accurate and readable）译本能使英美读者不仅了解车尔尼雪夫斯基这本小说对人类生活产生了多大的影响，而且了解它推动历史前进的动力是从哪里来的。”

Ronald Hingley  在为其所译《契珂夫全集》写的序言（1964）中说道：“主要目的是为舞台演出提供脚本。译本一向以高度确切（strict accuracy）为宗旨，但希望避免学究气。译本从未有意识地为了字面上的忠实而使得台词不能上口，或违背原作的精神。”

Michael Grant在为其所译《西塞罗选集》写的前言（1960）中说道：“译者的主要任务之一是使译文通顺 (readable )，否则就没有人看，也就不能达到介绍原作者的目的。在今天如果译者使用修辞色彩很浓的英语，他的译文就不会通顺，也就没有人看。……西塞罗的修辞手段是他所受的语言训练的产物，是他的风格中不可分割的一部分。如果丢掉它，你就丢掉了人们最赞赏他的一个方面，损失还不止于此。如果保留它，我在前面已经指出，你就丢掉了另外一样东西－当代通顺的英语。这种进退两难的困境是没有折中办法可以解决的。因此，我既然不准备放弃努力，要尽可能地接近真正的现代英语，就不得不放弃西塞罗的修辞手段。至于读者遭受的损失，我是非常清楚的。”

Horace C. P. McGregor翻译了西塞罗所著《论神性》一书。他在“译者的话”（1970）中说道：任何一篇文章都包含着妥协的成分。一个句子在这种语言里通顺流畅，在另一种语言里就会拖沓累赘。一个精彩的短语如果按字面译成另外一种语言里就可能不像样子。一个单词在另一种语言里也可能难以找到相应的词。……我的目标是真正的翻译，然而是低标准的，我有一定程度的自由，可以改变原来的语言形式，但决不有意识地脱离原作的意思和语气。最主要的是我力图使西赛罗的英文译本和拉丁文原文一样通顺（readable）。

Edward G. Seidensticker翻译了紫式部的《源氏物语》。他在前言 (1976)中指出：此前Arthur Waley翻译的《源氏物语》是很自由的，他作了大胆删节，也作了大量的增补与美化。他说：“新译本可以称得上是个全译本，但其字数比Waley大加删节的译本还要少。这就说明无论Waley取得了多么精彩的效果。……他的节奏(rhythms)是与原作迥然不同的，原作较为明快、凝练，用词节省，不罗嗦。如果说翻译的目标应该在一切重要方面包括节奏在内模仿原作的话，那么这里提供的译文规定要达到的目标，可以说比Waley的译文所要达到的目标多得多。”

George Gihiam 在美国康奈尔大学任职，参加了Norton Critical Edition这套丛书的编辑工作。他在为陀思妥耶夫斯基的《罪与罚》英译本写的序言（1989）中写道：“我们选择《罪与罚》一书的英译本，标准是这个译本能用当代英语确切地(accurately)体现陀思妥耶夫斯基的十九世纪俄语原作，能用今天的英语表现出和原作相一致的风格(style)，不以现代词语或维多利亚时代的词语歪曲原作，而且译文本身是通顺的(readable)。根据这些原则，我们认为Jessie Coulson的译本似乎是最好的译本，经与牛津大学出版社接洽，在这里重印出版。”

从以上几段引文来看，accuracy和readability 是译者追求的共同目标。其他方面，各位译者的侧重点是不同的，风格、精神、修辞手段、语气、节奏，不一而足，有时甚至故意反其道而行之，可见问题之复杂。
鉴于以上情况，我们在开始时不妨就以信（忠实）和达（通顺）为目标吧。你觉得这两条会很容易做到吗？