0

C++资源之不完全导引

Posted: October 26, 2006 at 11:06 am | Tags: blog, class, html, java, linux, python, unix, windows, 优化, 平台, 开发, 技术, 类

声明：

.本文2004年5月首发于《CSDN开发高手》，版权归该杂志与《程序员》杂志社所有。杂志限于篇幅部分内容有所删节，此处版本为相对完整版本。

.本文为介绍性文章，会随笔者学习C++语言不断更新。

库

在C++中，库的地位是非常高的。C++之父 Bjarne Stroustrup先生多次表示了设计库来扩充功能要好过设计更多的语法的言论。现实中，C++的库门类繁多，解决的问题也是极其广泛，库从轻量级到重量级的都有。不少都是让人眼界大开，亦或是望而生叹的思维杰作。由于库的数量非常庞大，而且限于笔者水平，其中很多并不了解。所以文中所提的一些库都是比较著名的大型库。

标准库

标准库中提供了C++程序的基本设施。虽然C++标准库随着C++标准折腾了许多年，直到标准的出台才正式定型，但是在标准库的实现上却很令人欣慰得看到多种实现，并且已被实践证明为有工业级别强度的佳作。

1、 Dinkumware C++ Library

参考站点：http://www.dinkumware.com/

P.J. Plauger编写的高品质的标准库。P.J. Plauger博士是Dr. Dobb’s程序设计杰出奖的获得者。其编写的库长期被Microsoft采用，并且最近Borland也取得了其OEM的license，在其C/C++的产品中采用Dinkumware的库。

2、 RogueWave Standard C++ Library

参考站点：http://www.roguewave.com/

这个库在Borland C++ Builder的早期版本中曾经被采用，后来被其他的库给替换了。笔者不推荐使用。

3、SGI STL

参考站点：http://www.roguewave.com/

SGI公司的C++标准模版库。

4、STLport

参考站点：http://www.stlport.org/

SGI STL库的跨平台可移植版本。

准标准库——Boost

Boost库是一个经过千锤百炼、可移植、提供源代码的C++库，作为标准库的后备，是C++标准化进程的发动机之一。 Boost库由C++标准委员会库工作组成员发起，在C++社区中影响甚大，其成员已近2000人。 Boost库为我们带来了最新、最酷、最实用的技术，是不折不扣的“准”标准库。

Boost中比较有名气的有这么几个库：
Regex
正则表达式库

Spirit
LL parser framework，用C++代码直接表达EBNF

Graph
图组件和算法

Lambda
在调用的地方定义短小匿名的函数对象，很实用的functional功能

concept check
检查泛型编程中的concept

Mpl
用模板实现的元编程框架

Thread
可移植的C++多线程库

Python
把C++类和函数映射到Python之中

Pool
内存池管理

smart_ptr
5个智能指针，学习智能指针必读，一份不错的参考是来自CUJ的文章：

Smart Pointers in Boost,哦，这篇文章可以查到，CUJ是提供在线浏览的。中文版见笔者在《Dr. Dobb’s Journal软件研发杂志》第7辑上的译文。

Boost总体来说是实用价值很高，质量很高的库。并且由于其对跨平台的强调，对标准C++的强调，是编写平台无关，现代C++的开发者必备的工具。但是Boost中也有很多是实验性质的东西，在实际的开发中实用需要谨慎。并且很多Boost中的库功能堪称对语言功能的扩展，其构造用尽精巧的手法，不要贸然的花费时间研读。Boost另外一面，比如Graph这样的库则是具有工业强度，结构良好，非常值得研读的精品代码，并且也可以放心的在产品代码中多多利用。

参考站点：http://www.boost.org（国内镜像：http://www.c-view.org/tech/lib/boost/index.htm）

GUI

在众多C++的库中，GUI部分的库算是比较繁荣，也比较引人注目的。在实际开发中，GUI库的选择也是非常重要的一件事情，下面我们综述一下可选择的GUI库，各自的特点以及相关工具的支持。

1、 MFC

大名鼎鼎的微软基础类库（Microsoft Foundation Class）。大凡学过VC++的人都应该知道这个库。虽然从技术角度讲，MFC是不大漂亮的，但是它构建于Windows API 之上，能够使程序员的工作更容易,编程效率高，减少了大量在建立 Windows 程序时必须编写的代码，同时它还提供了所有一般 C++ 编程的优点，例如继承和封装。MFC 编写的程序在各个版本的Windows操作系统上是可移植的，例如，在 Windows 3.1下编写的代码可以很容易地移植到 Windows NT 或 Windows 95 上。但是在最近发展以及官方支持上日渐势微。

2、 QT

参考网站：http://www.trolltech.com/

Qt是Trolltech公司的一个多平台的C++图形用户界面应用程序框架。它提供给应用程序开发者建立艺术级的图形用户界面所需的所用功能。Qt是完全面向对象的很容易扩展，并且允许真正地组件编程。自从1996年早些时候，Qt进入商业领域，它已经成为全世界范围内数千种成功的应用程序的基础。Qt也是流行的Linux桌面环境KDE 的基础，同时它还支持Windows、Macintosh、Unix/X11等多种平台。

3、WxWindows

参考网站：http://www.wxwindows.org/

跨平台的GUI库。因为其类层次极像MFC，所以有文章介绍从MFC到WxWindows的代码移植以实现跨平台的功能。通过多年的开发也是一个日趋完善的GUI库，支持同样不弱于前面两个库。并且是完全开放源代码的。新近的C++ Builder X的GUI设计器就是基于这个库的。

4、Fox

开放源代码的GUI库。作者从自己亲身的开发经验中得出了一个理想的GUI库应该是什么样子的感受出发，从而开始了对这个库的开发。有兴趣的可以尝试一下。

参考网站：http://www.fox-toolkit.org/

5、 WTL

基于ATL的一个库。因为使用了大量ATL的轻量级手法，模板等技术，在代码尺寸，以及速度优化方面做得非常到位。主要面向的使用群体是开发COM轻量级供网络下载的可视化控件的开发者。

6、 GTK

参考网站：http://gtkmm.sourceforge.net/

GTK是一个大名鼎鼎的C的开源GUI库。在Linux世界中有Gnome这样的杀手应用。而GTK就是这个库的C++封装版本。

网络通信

ACE

参考网站：http://www.cs.wustl.edu/~schmidt/ACE.html

C++库的代表，超重量级的网络通信开发框架。ACE自适配通信环境（Adaptive Communication Environment）是可以自由使用、开放源代码的面向对象框架，在其中实现了许多用于并发通信软件的核心模式。ACE提供了一组丰富的可复用C++包装外观（Wrapper Facade）和框架组件，可跨越多种平台完成通用的通信软件任务，其中包括：事件多路分离和事件处理器分派、信号处理、服务初始化、进程间通信、共享内存管理、消息路由、分布式服务动态（重）配置、并发执行和同步，等等。

StreamModule

参考网站：http://www.omnifarious.org/StrMod/

设计用于简化编写分布式程序的库。尝试着使得编写处理异步行为的程序更容易，而不是用同步的外壳包起异步的本质。

SimpleSocket

参考网站：http://home.hetnet.nl/~lcbokkers/simsock.htm

这个类库让编写基于socket的客户/服务器程序更加容易。

A Stream Socket API for C++

参考网站：http://www.pcs.cnu.edu/~dgame/sockets/socketsC++/sockets.html

又一个对Socket的封装库。

XML

Xerces

参考网站：http://xml.apache.org/xerces-c/

Xerces-C++ 是一个非常健壮的XML解析器，它提供了验证，以及SAX和DOM API。XML验证在文档类型定义(Document Type Definition，DTD)方面有很好的支持，并且在2001年12月增加了支持W3C XML Schema 的基本完整的开放标准。

XMLBooster

参考网站：http://www.xmlbooster.com/

这个库通过产生特制的parser的办法极大的提高了XML解析的速度，并且能够产生相应的GUI程序来修改这个parser。在DOM和SAX两大主流XML解析办法之外提供了另外一个可行的解决方案。

Pull Parser

参考网站：http://www.extreme.indiana.edu/xgws/xsoap/xpp/

这个库采用pull方法的parser。在每个SAX的parser底层都有一个pull的parser，这个xpp把这层暴露出来直接给大家使用。在要充分考虑速度的时候值得尝试。

Xalan

参考网站：http://xml.apache.org/xalan-c/

Xalan是一个用于把XML文档转换为HTML，纯文本或者其他XML类型文档的XSLT处理器。

CMarkup

参考网站：http://www.firstobject.com/xml.htm

这是一种使用EDOM的XML解析器。在很多思路上面非常灵活实用。值得大家在DOM和SAX之外寻求一点灵感。

libxml++

http://libxmlplusplus.sourceforge.net/

libxml++是对著名的libxml XML解析器的C++封装版本

科学计算

Blitz++

参考网站：http://www.oonumerics.org/blitz/

Blitz++ 是一个高效率的数值计算函数库，它的设计目的是希望建立一套既具像C++ 一样方便，同时又比Fortran速度更快的数值计算环境。通常，用C++所写出的数值程序，比 Fortran慢20%左右，因此Blitz++正是要改掉这个缺点。方法是利用C++的template技术，程序执行甚至可以比Fortran更快。Blitz++目前仍在发展中，对于常见的SVD，FFTs，QMRES等常见的线性代数方法并不提供，不过使用者可以很容易地利用Blitz++所提供的函数来构建。

POOMA

参考网站：http://www.codesourcery.com/pooma/pooma

POOMA是一个免费的高性能的C++库，用于处理并行式科学计算。POOMA的面向对象设计方便了快速的程序开发，对并行机器进行了优化以达到最高的效率，方便在工业和研究环境中使用。

MTL

参考网站：http://www.osl.iu.edu/research/mtl/

Matrix Template Library(MTL)是一个高性能的泛型组件库，提供了各种格式矩阵的大量线性代数方面的功能。在某些应用使用高性能编译器的情况下，比如Intel的编译器，从产生的汇编代码可以看出其与手写几乎没有两样的效能。

CGAL

参考网站：www.cgal.org

Computational Geometry Algorithms Library的目的是把在计算几何方面的大部分重要的解决方案和方法以C++库的形式提供给工业和学术界的用户。

游戏开发

Audio/Video 3D C++ Programming Library

参考网站：http://www.galacticasoftware.com/products/av/

AV3D是一个跨平台，高性能的C++库。主要的特性是提供3D图形，声效支持（SB,以及S3M），控制接口（键盘，鼠标和遥感），XMS。

KlayGE

参考网站：http://home.g365.net/enginedev/

国内游戏开发高手自己用C++开发的游戏引擎。KlayGE是一个开放源代码、跨平台的游戏引擎，并使用Python作脚本语言。KlayGE在LGPL协议下发行。感谢龚敏敏先生为中国游戏开发事业所做出的贡献。

OGRE

参考网站：http://www.ogre3d.org

OGRE（面向对象的图形渲染引擎）是用C++开发的，使用灵活的面向对象3D引擎。它的目的是让开发者能更方便和直接地开发基于3D硬件设备的应用程序或游戏。引擎中的类库对更底层的系统库（如：Direct3D和OpenGL）的全部使用细节进行了抽象，并提供了基于现实世界对象的接口和其它类。

线程

C++ Threads

参考网站：http://threads.sourceforge.net/

这个库的目标是给程序员提供易于使用的类，这些类被继承以提供在Linux环境中很难看到的大量的线程方面的功能。

ZThreads

参考网站：http://zthread.sourceforge.net/

一个先进的面向对象，跨平台的C++线程和同步库。

序列化

s11n

参考网站：http://s11n.net/

一个基于STL的C++库，用于序列化POD，STL容器以及用户定义的类型。

Simple XML Persistence Library

参考网站：http://sxp.sourceforge.net/

这是一个把对象序列化为XML的轻量级的C++库。

字符串

C++ Str Library

参考网站：http://www.utilitycode.com/str/

操作字符串和字符的库，支持Windows和支持gcc的多种平台。提供高度优化的代码，并且支持多线程环境和Unicode，同时还有正则表达式的支持。

Common Text Transformation Library

参考网站：http://cttl.sourceforge.net/

这是一个解析和修改STL字符串的库。CTTL substring类可以用来比较，插入，替换以及用EBNF的语法进行解析。

GRETA

参考网站：http://research.microsoft.com/projects/greta/

这是由微软研究院的研究人员开发的处理正则表达式的库。在小型匹配的情况下有非常优秀的表现。

综合

P::Classes

参考网站：http://pclasses.com/

一个高度可移植的C++应用程序框架。当前关注类型和线程安全的signal/slot机制，i/o系统包括基于插件的网络协议透明的i/o架构，基于插件的应用程序消息日志框架，访问sql数据库的类等等。

ACDK – Artefaktur Component Development Kit

参考网站：http://acdk.sourceforge.net/

这是一个平台无关的C++组件框架，类似于Java或者.NET中的框架（反射机制，线程，Unicode，废料收集，I/O，网络，实用工具，XML，等等），以及对Java, Perl, Python, TCL, Lisp, COM 和 CORBA的集成。

dlib C++ library

参考网站：http://www.cis.ohio-state.edu/~kingd/dlib/

各种各样的类的一个综合。大整数，Socket，线程，GUI，容器类,以及浏览目录的API等等。

Chilkat C++ Libraries

参考网站：http://www.chilkatsoft.com/cpp_libraries.asp

这是提供zip，e-mail，编码，S/MIME，XML等方面的库。

C++ Portable Types Library (PTypes)

参考网站：http://www.melikyan.com/ptypes/

这是STL的比较简单的替代品，以及可移植的多线程和网络库。

LFC

参考网站：http://lfc.sourceforge.net/

哦，这又是一个尝试提供一切的C++库

其他库

Loki

参考网站：http://www.moderncppdesign.com/

哦，你可能抱怨我早该和Boost一起介绍它，一个实验性质的库。作者在loki中把C++模板的功能发挥到了极致。并且尝试把类似设计模式这样思想层面的东西通过库来提供。同时还提供了智能指针这样比较实用的功能。

ATL

ATL(Active Template Library)是一组小巧、高效、灵活的类，这些类为创建可互操作的COM组件提供了基本的设施。

FC++: The Functional C++ Library

这个库提供了一些函数式语言中才有的要素。属于用库来扩充语言的一个代表作。如果想要在OOP之外寻找另一分的乐趣，可以去看看函数式程序设计的世界。大师Peter Norvig在 “Teach Yourself Programming in Ten Years”一文中就将函数式语言列为至少应当学习的6类编程语言之一。

FACT!

参考网站：http://www.kfa-juelich.de/zam/FACT/start/index.html

另外一个实现函数式语言特性的库

Crypto++

提供处理密码，消息验证，单向hash，公匙加密系统等功能的免费库。

还有很多非常激动人心或者是极其实用的C++库，限于我们的水平以及文章的篇幅不能包括进来。在对于这些已经包含近来的库的介绍中，由于并不是每一个我们都使用过，所以难免有偏颇之处，请读者见谅。

书籍

以前熊节先生曾撰文评论相对于Java程序设计语言，C++的好书多如牛毛。荣耀先生在《程序员》杂志上撰文《C++程序设计之四书五经》也将本领域内几乎所有的经典书籍作了全面的介绍,任何关于书的评论此时看来便是很多余的了。个人浅见，除非你打算以C++作为唯一兴趣或者生存之本，一般读者确实没有足够的时间和必要将20余本书籍全部阅读。更有参考价值的是荣耀先生的另一篇文章：《至少应该阅读的九本C++著作》，可以从下面的地址浏览到此文：

http://www.royaloo.com/articles/articles_2003/9CppBooks.htm

下面几本书对于走在C++初学之路上的读者是我们最愿意推荐给大家的：

《C++ Primer》

哦，也许你会抱怨我们为什么不先介绍TCPL,但对于走在学习之路上的入门者，本书内容更为全面，更为详细易懂，我们称它为“C++的超级宝典”并不过分。配有一本不错的习题解答《C++ Primer Answer Book》可以辅助你的学习之路。

《Essential C++》

如果说《C++ Primer》是C++领域的超级宝典，那么此书作为掌握C++的大局观当之无愧。正如《.NET大局观》一书能够让读者全揽.NET，本书讲述了C++中最核心的全部主题。书虽不厚，内容精炼，不失为《C++ Primer》读者茶余饭后的主题回顾之作。

《The C++ Programming Language》

Bjarne为你带来的C++教程，真正能够告诉你怎么用才叫真正的C++的唯一一本书。虽然如同“某某程序设计语言”这样的书籍会给大家一个内容全揽，入门到精通的感觉，但本书确实不太适合初学者阅读。如果你自认为是一名很有经验的C++程序员，那至少也要反复咀嚼Bjarne先生所强调的若干内容。

《Effective C++》，《More Effective C++》

是的，正如一些C++爱好者经常以读过与没有读过上述两本作品来区分你是否是C++高手。我们也极力推崇这两本著作。在各种介绍C++专家经验的书籍里面，这两本是最贴近语言本质，看后最能够有脱胎换骨感觉的书，读此书你需每日三省汝身。

技术书籍仁者见仁，过多的评论反无太多意义，由读者喜好选择最适合自己的书方为上策。

资源网站

正如我们可以通过计算机历史上的重要人物了解计算机史的发展，C++相关人物的网站也可以使我们得到最有价值的参考与借鉴，下面的人物我们认为没有介绍的必要，只因下面的人物在C++领域的地位众所周知，我们只将相关的资源进行罗列以供读者学习，他们有的工作于贝尔实验室，有的工作于知名编译器厂商，有的在不断推进语言的标准化，有的为读者撰写了多部千古奇作……

Bjarne Stroustrup http://www.research.att.com/~bs/

Stanley B. Lippman

http://blogs.msdn.com/slippman/(中文版http://www.zengyihome.net/slippman/index.htm)

Scott Meyers http://www.aristeia.com/

David Musser http://www.cs.rpi.edu/~musser/

Bruce Eckel http://www.bruceeckel.com

Nicolai M. Josuttis http://www.josuttis.com/

Herb Sutter http://www.gotw.ca/

Andrei Alexandrescu http://www.moderncppdesign.com/

侯捷先生 http://www.jjhou.com

孟岩先生 先生繁忙于工作，痴迷于技术，暂无个人主页，关于先生的作品可以通过CSDN的专栏和侯先生的主页访问到。

荣耀先生 http://www.royaloo.com/

潘爱民先生 http://www.icst.pku.edu.cn/panaimin/pam_homepage.htm

除了上述大师的主页外，以下的综合类C++学习参考站点是我们非常愿意向大家推荐的：

CodeProject http://www.codeproject.com

CodeGuru http://www.codeguru.com

Dr. Dobb’s Journal http://www.ddj.com

C/C++ Users Journal http://www.cuj.com

C维视点 http://www.c-view.org

allaboutprogram http://www.allaboutprogram.com

其他资料

ISO IEC JTC1/SC22/WG21 – C++：标准C++的权威参考

http://anubis.dkuug.dk/jtc1/sc22/wg21/

C++ FAQ LITE — Frequently Asked Questions: 最为全面的C++FAQ

http://www.sunistudio.com/cppfaq/index.html

C/C++ 新闻组：

你不妨尝试从这里提问和回答问题，很多不错的Q&A资源……
.alt.comp.lang.learn.c-c++
这个简单些，如果你和我一样是个菜鸟

.comp.lang.c++.moderated
嗯，这个显然水平高一些

.comp.std.c++
如果你需要讨论标准C++相关话题的话

不得不写的结束语

结束的时候也是总结现状，展望未来的时候。虽然C++从脱胎于C开始，一路艰难坎坷的走过来，但是无论如何C++已经取得了工业基础的地位。文章列举的大量相关资源就是最好的证明，而业界的大量用C++写成的产品代码以及大量的C++职业工程师则是最直接的证明。同时，我们可以看到各个高校的计算机专业都开设有C++这门课程，网络上对于C++的学习讨论也从来都没有停过。但是，在Java和.NET两大企业开发平台的围攻下，给人的感觉是C++越来越“不行”了。

C++在面向企业的软件开发中，在开发便捷性等方面的确要比Java和C#差很多，其中一个问题是C++语言本身比较复杂，学习曲线比较陡峭，另外一个问题是C++标准化的时间太长，丧失了很多的壮大机会，耗费了很多精力在厂商的之间的斗争上，而C++的标准库离一个完善的程序开发框架还缺少太多太多的内容，各个第三方的类库和框架又在一致性和完整性上没法和随平台提供的框架相提并论。难道C++真的要退出历史舞台了？

从C++目前的活跃程度，以及应用现状来说是完全能够肯定C++仍然是软件工业的基础，也不会退出历史舞台的。另外从Boost，Loki这些库中我们也能够看到C++的发展非常活跃，对于新技术新思维非常激进，C++仍然广泛受到关注。从ACE在高性能通信领域的应用，以及MTL这样的库在数值计算领域的出色表现，我们可以看到C++在高性能应用场合下的不可替代的作用，而嵌入式系统这样的内存受限开发平台，比如Symbian OS上，C++已经发挥着并且将发挥更大的作用。可以预见的是以后的软件无论上层的应用怎么变，它的底层核心都会是由C/C++这样的系统级软件编写的，比如Java虚拟机，.NET Framwork。因为只有这样的系统级软件才能完全彻底的发挥机器的功能。

需要看到的是两个趋势，一个趋势是C++变得更加复杂，更加学院派，通过模板等有潜力的语法因素构造越来越精巧的库成为了现代C++的热点，虽然在利用库实现新的编程范式，乃至设计模式等方面很有开创意义，也确实产生了一些能够便捷开发的工具，但是更多的是把C++变得更加强大，更加复杂，也更加难懂，似乎也更加学院派，不得不说它正在向边缘化道路发展。另一个趋势是C++在主流的企业应用开发中已经逐渐退出了，ERP这样的企业软件开发中基本上不会考虑C++，除非需要考虑性能或者和遗留代码的集成这些因素。C++退守到系统级别语言，成为软件工业的基础是大势所趋。然而反思一下，真的是退守么？自从STL出现，无数的人风起云涌的开始支持C++,他们狂呼“我看到深夜消失了，目标软件工程的出现。我看到了可维护的代码。”是的，STL在可维护性下做得如此出色。但是又怎样呢？STL为C++铺平了现代软件工程的道路，而在上层应用程序软件开发领域这块场地早不单独属于C++,很多程序设计语言都做得很出色，疯狂的支持者会毫不犹豫地说我们应当支持C++,因为它是世界上最棒的语言。而坦率地说，你的腰杆真的那么硬么？也许只是在逃避一些事实。C++是优秀的，这不可否认，STL的出现让C++一度走上了最辉煌的时刻，然而现在看来……我的一位恩师曾言：真正能够将STL应用得淋漓尽致的人很保守地说国内也不超过200人，或许不加入STL能够使C++向着它应当发展的方向发展的更好，而现在看来，C++也应当回首到真正属于他的那一片圣地上……

0

MPlayer 1.0rc1 released

Posted: October 24, 2006 at 9:45 am | Tags: cache, html, linux, ror, server, unix, windows

MPlayer是Linux 上的电影播放器(也能跑在许多其它Unices上,甚至非x86CPU上).他的win32版本一样强劲. 它能使用众多的本地的XAnim,RealPlayer和Win32 DLL编解码器播放大多数MPEG,VOB,AVI,OGG,VIVO,ASF/WMV,QT/MOV,FLI,RM,NuppelVideo,yuv4mpeg,FILM,RoQ文件.你还能观看VideoCD,SVCD,DVD,3ivx,RealMedia和DivX格式的电影(你根本不需要avifile库).

mplayer的另一个大的特色是广泛的输出设备支持。它可以在X11，Xv，DGA， OpenGL，SVGAlib，fbdev，AAlib，DirectFB下工作，而且你也能使用GGI和SDL(由此可以使用他们支持的各种驱动模式) 和一些低级的硬件相关的驱动模式(比如Matrox，3Dfx和Radeon，Mach64，Permedia3)！他们大多数支持软件或者硬件缩放，因此你能在全屏下观赏电影。MPlayer还支持通过硬件MPEG解码卡显示，诸如DVB 和DXR3与Hollywood+。可以使用European/ISO 8859-1,2(匈牙利语，英语，捷克语等等)，西里尔语，韩语的字体的清晰放大并且反锯齿的字幕(支持10种格式)，和on screen display(OSD)你又觉得如何？
这个播放器能够稳如泰山的播放被破坏的MPEG文件(对一些VCD有用)，而它能播放著名的windows media player 都打不开的的坏的AVI文件。甚至，没有索引部分的AVI文件可播放，你能暂时由重建他们的索引-idx选择，或者用MEncoder永久重建，使你能够在影片中搜索！如你所见，稳定和质量是最重要的事情，而且他的速度是也惊人的。

MPlayer 1.0rc1: "Codename intentionally left blank"

DOCS:

• German documentation translation finished
• Russian documentation translation synced and almost finished

Drivers:

• IVTV hardware MPEG audio/video decoder output
• ALSA audio output: AC3 passthrough now works even when the device name of the digital output port has been set by the user
• bicubic OpenGL scaling works with ATI cards
• md5sum switched to the libavutil MD5 implementation
• support for libcaca 1.0 via compatibility layer

Decoders:

• liba52 updated to 0.7.4 (slightly faster)
• SSE optimizations for mp3lib
• removed support for obsolete and non-free divx4 libraries

Demuxers:

• audio stream switching in MPEG-TS/PS, Matroska and streams supported by libavformat
• audio stream switching between streams with different codecs
• libavformat demuxer now honors -alang
• chapter seeking in Matroska files
• fixed seeking to absolute and percent position for libavformat demuxer
• NUT demuxer using libnut
• Matroska SimpleBlock support

Inputs:

• split of stream layer from libmpdemux to new stream library
• PVR input for hardware MPEG encoder based cards, such as Hauppauge WinTV PVR-150/250/350/500 AKA IVTV but also pvrusb2 and cx88 (requires Linux >= 2.6.18 kernel, featuring native V4L2 MPEG API)
• native RTSP input (handles MPEG-TS over RTP) for generic RTSP servers
• support for seeking to chapters in dvd:// and dvdnav:// streams
• radio support (radio://)

FFmpeg/libavcodec:

• VC-1/WMV3/WMV9 video decoder
• Vorbis decoding speedup, now default Vorbis decoder
• VMware Video decoder
• On2 VP50 and VP62 decoder
• lossless audio decoders: WavPack, TTA, Shorten
• CAVS decoder
• GXF muxer/demuxer
• MXF demuxer
• much improved FLAC encoder
• more H.264 decoding speed improvements, plus support for -lavdopts fast
• Theora decoder fixes
• preliminary Vorbis encoder
• MTV demuxer

GUI:

• Windows version added
• drag-and-drop ignored last file
• save and load cache setting correctly
• working audio stream selection for Ogg and Matroska files
• executable names like gmplayer_old etc. will now start GUI as well
• -gui/-nogui options
• xinerama fixes, now behaves similar to MPlayer without GUI

Filters:

• MMX-optimizations for -vf yadif
• MMX-optimizations for -vf zrmjpeg

MEncoder:

• support of x264 encoding via libavcodec
• rewrite -x264encopts option parser to use the 264 option parser; likely breaks 3rd party tools as the syntax of some options has changed
• removed support for obsolete and non-free divx4 libraries

Ports:

• partial Intel Mac support, –disable-loader –disable-mp3lib is needed
• OpenGL can now create windows > screen size under Windows
• allow filenames starting with for remote paths on Windows

Others:

• SSA/ASS subtitle renderer
• -endpos option for MPlayer
• -correct-pts option
• UTF-8 used for OSD and subtitles, some bitmap fonts will no longer work correctly and -subcp must be set for all non-UTF-8 subtitles
• more audio-truncation fixes
• libavutil mandatory for MPlayer compilation
• more intuitive -edlout behaviour
• -nortc is now default since -rtc has disadvantages with recent kernels

• Switzerland HTTP FTP
• Hungary HTTP FTP
• USA HTTP
• Serbia HTTP FTP
• Korea HTTP FTP
• Sweden HTTP FTP
• Germany FTP

• BitTorrent torrent

访问:官方网站详细更新说明
下载:MPlayer 1.0rc1 Windows GUI

0

用rsync对网站进行镜像备份

Posted: October 18, 2006 at 12:52 pm | Tags: linux, python, ror, server, unix, web, 优化, 技术, 测试, 类

对系统管理员来说，平时的工作重心应该集中在维护系统正常运转，能够正常提供服务上，这里往往牵涉到一个数据备份的问题，在我所了解

的情况中，有80%的系统管理员不是太关心自己服务器的安全性，但往往对备分镜像的技术相当感兴趣，但由于商业产品的软硬件价格都相当高

昂，因此往往会选择自由软件。这里准备介绍的rsync就是这样的软件，它可以满足绝大多数要求不是特别高的备份需求。

一、特性简介

rsync是类unix系统下的数据镜像备份工具，从软件的命名上就可以看出来了——remote sync。它的特性如下：

1、可以镜像保存整个目录树和文件系统。
2、可以很容易做到保持原来文件的权限、时间、软硬链接等等。
3、无须特殊权限即可安装。
4、优化的流程，文件传输效率高。
5、可以使用rcp、ssh等方式来传输文件，当然也可以通过直接的socket连接。
6、支持匿名传输。

二、使用方法

rsync的使用方法很简单，我就举自己使用的例子来说明吧。

1、系统环境

rsync支持大多数的类unix系统，无论是Linux、Solaris还是BSD上都经过了良好的测试。我的系统环境为：

server: FreeBSD 4.3 ip: 192.168.168.52
client: Solaris 8 ip: 192.168.168.137
rsync 版本 2.4.6(可以从http://rsync.samba.org/rsync/获得最新版本)

2、配置server端的/etc/rsyncd.conf文件

bash-2.03# cat /etc/rsyncd.conf

uid = nobody
gid = nobody
use chroot = no # 不使用chroot
max connections = 4 # 最大连接数为4
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock
log file = /var/log/rsyncd.log # 日志记录文件

[inburst] # 这里是认证的模块名，在client端需要指定
path = /home/inburst/python/ # 需要做镜像的目录
comment = BACKUP CLIENT IS SOLARIS 8 E250
ignore errors # 可以忽略一些无关的IO错误
read only = yes # 只读
list = no # 不允许列文件
auth users = inburst # 认证的用户名，如果没有这行，则表明是匿名
secrets file = /etc/inburst.pas # 认证文件名

[web]
path = /usr/local/apache/htdocs/
comment = inburst.org web server

3、在server端生成一个密码文件/etc/inburst.pas

bash-2.03# cat /etc/inburst.pas
inburst:hack

出于安全目的，文件的属性必需是只有属主可读。

4、在server端将rsync以守护进程形式启动

bash-2.03# rsync –daemon

如果要在启动时把服务起来，有几种不同的方法，比如：

a、加入inetd.conf

编辑/etc/services，加入rsync 873/tcp，指定rsync的服务端口是873
编加/etc/inetd.conf，加入rsync stream tcp nowait root /bin/rsync rsync –daemon

b、加入rc.local

在各种操作系统中，rc文件存放位置不尽相同，可以修改使系统启动时rsync –daemon加载进去。

5、从client端进行测试

下面这个命令行中-vzrtopg里的v是verbose，z是压缩，r是recursive，topg都是保持文件原有属性如属主、时间的参数。–progress是指显示

出详细的进度情况，–delete是指如果服务器端删除了这一文件，那么客户端也相应把文件删除，保持真正的一致。后面的inburst@ip中，

inburst是指定密码文件中的用户名，之后的::inburst这一inburst是模块名，也就是在/etc/rsyncd.conf中自定义的名称。最后的/tmp是备份

到本地的目录名。

在这里面，还可以用-e ssh的参数建立起加密的连接。可以用–password-file=/password/path/file来指定密码文件，这样就可以在脚本中使

用而无需交互式地输入验证密码了，这里需要注意的是这份密码文件权限属性要设得只有属主可读。

bash-2.03# rsync -vzrtopg –progress –delete inburst@192.168.168.52::inburst /tmp/
Password:
receiving file list … done
./
1
785 (100%)
1.py
4086 (100%)
2.py
10680 (100%)
a
0 (100%)
ip
3956 (100%)
./
wrote 190 bytes read 5499 bytes 758.53 bytes/sec
total size is 19507 speedup is 3.43

6、创建更新脚本

如果有比较复杂的工作，利用一些常见的脚本语言可以有帮助。比如：

bash-2.03# cat /usr/local/bin/rsync.sh

#!/bin/sh
DATE=`date +%w`

rsync -vzrtopg –progress –delete inburst@192.168.168.52::inburst /home/quack/backup/$DATE –password-file=/etc/rsync.pass >

/var/log/rsync.$DATE

7、修改/etc/crontab做好定时

比如:

bash-2.03# echo "15 4 * * 6 root rsync.sh">>/etc/crontab

三、FAQ

Q：如何通过ssh进行rsync，而且无须输入密码？
A：可以通过以下几个步骤

1. 通过ssh-keygen在server A上建立SSH keys，不要指定密码，你会在~/.ssh下看到identity和identity.pub文件
2. 在server B上的home目录建立子目录.ssh
3. 将A的identity.pub拷贝到server B上
4. 将identity.pub加到~[user b]/.ssh/authorized_keys
5. 于是server A上的A用户，可通过下面命令以用户B ssh到server B上了
e.g. ssh -l userB serverB
这样就使server A上的用户A就可以ssh以用户B的身份无需密码登陆到server B上了。

Q：如何通过在不危害安全的情况下通过防火墙使用rsync?
A：解答如下：

这通常有两种情况，一种是服务器在防火墙内，一种是服务器在防火墙外。
无论哪种情况，通常还是使用ssh，这时最好新建一个备份用户，并且配置sshd仅允许这个用户通过RSA认证方式进入。
如果服务器在防火墙内，则最好限定客户端的IP地址，拒绝其它所有连接。
如果客户机在防火墙内，则可以简单允许防火墙打开TCP端口22的ssh外发连接就ok了。

Q：我能将更改过或者删除的文件也备份上来吗？
A：当然可以：

你可以使用如：rsync -other -options -backupdir = ./backup-2000-2-13 …这样的命令来实现。
这样如果源文件:/path/to/some/file.c改变了，那么旧的文件就会被移到./backup-2000-2-13/path/to/some/file.c，这里这个目录需要自己

手工建立起来

Q：我需要在防火墙上开放哪些端口以适应rsync？
A：视情况而定

rsync可以直接通过873端口的tcp连接传文件，也可以通过22端口的ssh来进行文件传递，但你也可以通过下列命令改变它的端口：

rsync –port 8730 otherhost::
或者
rsync -e ‘ssh -p 2002′ otherhost:

Q：我如何通过rsync只复制目录结构，忽略掉文件呢？
A：rsync -av –include ‘*/’ –exclude ‘*’ source-dir dest-dir

Q：为什么我总会出现"Read-only file system"的错误呢？
A：看看是否忘了设"read only = no"了

Q：为什么我会出现’@ERROR: invalid gid’的错误呢？
A：rsync使用时默认是用uid=nobody;gid=nobody来运行的，如果你的系统不存在nobody组的话，就会出现这样的错误，可以试试gid =

nogroup或者其它

Q：绑定端口873失败是怎么回事？
A：如果你不是以root权限运行这一守护进程的话，因为1024端口以下是特权端口，会出现这样的错误。你可以用–port参数来改变。

Q：为什么我认证失败？
A：从你的命令行看来：

你用的是：
> bash$ rsync -a 144.16.251.213::test test
> Password:
> @ERROR: auth failed on module test
>
> I dont understand this. Can somebody explain as to how to acomplish this.
> All suggestions are welcome.

应该是没有以你的用户名登陆导致的问题，试试rsync -a max@144.16.251.213::test test

四、一些可借鉴的脚本

这里这些脚本都是rsync网站上的例子：

1、每隔七天将数据往中心服务器做增量备份

#!/bin/sh

# This script does personal backups to a rsync backup server. You will end up
# with a 7 day rotating incremental backup. The incrementals will go
# into subdirectories named after the day of the week, and the current
# full backup goes into a directory called "current"
# tridge@linuxcare.com

# directory to backup
BDIR=/home/$USER

# excludes file – this contains a wildcard pattern per line of files to exclude
EXCLUDES=$HOME/cron/excludes

# the name of the backup machine
BSERVER=owl

# your password on the backup server
export RSYNC_PASSWORD=XXXXXX

########################################################################

BACKUPDIR=`date +%A`
OPTS="–force –ignore-errors –delete-excluded –exclude-from=$EXCLUDES
–delete –backup –backup-dir=/$BACKUPDIR -a"

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin

# the following line clears the last weeks incremental directory
[ -d $HOME/emptydir ] || mkdir $HOME/emptydir
rsync –delete -a $HOME/emptydir/ $BSERVER:USER/$BACKUPDIR/
rmdir $HOME/emptydir

# now the actual transfer
rsync $OPTS $BDIR $BSERVER:USER/current

2、备份至一个空闲的硬盘

#!/bin/sh

export PATH=/usr/local/bin:/usr/bin:/bin

LIST="rootfs usr data data2"

for d in $LIST; do
mount /backup/$d
rsync -ax –exclude fstab –delete /$d/ /backup/$d/
umount /backup/$d
done

DAY=`date "+%A"`
rsync -a –delete /usr/local/apache /data2/backups/$DAY
rsync -a –delete /data/solid /data2/backups/$DAY

3、对vger.rutgers.edu的cvs树进行镜像

#!/bin/bash

cd /var/www/cvs/vger/
PATH=/usr/local/bin:/usr/freeware/bin:/usr/bin:/bin

RUN=`lps x | grep rsync | grep -v grep | wc -l`
if [ "$RUN" -gt 0 ]; then
echo already running
exit 1
fi

rsync -az vger.rutgers.edu::cvs/CVSROOT/ChangeLog $HOME/ChangeLog

sum1=`sum $HOME/ChangeLog`
sum2=`sum /var/www/cvs/vger/CVSROOT/ChangeLog`

if [ "$sum1" = "$sum2" ]; then
echo nothing to do
exit 0
fi

rsync -az –delete –force vger.rutgers.edu::cvs/ /var/www/cvs/vger/
exit 0

4、利用find的一种巧妙方式

rsync -avR remote:’`find /home -name "*.[ch]"`’ /tmp/

可以用这种方法列出需要备份的文件列表——这种方法似乎比较少人用到。

五、参考资料：

1、http://rsync.samba.org/
2、rsync examples
3、rsync FAQ

文章来源：http://xfocus.org/

0

shell使用指南

Posted: October 17, 2006 at 7:41 pm | Tags: crontab, dreamhost, linux, shell, tar, unix, web, wget, 指令, 类

本文中所用的shell指令及操作均基于Linux ord 2.4.29，即DreamHost现在采用的系统。本人不是计算机专业出身，本指南因此会比较死板，只针对想要使用shell又苦于不知如何下手的新手，如果你也是DreamHost的用户，那本文或许对你有所帮助。

目录：
1. Basic Instructions /基本指令
2. wget /下载工具
3. Crontab /定时任务
4. tar/tar.gz /压缩文件
5. vi /编辑器

[最后更新: 2006-03-11]

1. Basic Instructions基本操作命令
通常来说，使用”$[Instructions] –help”可以获得以下各个命令[instructions]的帮助，包含其参数列表的定义。

-ls 列出当前文件夹下所有内容
$ls -o 列出当前文件夹中所有内容，含详细信息，但不列出group
$ls -l 同上，含group信息
$ls -a 列出当前文件夹中所有内容，包含以”.”开头的文件
$ls -t 按更改时间排序
$ls -v 按版本先后排序

-cd [dir] 进入文件夹

-pwd 显示当前路径

-mkdir [dir] 新建文件夹

-chmod 更改文件/文件夹权限
$chmod [Mode] [dir]，其中Mode形如”755″或”777″等。
$chmod [Mode] [file]
$chmod -R [Mode] [dir]，递归形式，即将目标文件夹内所有文件均改变权限
Mode还有另一种表达方式，”755″即为”-rwxr-xr-x”，不列举了。

-rm [file] 删除文件/文件夹
$rm -f [file] 强行删除，忽略不存在的文件，无提示
$rm -r [file] 递归删除所有内容

-cp 拷贝
$cp [options] [source] [destination]
其中[options]可以为-f（强行拷贝）或-r（递归拷贝）

-mv 重命名或移动
$mv [options] [source] [destination]
[options]常用：-f(强行移动/重命名), -i(移动/重命名前尝试), -u(更新)
例如
$mv wwwroot/cgi-bin . 将/cgi-bin目录移动到当前目录下
$mv cronfile.txt myfile.txt 将cronfile.txt重命名为myfile.txt

2. wget下载工具
wget是一种非交互式的网络文件下载工具，在linux下可以使用该工具快速地从网络上下载所需要的文件而不需要经由本地硬盘中转，而且速度极快。以下是一些使用方法：

wget [参数列表] URL

最简单的用法:
$wget http://targetdomain.com/file.tar

wget的常用参数：
· -t [nuber of times]：尝试次数，当wget无法与服务器建立连接时，尝试连接多少次。比如”-t120″表示尝试120次。当这一项为”0″的时候，指定尝试无穷多次直到连接成功为止，这个设置非常有用，当对方服务器突然关机或者网络突然中断的时候，可以在恢复正常后继续下载没有传完的文件；

· -c：断点续传，这也是个非常有用的设置，特别当下载比较大的文件的时候，如果中途意外中断，那么连接恢复的时候会从上次没传完的地方接着传，而不是又从头开始，使用这一项需要远程服务器也支持断点续传，一般来讲，基于UNIX/linux的Web/FTP服务器都支持断点续传；

· -T [number of seconds]：超时时间，指定多长时间远程服务器没有响应就中断连接，开始下一次尝试。比如”-T120″表示如果120秒以后远程服务器没有发过来数据，就重新尝试连接。如果网络速度比较快，这个时间可以设置的短些，相反，可以设置的长一些，一般最多不超过900，通常也不少于60，一般设置在120左右比较合适；

· -w [number of seconds]：在两次尝试之间等待多少秒，比如”-w 100″表示两次尝试之间等待100秒；

· -nd：不下载目录结构，把从服务器所有指定目录下载的文件都堆到当前目录里；

· -x：与”-nd”设置刚好相反，创建完整的目录结构，例如”wget -nd http://www.gnu.org/ “，实际的目录结构一级一级建下去，直到所有的文件都传完为止；

· -nH：不创建以目标主机域名为目录名的目录，将目标主机的目录结构直接下到当前目录下；

· -r：递归下载，在本机建立服务器端目录结构；

· -l [depth]：下载远程服务器目录结构的深度，例如”-l 5″下载目录深度小于或者等于5以内的目录结构或者文件；

· -m：做站点镜像时的选项，如果你想做一个站点的镜像，使用这个选项，它将自动设定其他合适的选项以便于站点镜像；

· -np：只下载目标站点指定目录及其子目录的内容。这也是一个非常有用的选项，我们假设某个人的个人主页里面有一个指向这个站点其他人个人主页的连接，而我们只想下载这个人的个人主页，如果不设置这个选项，甚至–有可能把整个站点给抓下来，这显然是我们通常不希望的；

· –http-user=username
· –http-passwd=password：如果Web服务器需要指定用户名和口令，用这两项来设定；

· -O 将数据写入文件中。

3. Crontab 定时执行任务

在DreamHost系统下, 通过Shell可以建立自己的crontab. 具体使用如下:
使用支持shell登录的终端(如fterm或putty), 地址栏输入username@qiran.org:22即可以SSH方式登录至服务器.

常用的crontab命令:
crontab -l 显示所有现存cron job.

crontab -r 删除当前cron jobs.

crontab -e 编辑当前 “crontab file”. DH推荐使用nano

注意你的crontab包含所有的cron jobs, 每个cron一行, 断行结尾. 一个正常的cron如下所示:
45 2 * * * /home/user/script.pl

第一个数字是每小时的第几分钟,
第二个数字是每天的第几小时,
第三个数字是每月的第几天,
第四个数字是每年的第几月,
第五个数字是每周的第几天.

使用方式例如:
32 * * * * : 表示每小时的第32分钟.
12,42 * * * * : 表示每小时的第12及第42分钟两次
*/15 */2 * * *: 表示0:00, 0:15, 0:30, 0:45, 2:00, 2:15, 2:30, …
43 18 * * 7: 表示每个周日的6:43pm运行命令行.

在DreamHost下使用nano编辑完文件后，使用ctrl+o保存，ctrl+x退出编辑。

4. tar命令
tar命令的使用方法如下：

tar [参数列表] [文件名]

参数列表：
-c 生成新的备份，并同时覆盖旧的备份文件
-x 从备份文件中解压缩
-t 列出备份文件内的文件目录
-v 显示所有被操作文件列表
-f 在指定位置生成备份
-u 将不存在于备份中的文件，或将已经被更改的文件加入该备份中。

举例说明：
tar cvf filename.tar /*制作备份*/
tar cvf tarfile.tar ./filename /*将filename的文件备份到tarfile.tar里面*/
tar tvf filename.tar /*列出tar文档的内容*/
tar xvf filename.tar /*从tar文档中导出文件*/
tar zxpvf filename.tar.gz /*从tar.gz文档中导出文件*/
tar zxvf filename.tar.gz /*同上*/
tar xvf tarfile.tar ./filename /*导出tar文件中的单个文件*/

5. vi编辑器
Linux下很易用的一种编辑器，只需要稍微知道几个指令即可应用。

打开vi：
$vi [filename]：打开或新建文件，并将光标置于第一行首
$vi +n [filename] ：打开文件，并将光标置于第n行首
$vi + [filename] ：打开文件，并将光标置于最后一行首
$vi +/pattern [filename]：打开文件，并将光标置于第一个与pattern匹配的串处
$vi -r [filename] ：在上次正用vi编辑时发生系统崩溃，恢复filename
$vi [filename]….[filename] ：打开多个文件，依次编辑

如果filename不存在，则自动生成一个名字filename的新文件。

vi共有两种状态：命令状态/编辑状态

编辑状态下：
第一次按下insert键为”insert”模式，再按一下为”replace”模式，使用ESC返回命令状态；
在此状态下键盘的PgUp/PgDn/Insert/Delete/Home/End/方向键，均处于正常功能状态。

命令状态下：
输入的字符串作为命令处理，使用”insert”键切换到编辑状态；
以下是命令状态下的命令清单：

移动光标类命令
h ：光标左移一个字符
l ：光标右移一个字符
space：光标右移一个字符
Backspace：光标左移一个字符
k或Ctrl+p：光标上移一行
j或Ctrl+n ：光标下移一行
Enter ：光标下移一行
w或W ：光标右移一个字至字首
b或B ：光标左移一个字至字首
e或E ：光标右移一个字j至字尾
) ：光标移至句尾
( ：光标移至句首
}：光标移至段落开头
{：光标移至段落结尾
nG：光标移至第n行首
n+：光标下移n行
n-：光标上移n行
n$：光标移至第n行尾
H ：光标移至屏幕顶行
M ：光标移至屏幕中间行
L ：光标移至屏幕最后行
0：（注意是数字零）光标移至当前行首
$：光标移至当前行尾

屏幕翻滚类命令
Ctrl+u：向文件首翻半屏
Ctrl+d：向文件尾翻半屏
Ctrl+f：向文件尾翻一屏
Ctrl＋b；向文件首翻一屏
nz：将第n行滚至屏幕顶部，不指定n时将当前行滚至屏幕顶部。

插入文本类命令
i ：在光标前
I ：在当前行首
a：光标后
A：在当前行尾
o：在当前行之下新开一行
O：在当前行之上新开一行
r：替换当前字符
R：替换当前字符及其后的字符，直至按ESC键
s：从当前光标位置处开始，以输入的文本替代指定数目的字符
S：删除指定数目的行，并以所输入文本代替之
ncw或nCW：修改指定数目的字
nCC：修改指定数目的行

删除命令
ndw或ndW：删除光标处开始及其后的n-1个字
do：删至行首
d$：删至行尾
ndd：删除当前行及其后n-1行
x或X：删除一个字符，x删除光标后的，而X删除光标前的
Ctrl+u：删除输入方式下所输入的文本

搜索及替换命令 :
/pattern：从光标开始处向文件尾搜索pattern
?pattern：从光标开始处向文件首搜索pattern
n：在同一方向重复上一次搜索命令
N：在反方向上重复上一次搜索命令
：s/p1/p2/g：将当前行中所有p1均用p2替代
：n1,n2s/p1/p2/g：将第n1至n2行中所有p1均用p2替代
：g/p1/s//p2/g：将文件中所有p1均用p2替换

选项设置
all：列出所有选项设置情况
term：设置终端类型
ignorance：在搜索中忽略大小写
list：显示制表位(Ctrl+I)和行尾标志（$)
number：显示行号
report：显示由面向行的命令修改过的数目
terse：显示简短的警告信息
warn：在转到别的文件时若没保存当前文件则显示NO write信息
nomagic：允许在搜索模式中，使用前面不带“\”的特殊字符
nowrapscan：禁止vi在搜索到达文件两端时，又从另一端开始
mesg：允许vi显示其他用户用write写到自己终端上的信息

最后行方式命令
：n1,n2 co n3：将n1行到n2行之间的内容拷贝到第n3行下
：n1,n2 m n3：将n1行到n2行之间的内容移至到第n3行下
：n1,n2 d ：将n1行到n2行之间的内容删除
：w ：保存当前文件
：e filename：打开文件filename进行编辑
：x：保存当前文件并退出
：q：退出vi
：q!：不保存文件并退出vi
：!command：执行shell命令command
：n1,n2 w!command：将文件中n1行至n2行的内容作为command的输入并执行之，若不指
定n1，n2，则表示将整个文件内容作为command的输入
：r!command：将命令command的输出结果放到当前行 。

0

[转]C/C++/Perl/汇编/Java效率比较

Posted: October 11, 2006 at 11:04 am | Tags: cache, class, html, java, linux, python, ror, server, unix, web, windows, 优化, 平台, 开发, 技术, 测试, 类

本文适合初学编程的程序员阅读，它对比了几种编程语言在解决同一问题的时候的运效率。并通过具体的例子进行了量化分析。主要目的是帮助初学者认识各种编程语言的特质，并且能够理性的选择适合的编程语言来进行工作。

事发

我无聊的翻着散落案头的书籍，这些都是五花八门的关于编程和系统管理的著作。干了这么多年程序员，大大小小的软件和项目也做了无数。每每有新入行的朋友问我这个所谓的"老前辈"：哪种语言最好之类的问题，我总会作出一副知识渊博的样子，复述着从更老的老前辈那里听来的或者某些名著上看来的"知识"。就好比我们从学习编程的第一天起，就被计算机老师告知，COBOL语言是擅长处理商务事务、FOTRAN语言是用于科学计算一样。类似的知识还有"汇编语言比C语言快得多"以及"JAVA是一种效率很低的语言环境"在一代又一代的程序员中口耳相传，几乎成为了毋庸置疑的真理。

我产生了一个想法，能不能对于同一个应用用几种编程语言分别实现，来比较一下看看到底哪种语言效率最高？

老实说我自己都觉得这个想法很无聊，想想谁会反复用不同的语言写同一个程序呢？下雨天打孩子，闲着也是闲着。再说，对于某种语言的弱点和优势有一个量化的分析，对于我们今后在做项目的时候面临工具选择也少许有一点指导意义。另外，觉得好玩才是我做这件事情的真正原因。

选题

选择一个什么样的程序问题进行这样的测试呢？这是一个很关键的问题，也最容易影响测试的公平性。另外的，对于每种语言，各自的优势都是不同的。程序员的偏爱也是各不相同的。在网上和现实中，对于什么语言更好一些的争论从来就没有停止过。甚至的，各门各派的程序员所构成的各种阵营，把某种语言奉若神明的也不在少数。不信，你在CSDN的JAVA论坛说一句"JAVA执行效率太低了云云"试试？立刻会被铺天盖地的板砖掀翻在地。类似的，还有管理员对于操作系统的偏好和争论：在Linux论坛你要是表扬Windows，其惨烈程度简直是难以言状。因此，从这个意义上来说，程序员们对于编程语言的偏好，类似于战士之喜爱枪械，赛手之喜爱赛车，已经上升为一种精神层面的东西了。蔡学镛先生说得好：有人逢微软必反，有人逢微软必捧。这是一种纯粹的精神上的爱，但它可能会影响正常的、科学的思考。

可以预料的，我这篇文章一定会遭到各路豪杰的迎头痛击。

好了，让我们言归正转吧。首先的，我们的选题中要使用的各种程序语言的最常用的要素。什么是最常用的要素呢？当然了，大家都有的就是赋值、数组操作、循环、判断等。另外，对IO的操作也是编程语言重要的内容。其次的，操作时间一定要长，否则，对于解释性的语言来说是极不公平的：解释器还没调入内存呢，人家编译派的已经运行完了。最后，就是程序不能太复杂。除了我没有那么大的毅力用各种语言完成一个复杂算法的决心外，程序过于复杂，算法在测试中起的作用就越来越大，影响运行效率的原因也就增加了。算法过于复杂，开发工具的扩展部分用得也就越多。于是就成了语言附加库之间的竞赛了，这是我不愿意看到的。

考虑上述因素，我设计了一个简单的选题：从指定文本文件中搜索指定字符串，计算个数。并且打印出搜索到的个数作为结果输出。作为程序员的你粗粗过一下脑子，马上会想到这个算法里面包含了条件判断、循环、数组操作等基本的程序语言因素。这满足了上面第一个条件。另外的，为了满足第二个条件，我准备了一个多达2G的文本文件，总共有文本1500万行多。这保怔了足够的运行时间（但应该不会太长），而决不会一眨眼就执行完了。最后的，我们都知道，在文本串里面搜索子串的算法是数据结构课本中的一个典型的例子（考试也经常被考到的），也满足算法简单的要求。同时，为了让每个程序的环境都一样，我得每测试一次就重新启动一次机器，避免CACHE的影响。

准备

比赛嘛，就需要公平。首先的，硬件平台要统一。我找了一台看起来还不错的机器(服务器)：两颗PIII800，1G内存。操作系统嘛，原来的机器上有新装的Windows2000Server版本。几乎没装什么别的应用。我偷懒了一下，没有重新安装OS，就这样用吧。

第一个选手：PERL

如果别人交给我这个题目，我会马上决定用PERL语言来做这件事。这个题目是完全的文本处理问题，还有比用PERL来做更合适的吗？因为PERL是专门为了文本处理而编制的语言。事实上也是这样，我用了2分钟，写了几行代码，就轻松实现了这个问题。这也说明了，选择适用的编程语言工具，比选择喜爱的工具更重要。

#!/usr/bin/perl
$filename="d:\access.log_";
$count = 0;
open(FILE , "<$filename");
while(<FILE>)
{
@match_list = ($_ =~ /HIT/g);
$count=$count+@match_list;
}
close(FILE);
print "Count = $count ";
exit

PERL是一位语言学家Larry Wall发明的，事实上，早期这种语言是专门用于在UNIX平台处理文字文件的(Perl=Practical Extraction Report Language:实用报表析取语言)。后来人们发现有大量文本构成的HTML页面用PERL来做CGI程序生成动态页面再合适不过了。因为互联网的兴起，PERL跟着发大了起来。这种语言的语法和C语言基本类似，因此比较好掌握，并且的，其关于"正则表达式"处理的强大功能目前基本上无人能够望其项背。事实上，类似于"过滤出含有TOM或者ABC的、并且后者的第一个和第三个字母大写，前者最少出现2次，后者出现5次、而且中间间隔8个或4个字母或空格的文本行"。我猜你正在反复的揣摩这句话，事实上，这就是所谓正则表达式，这样的问题，在PERL只需要一行语句就可以完成。在C语言中需要多少语句才能实现呢。

我略略解释一下上面的程序，让没有用过PERL语言的程序员也有个感性认识。

第一行是在UNIX中才用得到，因为PERL是一种基于解释的脚本语言。

第四行是打开文件

下面的循环是一行一行的读文件的内容。循环中间的第一句话是把凡是文本行中含有的HIT全部放到一个数组中；循环中中的第二句话是统计一下刚才的数组中有几个HIT，然后累加起来。循环完成了，我们的任务也就完成了。怎么样，很简单吧？"/HIT/g"就是最简单的正则表达式。

现在的PERL语言早已经不是原来的脚本语言形象了，现代PERL几乎具备了其特语言的所有特性，并且的在模块的功能帮助下，可以实现很大的应用。而且还增加了一些面向对象的特点。尽管大多数人仍然在用它处理大量的文本，但也有使用PERL完成大型应用的，尤其是在WEB方面。值得一提的是PERL也是一个跨平台语言。

我的这个程序在测试平台上，使用PERL5.8解释器，用了8分18秒08完成了1500万行文本的扫描，并得出了正确的结果。

第二个选手：纯C

也许年龄大了，但是我真的很喜欢C语言。而且我最喜欢的就是使用指针和强制类型转换来任意操作数据。我甚至会在程序里通过指针手工拼凑一个长整性的数据。说句可能引起争议的话，我觉得JAVA语言抛弃可爱的指针的做法基本上就是逃避。因为掌握不好就不用，到头来就是牺牲了效率。

本文这个题目，用C语言来实现应该还是比较不错的选择。下面的代码就是在VC下面实现的纯C代码的字符串搜索程序（为了避免图形界面的干扰，一律做成控制台程序）。编译的时候使用速度优先编译选项。

#include <stdio.h>
#include <string.h>

void main()
{
int len=2048;
char filename[20];//文件名
char buff[10000];//文件缓冲区
char hit[5];
FILE *fd;
int i,j,flag=0,over=0;
int max,readed;
int count=0;//最后的结果
strcpy(&filename[0] , "d:\access.log_");
strcpy(&hit[0] , "HIT");
buff[0]=0×0;
buff[1]=0×0;
//打开文件：
if((fd = fopen(&filename[0] , "rb"))==NULL)
{
printf("Error : Can not open file %s ",&filename[0]);
}
//读取文件内容
while(over != 1)
{
readed = fread(&buff[2] , 1 , len , fd);
if(readed < len)
{
over=1;
max=readed;
}
else
{
max=len;
}
for(i=0;i<max;i++)
{
for(j=0;j<3;j++)
{
if(hit[j] != buff[i+j])
{
flag=0;//一旦有一个不相同就退出并且标志为0
break;
}
else
{
flag=1;//一个相同为1，如果连续都相同最后结果定是1
}
}
if(flag==1)
{
count++;
i+=j-1;
}
else
{
if(j==0)
{
i+=(j);
}
else
{
i+=(j-1);
}
}
}
//把最后两个字符转移到前面两个字节以防止切断搜索串.
buff[0]=buff[max];
buff[1]=buff[max+1];
}
fclose(fd);
printf("count:%d ",count);
}

程序很好懂，用的也是教科书上面的标准字符串搜索算法，但是比前面的PERL程序长多了吧？那是因为人家PERL已经帮你完成了大部分工作。但是看到上面这段程序的运行结果你可能会高兴起来，它最快一次只用了2分10秒52，最慢也只用了2分20秒59就完成了1500万行文本的搜索任务。平均2分15秒多。为什么每次时间不一样呢？我不清楚具体原因，但学过操作系统的朋友会明白，只有在单道单任务的系统中，代码才能有执行上的可再现性。

有经验的朋友可能会说，你的缓冲区只用了2048字节，加大它速度还会增加呢。是的，而且我相信还有高手能作出更快的程序来，但这不重要，重要的是我们要考察的是不同语言完成同一件工作的效率。而且你能够明白，在程序中，改进什么能够提高效率，这就足够了。因为C语言程序中，这些都是自由可控的。

第三个选手：C++

C++和前面的C是亲戚。我简单的把前面的C代码移植过来，然后把文件输入部分改成了流类对象。至于算法部分嘛。跟前面的C是一模一样的。最后在编译的时候，除了使用速度最佳编译选项外，当然还用了C++的编译参数，因此执行文件的长度比前面的C要长一些，这说明我加的流类代码比标准C库要复杂。是的，C++应该说是目前流行的计算机编程语言中复杂度排名靠前的。其复杂的类和继承关系，以及各种初始化的次序和构造函数执行顺序等都需要考虑。还有多态以及动态联编技术等。C++也是我非常喜欢的语言，提供了面向对象的代码重用特性和足够的安全型，但是在效率上的确比纯C略逊一筹。你知道吗，大部分的操作系统核心几乎都是用纯C写成的，尽管很复杂，但很少有使用面向对象技术的。为什么，不是面向对象技术不好，也不是操作系统核心不够复杂（那什么复杂？），主要的考虑就是效率问题。

#include <stdio.h>
#include <string.h>
#include <fstream.h>

void main()
{
int len=2048;
char filename[20];//文件名
char buff[10000];//文件缓冲区
char hit[5];
int i,j,flag=0;
int max;
int count=0;//最后的结果
strcpy(&filename[0] , "d:\access.log_");
strcpy(&hit[0] , "HIT");
buff[0]=0×0;
buff[1]=0×0;
//用输入流打开文件：
ifstream input(&filename[0]);
//读取文件内容
while(input)
{
input.getline(&buff[2] , len);
max = strlen(&buff[2]);
for(i=0;i<max;i++)
{
for(j=0;j<3;j++)
{
if(hit[j] != buff[i+j])
{
flag=0;//一旦有一个不相同就退出并且标志为0
break;
}
else
{
flag=1;//一个相同为1，如果连续都相同最后结果定是1
}
}
if(flag==1)
{
count++;
i+=j-1;
}
else
{
if(j==0)
{
i+=(j);
}
else
{
i+=(j-1);
}
}
}

}
printf("count:%d ",count);
}

这段C++程序在测试平台上用了最快4分25秒95 到最慢5分40秒68的时间完成1500万行的文本检索，并在2G的文件中检索出10951968个"HIT"字符串。这结果是正确的。

第四个选手：汇编

本以为汇编程序能够达到前所未有的高速，把前面的选手远远抛在身后而笑傲江湖。这一想法支撑我完成了艰涩的代码。可事实上测试的结果缺让我大失所望，完全用机器指令书写的程序，去掉缓冲区才几百字节，算法和前面的C程序一模一样，扫描1500万行文本竟然最快也要2分14秒56！这甚至还比不过C语言的最快纪录。而平均下来，汇编程序的速度竟然和前面的C程序在伯仲之间。恐怕这样的结果也出乎大部分人的意外。因为我们从入行的那一天起，就被告知汇编是你所能够掌握的最快的语言！尽管代码坚涩难懂，但性能的代价是值得的。而从这里的测试看，你觉得向下面这样的代码，实现和C语言一样的速度和功能值得吗？

;堆栈段
STSG SEGMENT STACK ‘S’
DW 64 DUP(?)
STSG ENDS

;数据段
DATA SEGMENT
rlength EQU 2048
fname DB ‘access.log_’,0
hit DB ‘HIT$’
fd DW ? ;文件句柄
resault DB ‘count : $’ ;结果提示
count DD 0 ;存放结果
disflag DB 0 ;显示标志
buff DB 5000 dup(0) ;缓冲区
DATA ENDS

;代码段
CODE SEGMENT
MAIN PROC FAR
ASSUME CS:CODE,DS:DATA,SS:STSG,ES:NOTHING
MOV AX,DATA
MOV DS,AX
;我的代码开始:
mov ah,3dh ;打开文件
lea dx,fname
mov al,00h ;文件打开方式
int 21h ;开始操作
;这里就不作错误处理了，偷懒喽！
;CF＝0表示正确，CF=1表示错误，AX是文件句柄或者是错误代码
mov fd,ax ;保存文件句柄

READ: mov ah,3fh ;读文件
mov bx,fd ;文件句柄
mov cx,rlength ;要读length字节

lea dx,buff ;给出读缓冲区指针
add dx,2 ;缓冲区指针向后错两个（目的是解决边界问题：有一个HIT正好横跨rlength界限）
int 21h ;开始读
;AX里面是实际读出的字节数
;读完了以后，扫描缓冲区
push ax ;保存AX字节数
cmp ax,0
jz ALLEND ;文件读完了就退出

sub dx,2 ;指针向前错2个，
mov si,dx
add dx,2 ;把指针回到原来的位置
add dx,ax ;计算结尾
LOD3: cmp si,dx ;到头了就重新读一次文件
jz OVR
lods buff
lea bx,HIT
cmp al,[bx]
jnz LOD3 ;读第一个字节不相等就重新读一个

cmp si,dx
jz OVR
lods buff
cmp al,[bx+1]
jnz LOD3 ;如果第一个字节相等，就读第2个字节，不行等就从第一个字节再重比较。

cmp si,dx ;如果第二个字节也相等的话，就比较第三个字节。
jz OVR
lods buff
cmp al,[bx+2]
jnz LOD3 ;第三个字节不相等再从头开始
;有一个HIT匹配
push bx
lea bx,count
add WORD ptr [bx],1 ;计数器增加一个
adc WORD ptr [bx+2],0 ;进位
pop bx
jmp LOD3

OVR: mov ah,[si-1]
mov BYTE ptr buff+1 , ah
mov ah,[si-2]
mov BYTE ptr buff , ah

pop ax ;恢复这次总共读出的字节数
cmp ax,rlength ;看看是不是最后一次（剩余的零头）
jz READ
;如果是最后一次读文件，

ALLEND: mov ah,3eh ;关闭文件
mov bx,fd ;文件句柄
int 21h ;关闭文件

mov ah,9 ;显示结果字符串
lea dx,resault
int 21h

;转换2进制结果到10进制ACSII形式
mov bx, WORD ptr count
call TERN

mov ax,4c00h ;返回DOS
int 21h
;结束代码,最大的数字已经排到了最前面
MAIN ENDP

TERN PROC ;这个子程序是转换并显示2进制数字的
mov cx,10000
call DEC_DIV
mov cx,1000
call DEC_DIV
mov cx,100
call DEC_DIV
mov cx,10
call DEC_DIV
mov cx,1
call DEC_DIV
ret
TERN ENDP
DEC_DIV PROC
mov ax,bx
mov dx,0
div cx
mov bx,dx
mov dl,al
add dl,30H
mov ah,disflag ;read flag
cmp ah,0
jnz DISP ;已经显示过有效数字了
cmp dl,30H
jz NODISP
mov disflag,1 ;作用是第一个有效数字出现前不显示0
DISP: mov ah,2
int 21H
NODISP: ret
DEC_DIV ENDP
CODE ENDS
END MAIN

上面这段代码我猜你也懒得仔细阅读。其实他不能"显示结果"。因为最后这段负责把最终结果转换成可显示ASCII码的程序实际上只能转换二进制十六位的数据，而最终的结果高达1000万挂零，显示会出错。由于这最终结果的显示已经和程序的运行没有大关系了，因此，我也就懒得去写一个32位的ASCII转换程序了。就这样吧。

第五个选手：JAVA

JAVA是一个不能不参加比赛的选手。有如此多的人热爱他，他们中的一半人是因为JAVA的面向对象特性以及良好的跨平台特性。而另一半人纯粹就是因为JAVA不姓"微（软）"，这就是意识形态在程序员头脑中对某种语言的注释。单纯从语言元素上来说，我还是比较喜欢JAVA的。因为他的语法干净、简洁。环境也好。虽然用虚拟机系统（JVM）的做法来实现跨平台特性并非什么了不得的创意（像不像30年前的BASIC解释器？别跟我说什么中间代码？几乎所有的解释器都是把语言因素翻译成中间代码的，JVM不过是分成2步来实现罢了，但从运行机制上应该是差不多的。），但JVM仍然将JAVA的跨平台特性做到了前所未有的地步。而且JVM是一个很干净的系统，让人用起来赏心悦目。说到这里我忍不住想提一下J2EE企业应用框架了。不知道有多少人能够看懂SUN出的J2EE的"理论著作"？满纸充斥着各种生造的概念，洋溢着溢美之词。JAVA的企业应用框架实在是比较复杂的东西，虽然赶不上后来的.NET框架，但足以让大多数初学者望而却步。一句话，东西太多了。事实上JAVA的企业级应用并没有想象的成功，iPlanet就随着电子商务概念的全面垮台而渐渐淡出。现在换了个名叫“SUNONE”――SUN公司员工原话。

我们回到JAVA的语言元素上来说，实际上JAVA可以被理解为被纯化的C++。JAVA去除了C++为了兼容C而增加的一些"非面向对象特质"，用其他的一些变通办法实现C++直接实现的功能，比如：多继承。在实现机制上，JAVA的程序会先编译成.CLASS文件，然后这种跨平台的中间代码就可以"一次编译，到处运行"了。当然必须运行在有JVM虚拟机的环境中，连图形什么的都可以照搬。换句话说，你用JAVA程序在PC屏幕上画一个圆，在JAVA－PDA上它还是圆的。

我在本次测试中，写了下面的代码，用JAVA做了同样的测试，测试中实际上用到了：JAVA的文件流类，运行了循环、条件判断、数组操作等基本的语言因素。环境是J2SE1.3.1-06。JAVA程序做1500万行的文本扫描用了8分21秒18。应该说是几种语言中最慢的，基本上和纯解释的PERL是在同一水准。J2EE的JVM环境还是经过优化的所谓HOTSPOT。

import java.io.*;
public class langtest
{
public static void main(String[] args)
{
String filename = "d:\access.log_";
try
{
count(filename);
}
catch (IOException e)
{
System.err.println(e.getMessage());
};
}

public static void count(String filename) throws IOException
{
long count=0;
long len;
String strline = "";
char hit[] = {‘H’,'I’,'T’};//要搜索的字符串
char buff[] = new char[2100];

Reader in = new FileReader(filename);//用FileReader类构造产生一个Reader类对象
LineNumberReader line = null;//生成一个空指针
try
{
line = new LineNumberReader(in);//建立LineNumberReader类对象
while((strline = line.readLine()) != null)
{
//到这里已经读出一行了，用下面的代码分析这行有几个HIT
int i=0,j=0,max=0,flag=0;
buff = strline.toCharArray();//转换成字符数组
max = strline.length();

for(i=0;i<max;i++)
{
for(j=0;j<3;j++)
{
if(hit[j] != buff[i+j])
{
flag=0;//一旦有一个不相同就退出并且标志为0
break;
}
else
{
flag=1;//一个相同为1，如果连续都相同最后结果定是1
}
}
if(flag==1)
{
count++;
i+=j-1;
}
else

{
if(j==0)
{
i+=(j);
}
else
{
i+=(j-1);
}
}
}
}
System.out.println("Count : "+count);
}
catch (IOException e)
{
System.err.println(e.getMessage());
}
finally
{
try
{
if(in != null) in.close();
}
catch (IOException e)
{
}
}
}
}

候捷先生翻译的宏篇巨著《JAVA编程思想》一书中第67页说到："使用最原始的JAVA解释器，JAVA大概比C慢上20到50倍"之说法我在阅读的时候就心存疑虑，心想要是这样，JAVA完全没有存或与世间的必要了。在亲自动手试验过后，我觉得说JAVA在J2EE环境下，比C慢上2－3倍还是比较可靠的说法的。况且，目前越来越多的硬件JVM的诞生，也给JAVA越来越多的机会。不过我担心的正是这点，JVM的多厂家多样化很可能会造成某些兼容性方面的问题。例如我见过一篇文章就是讨论某种JAVA程序在IBM－JVM可用而在SUN－JVM上不可用之事例。但愿的，JAVA能健康成长。

总结

事实上，本文有两个基本的意义传递给初做程序员的读者：

一、 抛开你的意识形态好恶，选择最合适的编程语言来完成你的工作。每种流行的语言都有自己存在的意义。

二、 在编程中，有想法就自己做一做，你会得出自己的结论。

至此，你应该明白，前面的所有测试结果其实并不重要，重要的是你了解了这些语言的特质，也许在今后的编程生涯中会因此增加一点点"经验"呢。

后记

本来笔者还打算继续测试一下另外的一种颇为流行的解释语言Python和新贵C＃以及在Linux平台完成这些测试，但终究还是被懒惰瓦解了斗志。好在的，Python和Perl比较相似，而C#和JAVA有异曲同工之妙。也可以略略做一点参考。

事实上，本文测试中有一个大大的不公平之处，相信仔细的读者已经发现了：其中C和ASM都是使用缓冲区直读的办法，不管三七二十一就进行判断（最后用指针检查缓冲区边界）。而C++等其他的语言虽然用了非常方便的流按行读出，但是多做了很多事情：每一个字符都要判断其是不是回车换行符，而按行读近来，每次缓冲的也要少很多。因此其他几种语言就大大的吃亏了。不过这并不影响结论性的东西，因为测试本身就说明越方便就效率越低。事情总是要有人做，不是吗？

0

ACE自适配通信环境

Posted: August 23, 2006 at 1:43 pm | Tags: class, html, java, linux, unix, web, 优化, 平台, 开发, 技术, 测试, 类, 缓存

0

ACE 简介

Posted: August 23, 2006 at 1:42 pm | Tags: class, java, linux, unix, web, 优化, 平台, 开发, 技术, 测试, 类

ADAPTIVE Communication Environment (ACE) 是一种免费开放原代码的面向对象框架结构，该结构实现了许多并行通信软件的核心设计模式. ACE提供丰富的C++ wrapper facades, 以及可跨平台执行通信软件的基本任务的框架对象。ACE提供的基本任务包括事件分离与事件淼姆址? 信号量处理,服务初始化 , 进程间通信, 共享内存管理, 消息路由, 分布式服务的动态配置, 并发执行与同步。

ADAPTIVE Communication Environment (ACE) 是一种免费开放原代码的面向对象框架结构，该结构实现了许多并行通信软件的核心设计模式. ACE提供丰富的C++ wrapper facades, 以及可跨平台执行通信软件的基本任务的框架对象。ACE提供的基本任务包括事件分离与事件处理的分发, 信号量处理,服务初始化 , 进程间通信, 共享内存管理, 消息路由, 分布式服务的动态配置, 并发执行与同步。
　　ACE 的使用对象是面向开发高性能与实时通信服务应用的开发人员。它可以简化实现进程见通信，event demultiplexing , 直接动态链接explicit dynamic linking,以及并发处理功能的面向对象网络应用与服务的开发过程。 同时, ACE 通过在运行过程中动态将服务连接到应用中并在一个或多个进程或线程中执行这些服务这种方式实现了系统的自动配置与重新配置。
　　ACE 仍在不断的发展，它的应用前景非常光明。ACE的商业用途的支持由 Riverace 公司使用公开原代码方式进行. 同时，许多ACE 开发小组的成员正在进行 ACE ORB (TAO)的开发工作。

1. 使用ACE的优点

　　使用ACE的主要优点包括:
　　高可移植性 – ACE部件使书写某一操作系统的并行网络应用和快速移植到许多其他操作系统平台变的非常容易。而且，因为ACE 是开发原代码、免费的软件，你不需担心在特定的操作系统或编译配置时被卡住。　
　　增强的软件质量 – ACE部件是使用许多可增强通信软件关键的质量特性（如灵活性、可扩展性、可重用性与模块化等）的重要设计模式来设计的。
　　高效率与可预见性predictability – ACE通过小心的设计来支持对于不同应用质量的服务（application quality of service，QoS）的需求,包括对于延迟敏感的应用使用较少的延迟，要求较强通信带宽的应用提供高性能的服务，以及对实时性应用的可预见性等服务。
　　可容易的整合为高级的中间件 — ACE 在TAO提供了可重用的部件与模式。而TAO是一个为高性能与实时系统应用优化过的，通过开放原代码实现了CORBA兼容标准。这样, ACE与TAO被设计用来协同工作来实现复杂的中间件解决方案。

2. ACE的结构与功能

　　下图说明了ACE关键的部件以及他们之间的层次关系。

　　
　　　　　　　　　　　　　　　　　　　　　　　　图表 1
　　图中的结构与层次关系在下面描述。

3. ACE接口层（ACE Adapter Layer）

　　该层在C编写的本地操作系统API之上。该接口层使在ACE中的其他层与部件与下面的平台相关的操作系统API隔离开来：
　　并发与同步 – ACE接口层封装了操作系统的多线程、多进程与同步机制相关的API。
　　进程间通信与共享内存– ACE接口层封装了操作系统的本地与远程进程间通信，和共享内存管理的相关API。
事件分离机制 – ACE的接口层封装了操作系统中，有关同步和异步分离基于I/O、计时器、信号量、和同步事件的部分功能。
　　显式动态链接– ACE接口层封装了操作系统的显式动态链接相关的API，该功能允许应用服务不管在安装与运行时都可被配置。
　　文件系统机制 — ACE接口层封装了操作系统的文件系统API来操作文件与目录。
　　ACE操作系统接口层的移植性使它可以在许多不同的操作系统平台上运行。 ACE已经在许多操作系统平台上被移植并被测试 包括Win32 (i.e., WinNT 3.5.x, 4.x, 2000, Win95/98, and WinCE using MSVC++, Borland C++ Builder, and IBM’s Visual Age on Intel and Alpha platforms), 许多UNIX的版本 (e.g., Solaris 1.x and 2.x on SPARC and Intel, SGI IRIX 5.x and 6.x, DG/UX, HP-UX 9.x, 10.x, and 11.x, DEC/Compaq UNIX 3.x and 4.x, AIX 3.x and 4.x, DG/UX, UnixWare, SCO, and freely available UNIX implementations, such as Debian Linux 2.x, RedHat Linux 5.2 and 6.0, FreeBSD, and NetBSD), 实时操作系统(e.g., LynxOS, VxWorks, Chorus ClassiX 4.0, QnX Neutrino, and PSoS), MVS OpenEdition, and CRAY UNICOS. 单一的原代码树被用到所有操作系统平台上。
　　ACE当前也有JAVA版本。
　　因为有ACE操作系统接口平台的抽象，单一的原代码树被用到所有操作系统平台上，该设计简化了ACE的可移植性与可维护性。

4. 操作系统接口的C++包装接口（C++ Wrapper Facades for OS Interfaces）

　　我们完全可以直接在ACE操作系统接口层之上开发高移植性的C++程序。但是，更多的开发者选择使用如图所示ACE的C++封装层。C++封装层通过提供封装并增强本地操作系统并发控制、通信、内存管理、事件分离、动态链接，与文件系统API，提供类型安全接口简化应用的开发。应用可通过有选择的继承、聚集或实例化下列对象来使用这些封装：
　　并发与同步部件-ACE抽象了本地操作系统的多线程和多进程机制，如互斥，信号量来创建如活动对象（Active Objects）与多态未来（Polymorphic Futures）等高级面向对象并发抽象。
　　进程间通信与文件部件 –ACE C++ 包装者封装了本地和远程的进程间通信机制如：接口（sockets）, TLI, UNIX FIFOs与STREAM pipes, 以及Win32 的命名管道（Named Pipes）. ACE C++ 包装者封装了操作系统当中文件系统的APIs。
　　内存管理部件 – ACE的内存管理部件对于管理进程间共享内存和进程外栈内存的动态分配与回收，提供了灵活、可扩展的抽象机制。
　　C++包装者提供了许多与操作系统接口层同样的特性。但是，这些特性不是使用单独的C函数构造的，他们是使用C++类与对象来构造的。这些面向对象的包可减少直接学习与使用ACE所花费的精力。
　　比如，由于C++包装者是强类型的，所以，使用它可以增强应用的健壮性。因此，编译器可以在编译时间检测到系统类型不匹配而不是在运行时间。相反，对于C级别的操作系统的一些API如，接口、文件系统I/O等，在运行时间之前几乎不能检查到系统类型的不匹配 。
　　ACE使用许多技术来减少或最小化执行成本。如ACE通过它的操作系统接口层和C++包装者提供的附加的类型安全性与不同的抽象级别，使用C++扩展的内联性（inlining）减少相关的方法调用的成本。同时，ACE注意避免在关键任务的包装者上使用需方法，如接口与文件I/O的send/recv方法。

5. 框架结构（Frameworks）　

　　ACE同时包含了高级网络编程框架，该框架集成且增强了低一级的C++包装接口。该框架支持动态地将并发分布式服务配置成为应用。ACE的框架结构部分包含以下部件：
　　事件分离器部件（Event demultiplexing components）–ACE的接收者（Reactor）与超动者（Proactor）是可扩展的、面向对象的事件分离器。这些分离器可以基于各种类型的I/O、计时器、信号量、与同步相关事件来分发各种应用相关的操作句柄。
　　服务初始化部件（Service initialization components）–ACE 接收者（Acceptor）和连接者（Connector）部件是分别从特定应用任务中分离出来的，在服务初始化完成后，执行主动与被动初始化角色。
服务配置部件（Service configuration components ）– ACE服务配置管理者可以配置应用，使其可在安装或运行时组装服务。
　　分层流部件（Hierarchically-layered stream components） — ACE流部件简化了通信软件应用的开发过程，比如用户级的协议堆栈，它可由层次结构的服务构成。
　　ORB接口部件（ORB adapter components） — ACE可以通过其ORB接口部件，无缝地集成单线程和多线程的CORBA应用。
　　使用ACE框架部件可促进通信软件的开发。使用它，通信软件可以在不用修改、重新编译、重新链接、或是经常重新启动应用程序的情况下，更新或扩展应用。该灵活性在ACE中是通过结合以下方面实现的：
　　a) C++语言特性，如模板、继承、和动态帮定。
　　b) 设计模式，如抽象类工厂、策略、以及服务配置器等。
　　c) 操作系统机制，如显式的动态链接与多线程。

6. 分布式服务与部件（Distributed Services and Components）

　　除了它的操作系统接口层，C++封装层和各种框架部件外，ACE同时提供一套分布式服务标准库，这些库被分成可自含的包。尽管这些服务部件不是严格的ACE框架库，但这些部件在ACE中有以下角色：
　　给出可重用的应用代码片段-这些服务部件提供了如命名、事件路由、日志、时间同步与网络封锁等一般分布式应用任务的可重用实现。
　　给出ACE部件的基本用例的示范–这些分布式服务同时证明了如何使用象 反应者（Reactors），服务配置（ Service Configurators）,接收者与连接者（ Acceptors and Connectors），活动对象（Active Objects），以及进程间通信的封装（IPC wrappers） 等ACE部件，有效开发灵活、高效和可靠的通信软件。

7. 高级分布式计算中间件对象（Higher-level Distributed Computing Middleware Components）

　即使使用象ACE这样的通信框架，开发健壮的、可扩展并且高效的通信程序是非常有挑战性的工作。开发人员必须掌握大量的复杂操作系统与通信概念，比如：
网络寻址与服务识别
　　描述转换, 如在异构系统间和不同处理器的字节循序间的加密、压缩与网络字节顺序转换。
　　进程与线程的创建与同步。
　　系统调用和对于本地与远程的进程间通信机制的类库常规接口。
　　通过使用如CORBA，DCOM或JAVA RMI等高级的分布计算中间件，有可能减轻部分开发通信应用的复杂程度。高级分布计算中间件包含有服务器端与客户端两部分，并自动完成许多繁杂且易于出错的分布式应用开发工作，比如：
　　验证，授权与数据安全。
　　服务的查找与帮定。
　　服务的注册与激活。
　　对于事件的分离与发送。
　　在面向字节流通信协议之上实现如TCP协议的消息框架。
　　如网络字节码转换或参数排列等的描述转换问题处理。
　　为了给通信软件开发者提供这些特性，在ACE中打包了下面的高级中间件应用：
　　ACE ORB (TAO) – TAO是使用ACE中提供的框架结构对象与模式实现的针对高效与实时系统的CORBA应用。TAO中包含了网络接口，操作系统，通信协议以及CORBA中间件对象与相关特性。TAO基于标准的OMG的CORBA参考模型, 并且针对传统ORBS对于高效和实时应用系统的缺点，加入了相应的改善设计。TAO,与 ACE一样，都是免费的开放原代码的软件。
　　JAWS — JAWS TAO是使用ACE中提供的框架结构对象与模式实现的针对高效与实时系统的可适应性的WEB服务器。JAWS 被设计为框架的框架。JAWS的总体框架包含以下部件与框架： 一个事件调配者,并发策略 ，I/O 策略，协议管道 , 协议处理者，以及缓冲的虚拟文件系统。通过结合与扩展ACE中的部件，每种框架被设计为一套可协作的对象。JAW也是免费的开放原代码的软件。

0

flickr对javascript干的好事

Posted: August 17, 2006 at 11:26 am | Tags: blog, cache, flickr, html, java, javascript, php, unix, web, windows, 优化, 开发, 技巧, 技术, 类, 缓存, 网站, 翻译

在一个讨论web技术的网站vitamin上发现这篇《Serving JavaScript Fast》，读过之后大有收获，茅塞顿开。于是就有了翻译过来的念头——我这人有个毛病，看到有意思的英文文章，就想自己翻过来（虽然英文水平很烂）。先在网上查了查，已经有blog谈到这篇文章（我算是后知后觉了），有总结要点的《Flickr 的开发者的 Web 应用优化技巧》，也有延伸开来的《接着讲Flickr的八卦》，但似乎没有全文翻译的（这下就好，不会忙了半天发现是无用功）。之后，就写信问作者可不可以，作者一口答应：“sure – i’d love you to translate it”，只是要求我翻好之后给他一个链接地址。得到准许，心里就有底了。

先介绍一下作者。Cal Henderson，伦敦人，现居加利福尼亚的旧金山。PHP，MySQL和Perl专家，现任flickr架构师（flickr被收购后就在yahoo了），同时也是vitamin的特聘顾问（写些技术性文章）。

既然他是架构师，flickr用的应该就是文中谈到的这些技术，于是参照文章，再对比网站，种种迹象表明确实如此。虽然在中国访问flickr速度不敢恭维，加速效果不得而知，但其用了n多css和javascript资源却似乎从没出过什么问题，也从侧面印证了这些技术的有效性。

仔细的看完文章，还有个强烈的感觉：这老兄也太能卖关子了，一句话非分成三句说，摆事实讲道理是够透彻，就是有点太@#$%了…… 算了，他怎么说我怎么翻吧，忠实于原著嘛，要不就成篡改了。经过几天努力，加上同事thincat兄倾力援手（小弟不胜感激啊），终于完工（@_@ 真是苦力活啊，我再也不想干了～）。

全文翻译如下：

让javascript跑得更快

作者：Cal Henderson

下一代web应用让javascript和css得堪大用。我们会告诉你怎样使这些应用又快又灵。

建立了号称“Web 2.0”的应用，也实现了富内容（rich content）和交互，我们期待着css和javascript扮演更加重要的角色。为使应用干净利落，我们需要完善那些渲染页面的文件，优化其大小和形态，以确保提供最好的用户体验——在实践中，这就意味着一种结合：使内容尽可能小、下载尽可能快，同时避免对未改动资源不必要的重新获取。

由于css和js文件的形态，情况有点复杂。跟图片相比，其源代码很有可能频繁改动。而一旦改动，就需要客户端重新下载，使本地缓存无效（保存在其他缓存里的版本也是如此）。在这篇文章里，我们将着重探讨怎样使用户体验最快：包括初始页面的下载，随后页面的下载，以及随着应用渐进、内容变化而进行的资源下载。

我始终坚信这一点：对开发者来说，应该尽可能让事情变得简单。所以我们青睐于那些能让系统自动处理优化难题的方法。只需少许工作量，我们就能建立一举多得的环境：它使开发变得简单，有极佳的终端性能，也不会改变现有的工作方式。

好大一沱

老的思路是，为优化性能，可以把多个css和js文件合并成极少数大文件。跟十个5k的js文件相比，合并成一个50k的文件更好。虽然代码总字节数没变，却避免了多个HTTP请求造成的开销。每个请求都会在客户端和服务器两边有个建立和消除的过程，导致请求和响应header带来开销，还有服务器端更多的进程和线程资源消耗（可能还有为压缩内容耗费的cpu时间）。

（除了HTTP请求，）并发问题也很重要。默认情况下，在使用持久连接（persistent connections）时，ie和firefox在同一域名内只会同时下载两个资源（在HTTP 1.1规格书中第8.1.4节的建议）（htmlor注：可以通过修改注册表等方法改变这一默认配置）。这就意味着，在我们等待下载2个js文件的同时，将无法下载图片资源。也就是说，这段时间内用户在页面上看不到图片。

（虽然合并文件能解决以上两个问题，）可是，这个方法有两个缺点。第一，把所有资源一起打包，将强制用户一次下载完所有资源。如果（不这么做，而是）把大块内容变成多个文件，下载开销就分散到了多个页面，同时缓解了会话中的速度压力（或完全避免了某些开销，这取决于用户选择的路径）。如果为了随后页面下载得更快而让初始页面下载得很慢，我们将发现更多用户根本不会傻等着再去打开下一个页面。

第二（这个影响更大，一直以来却没怎么被考虑过），在一个文件改动很频繁的环境里，如果采用单文件系统，那么每次改动文件都需要客户端把所有css和js重新下载一遍。假如我们的应用有个100k的合成的js大文件，任何微小的改动都将强制客户端把这100k再消化一遍。

分解之道

（看来合并成大文件不太合适。）替代方案是个折中的办法：把css和js资源分散成多个子文件，按功能划分、保持文件个数尽可能少。这个方案也是有代价的，虽说开发时代码分散成逻辑块（logical chunks）能提高效率，可在下载时为提高性能还得合并文件。不过，只要给build系统（把开发代码变成产品代码的工具集，是为部署准备的）加点东西，就没什么问题了。

对于有着不同开发和产品环境的应用来说，用些简单的技术可以让代码更好管理。在开发环境下，为使条理清晰，代码可以分散为多个逻辑部分（logical components）。可以在Smarty（一种php模板语言）里建立一个简单的函数来管理javascript的下载：

SMARTY:{insert_js files="foo.js,bar.js,baz.js"}PHP:function smarty_insert_js($args){  foreach (explode(',', $args['files']) as $file){    echo "<script type=\"text/javascript\" SOURCE=\"/javascript/$file\"></script>\n";  }}OUTPUT:<script type="text/javascript" SOURCE="/javascript/foo.js"></script><script type="text/javascript" SOURCE="/javascript/bar.js"></script><script type="text/javascript" SOURCE="/javascript/baz.js"></script>

（htmlor注：wordpress中会把“src”替换成不知所谓的字符，因此这里只有写成“SOURCE”，使用代码时请注意替换，下同）

就这么简单。然后我们就命令build过程（build process）去把确定的文件合并起来。这个例子里，合并的是foo.js和bar.js，因为它们几乎总是一起下载。我们能让应用配置记住这一点，并修改模板函数去使用它。（代码如下：）

SMARTY:{insert_js files="foo.js,bar.js,baz.js"}PHP:# 源文件映射图。在build过程合并文件之后用这个图找到js的源文件。$GLOBALS['config']['js_source_map'] = array(  'foo.js'	=> 'foobar.js',  'bar.js'	=> 'foobar.js',  'baz.js'	=> 'baz.js',);function smarty_insert_js($args){  if ($GLOBALS['config']['is_dev_site']){    $files = explode(',', $args['files']);  }else{    $files = array();    foreach (explode(',', $args['files']) as $file){      $files[$GLOBALS['config']['js_source_map'][$file]]++;    }    $files = array_keys($files);  }  foreach ($files as $file){    echo "<script type=\"text/javascript\" SOURCE=\"/javascript/$file\"></script>\n";  }}OUTPUT:<script type="text/javascript" SOURCE="/javascript/foobar.js"></script><script type="text/javascript" SOURCE="/javascript/baz.js"></script>

模板里的源代码没必要为了分别适应开发和产品阶段而改动，它帮助我们在开发时保持文件分散，发布成产品时把文件合并。想更进一步的话，可以把合并过程（merge process）写在php里，然后使用同一个（合并文件的）配置去执行。这样就只有一个配置文件，避免了同步问题。为了做的更加完美，我们还可以分析css和js文件在页面中同时出现的几率，以此决定合并哪些文件最合理（几乎总是同时出现的文件是合并的首选）。

对css来说，可以先建立一个主从关系的模型，它很有用。一个主样式表控制应用的所有样式表，多个子样式表控制不同的应用区域。采用这个方法，大多数页面只需下载两个css文件，而其中一个（指主样式表）在页面第一次请求时就会缓存。

对没有太多css和js资源的应用来说，这个方法在第一次请求时可能比单个大文件慢，但如果保持文件数量很少的话，你会发现其实它更快，因为每个页面的数据量更小。让人头疼的下载花销被分散到不同的应用区域，因此并发下载数保持在一个最小值，同时也使得页面的平均下载数据量很小。

压缩

谈到资源压缩，大多数人马上会想到mod_gzip（但要当心，mod_gzip实际上是个魔鬼，至少能让人做恶梦）。它的原理很简单：浏览器请求资源时，会发送一个header表明自己能接受的内容编码。就像这样：

Accept-Encoding: gzip,deflate

服务器遇到这样的header请求时，就用gzip或deflate压缩内容发往客户端，然后客户端解压缩。这过程减少了数据传输量，同时消耗了客户端和服务器的cpu时间。也算差强人意。但是，mod_gzip的工作方式是这样的：先在磁盘上创建一个临时文件，然后发送（给客户端），最后删除这个文件。在高容量的系统中，由于磁盘io问题，很快就会达到极限。要避免这种情况，可以改用mod_deflate（apache 2才支持）。它采用更合理的方式：在内存里做压缩。对于apache 1的用户来说，可以建立一块ram磁盘，让mod_gzip在它上面写临时文件。虽然没有纯内存方式快，但也不会比往磁盘上写文件慢。

话虽如此，其实还是有办法完全避免压缩开销的，那就是预压缩相关静态资源，下载时由mod_gzip提供合适的压缩版本。如果把压缩添加在build过程，它就很透明了。需要压缩的文件通常很少（用不着压缩图片，因为并不能减小更多体积），只有css和js文件（和其他未压缩的静态内容）。

配置选项会告诉mod_gzip去哪里找到预压缩过的文件。

mod_gzip_can_negotiate	Yesmod_gzip_static_suffix	.gzAddEncoding	gzip	.gz

新一点的mod_gzip版本（从1.3.26.1a开始）添加一个额外的配置选项后，就能自动预压缩文件。不过在此之前，必须确认apache有正确的权限去创建和覆盖压缩文件。

mod_gzip_update_static	Yes

可惜，事情没那么简单。某些Netscape 4的版本（尤其是4.06-4.08）认为自己能够解释压缩内容（它们发送一个header这么说来着），但其实它们不能正确的解压缩。大多数其他版本的Netscape 4在下载压缩内容时也有各种各样的问题。所以要在服务器端探测代理类型，（如果是Netscape 4，就要）让它们得到未压缩的版本。这还算简单的。ie（版本4-6）有些更有意思的问题：当下载压缩的javascript时，有时候ie会不正确的解压缩文件，或者解压缩到一半中断，然后把这半个文件显示在客户端。如果你的应用对javascript的依赖比较大（htmlor注：比如ajax应用），那么就得避免发送压缩文件给ie。在某些情况下，一些更老的5.x版本的ie倒是能正确的收到压缩的javascript，可它们会忽略这个文件的etag header，不缓存它。（thincat友情提示：尽管压缩存在一些浏览器不兼容的现象，由于这些不能很好的支持压缩的浏览器数量现在已经非常少了，我认为这种由于浏览器导致的压缩不正常的情况可以忽略不计。这些过时的浏览器还能不能在现在流行的windows或unix环境下面安装都存在不小的问题）

既然gzip压缩有这么多问题，我们不妨把注意力转到另一边：不改变文件格式的压缩。现在有很多这样的javascript压缩脚本可用，大多数都用一个正则表达式驱动的语句集来减小源代码的体积。它们做的不外乎几件事：去掉注释，压缩空格，缩短私有变量名和去掉可省略的语法。

不幸的是，大多数脚本效果并不理想，要么压缩率相当低，要么某种情形下会把代码搞得一团糟（或者两者兼而有之）。由于对解析树的理解不完整，压缩器很难区分一句注释和一句看似注释的引用字符串。因为闭合结构的混合使用，要用正则表达式发现哪些变量是私有的并不容易，因此一些缩短变量名的技术会打乱某些闭合代码。

还好有个压缩器能避免这些问题：dojo压缩器（现成的版本在这里）。它使用rhino（mozilla的javascript引擎，是用java实现的）建立一个解析树，然后将其提交给文件。它能很好的减小代码体积，仅用很小的成本：因为只在build时压缩一次。由于压缩是在build过程中实现的，所以一清二楚。（既然压缩没有问题了，）我们可以在源代码里随心所欲的添加空格和注释，而不必担心影响到产品代码。

与javascript相比，css文件的压缩相对简单一些。由于css语法里不会有太多引用字符串（通常是url路径跟字体名），我们可以用正则表达式大刀阔斧的干掉空格（htmlor注：这句翻的最爽，哈哈）。如果确实有引用字符串的话，我们总可以把一串空格合成一个（因为不需要在url路径和字体名里查找多个空格和tab）。这样的话，一个简单的perl脚本就够了：

#!/usr/bin/perlmy $data = '';open F, $ARGV[0] or die "Can't open source file: $!";$data .= $_ while <F>;close F;$data =~ s!/*(.*?)*/!!g;  # 去掉注释$data =~ s!s+! !g;           # 压缩空格$data =~ s!} !}\n!g;         # 在结束大括号后添加换行$data =~ s!\n$!!;             # 删除最后一个换行$data =~ s! { ! {!g;         # 去除开始大括号后的空格$data =~ s!; }!}!g;          # 去除结束大括号前的空格print $data;

然后，就可以把单个的css文件传给脚本去压缩了。命令如下：

perl compress.pl site.source.css > site.compress.css

做完这些简单的纯文本优化工作后，我们就能减少数据传输量多达50%了（这个量取决于你的代码格式，可能更多）。这带来了更快的用户体验。不过我们真正想做的是，尽可能避免用户请求的发生——除非确实有必要。这下HTTP缓存知识派上用场了。

缓存是好东西

当用户代理（如浏览器）向服务器请求一个资源时，第一次请求过后它就会缓存服务器的响应，以避免重复之后的相同请求。缓存时间的长短取决于两个因素：代理的配置和服务器的缓存控制header。所有浏览器都有不同的配置选项和处理方式，但大多数都会把一个资源至少缓存到会话结束（除非被明确告知）。

为了不让浏览器缓存改动频繁的页面，你很可能已经发送过header不缓存动态内容。在php中，以下两行命令可以做到：

<?phpheader("Cache-Control: private");header("Cache-Control: no-cache", false);?>

听起来太简单了？确实如此——因为有些代理（浏览器）在某些环境下将忽略这些header。要确保浏览器不缓存文档，应该更强硬一些：

<?php# 让它在过去就“失效”header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");# 永远是改动过的header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");# HTTP/1.1header("Cache-Control: no-store, no-cache, must-revalidate");header("Cache-Control: post-check=0, pre-check=0", false);# HTTP/1.0header("Pragma: no-cache");?>

这样，对于我们不想缓存的内容来说已经行了。但对于那些不会每次请求时都有改动的内容，应该鼓励浏览器更霸道的缓存它。“If-Modified-Since”请求header能够做到这点。如果客户端在请求中发送一个“If-Modified-Since”header，apache（或其他服务器）会以状态代码304（没改过）响应，告诉浏览器缓存已经是最新的。使用这个机制，能够避免重复发送文件给浏览器，不过仍然导致了一个HTTP请求的消耗。嗯，再想想。

与If-Modified-Since机制类似的是实体标记（entity tags）。在apache环境下，每个对静态文件的响应都会发出一个“ETag”header，它包含了一个由文件修改时间、文件大小和inode号生成的校验和（checksum）。在下载文件之前，浏览器会发送一个HEAD请求去检查文件的etag。可ETag跟If-Modified-Since有同样的问题：客户端仍旧需要执行HTTP请求来验证本地缓存是否有效。

此外，如果你使用多台服务器提供内容，得小心使用if-modified-since和etags。在两台负载平衡的服务器环境下，对一个代理（浏览器）来说，一个资源可以这次从A服务器得到，下次从B服务器得到（htmlor注：lvs负载平衡系统就是个典型的例子）。这很好，也是采用平衡负载的原因。可是，如果两台服务器给同一个文件生成了不同的etag或者文件修改日期，浏览器就无所适从了（每次都会重新下载）。默认情况下，etag是由文件的inode号生成的，而多台服务器之间文件的inode号是不同的。可以使用apache的配置选项关掉它：

FileETag MTime Size

使用这个选项，apache将只用文件修改日期和文件大小来决定etag。很不幸，这导致了另一个问题（一样能影响if-modified-since）。既然etag依赖于修改时间，就得让时间同步。可往多台服务器上传文件时，上传时间差个一到两秒是常有的事。这样一来，两台服务器生成的etag还是不一样。当然，我们还可以改变配置，让etag的生成只取决于文件大小，但这就意味着如果文件内容变了而大小没变，etag也不会变。这可不行。

缓存真是个好东西

看来我们正从错误的方向入手解决问题。（现在的问题是，）这些可能的缓存策略导致了一件事情反复发生，那就是：客户端向服务器查询本地缓存是否最新。假如服务器在改动文件的时候通知客户端，客户端不就知道它的缓存是最新的了（直到接到下一次通知）？可惜天公不做美——（事实）是客户端向服务器发出请求。

其实，也不尽然。在获取js或css文件之前，客户端会用<script>或<link>标记向服务器发送一个请求，说明哪个页面要加载这些文件。这时候就可以用服务器的响应来通知客户端这些文件有了改动。有点含糊，说得再详细点就是：如果改变css和js文件内容的同时，也改变它们的文件名，就可以告诉客户端对url全都永久缓存——因为每个url都是唯一的。

假如能确定一个资源永不更改，我们就可以发出一些霸气十足的缓存header（htmlor注：这句也很有气势吧）。在php里，两行就好：

<?phpheader("Expires: ".gmdate("D, d M Y H:i:s", time()+315360000)." GMT");header("Cache-Control: max-age=315360000");?>

我们告诉浏览器这个内容在10年后（10年大概会有315,360,000秒，或多或少）过期，浏览器将会保留它10年。当然，很有可能不用php输出css和js文件（因此就不能发出header），这种情况将在稍后说明。

人力有时而穷

当文件内容更改时，手动去改文件名是很危险的。假如你改了文件名，模板却没有指向它？假如你改了一些模板另一些却没改？假如你改了模板却没改文件名？还有最糟的，假如你改动了文件却忘了改名或者忘了改变对它的引用？最好的结果，是用户看到老的而看不到新的内容。最坏的结果，是找不到文件，网站没法运转了。听起来这（指改动文件内容时修改url）似乎是个馊主意。

幸运的是，计算机做这类事情——当某种变化发生，需要相当准确地完成的、重复重复再重复的（htmlor注：番茄鸡蛋伺候～）、枯燥乏味的工作——总是十分在行。

这个过程（改变文件的url）没那么痛苦，因为我们根本不需要改文件名。资源的url和磁盘上文件的位置也没必要保持一致。使用apache的mod_rewrite模块，可以建立简单的规则，让确定的url重定向到确定的文件。

RewriteEngine onRewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$	/$1$2	[L]

这条规则匹配任何带有指定扩展名同时含有“版本”信息（version nugget）的url，它会把这些url重定向到一个不含版本信息的路径。如下所示：

URL			   Path/images/foo.v2.gif	-> /images/foo.gif/css/main.v1.27.css	-> /css/main.css/javascript/md5.v6.js	-> /javascript/md5.js

使用这条规则，就可以做到不改变文件路径而更改url（因为版本号变了）。由于url变了，浏览器就认为它是另一个资源（会重新下载）。想更进一步的话，可以把我们之前说的脚本编组函数结合起来，根据需要生成一个带有版本号的<script>标记列表。

说到这里，你可能会问我，为什么不在url结尾加一个查询字符串（query string）呢（如/css/main.css?v=4）？根据HTTP缓存规格书所说，用户代理对含有查询字符串的url永不缓存。虽然ie跟firefox忽略了这点，opera和safari却没有——为了确保所有浏览器都缓存你的资源，还是不要在url里用查询字符串的好。

现在不移动文件就能更改url了，如果能让url自动更新就更好了。在小型的产品环境下（如果有大型的产品环境，就是开发环境了），使用模板功能可以很轻易的实现这点。这里用的是smarty，用其他模板引擎也行。

SMARTY:<link xhref="{version xsrc='/css/group.css'}" rel="stylesheet" type="text/css" />PHP:function smarty_version($args){  $stat = stat($GLOBALS['config']['site_root'].$args['src']);  $version = $stat['mtime'];  echo preg_replace('!.([a-z]+?)$!', ".v$version.$1", $args['src']);}OUTPUT:<link xhref="/css/group.v1234567890.css" rel="stylesheet" type="text/css" />

对每个链接到的资源文件，我们得到它在磁盘上的路径，检查它的mtime（文件最后修改的日期和时间），然后把这个时间当作版本号插入到url中。对于低流量的站点（它们的stat操作开销不大）或者开发环境来说，这个方案不错，但对于高容量的环境就不适用了——因为每次stat操作都要磁盘读取（导致服务器负载升高）。

解决方案相当简单。在大型系统中每个资源都已经有了一个版本号，就是版本控制的修订号（你们应该使用了版本控制，对吧？）。当我们建立站点准备部署的时候，可以轻易的查到每个文件的修订号，写在一个静态配置文件里。

<?php$GLOBALS['config']['resource_versions'] = array(  '/images/foo.gif'    => '2.1',  '/css/main.css'      => '1.27',  '/javascript/md5.js' => '6.1.4',);?>

当我们发布产品时，可以修改模板函数来使用版本号。

<?phpfunction smarty_version($args){  if ($GLOBALS['config']['is_dev_site']){    $stat = stat($GLOBALS['config']['site_root'].$args['src']);    $version = $stat['mtime'];  }else{    $version = $GLOBALS['config']['resource_versions'][$args['src']];  }  echo preg_replace('!.([a-z]+?)$!', ".v$version.$1", $args['src']);}?>

就这样，不需要改文件名，也不需要记住改了哪些文件——当文件有新版本发布时它的url就会自动更新——有意思吧？我们就快搞定了。

只欠东风

之前谈到为静态文件发送超长周期（very-long-period）的缓存header时曾说过，如果不用php输出，就不能轻易的发送缓存header。很显然，有两个办法可以解决：用php输出，或者让apache来做。

php出马，手到擒来。我们要做的仅仅是改变rewrite规则，把静态文件指向php脚本，用php在输出文件内容之前发送header。

Apache:RewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$  /redir.php?path=$1$2  [L]PHP:header("Expires: ".gmdate("D, d M Y H:i:s", time()+315360000)." GMT");header("Cache-Control: max-age=315360000");# 忽略带有“..”的路径if (preg_match('!..!', $_GET[path])){ go_404(); }# 保证路径开头是确定的目录if (!preg_match('!^(javascript|css|images)!', $_GET[path])){ go_404(); }# 文件不存在？if (!file_exists($_GET[path])){ go_404(); }# 发出一个文件类型header$ext = array_pop(explode('.', $_GET[path]));switch ($ext){  case 'css':    header("Content-type: text/css");    break;  case 'js' :    header("Content-type: text/javascript");    break;  case 'gif':    header("Content-type: image/gif");    break;  case 'jpg':    header("Content-type: image/jpeg");    break;  case 'png':    header("Content-type: image/png");    break;  default:    header("Content-type: text/plain");}# 输出文件内容echo implode('', file($_GET[path]));function go_404(){  header("HTTP/1.0 404 File not found");  exit;}

这个方案有效，但并不出色。（因为）跟apache相比，php需要更多内存和执行时间。另外，我们还得小心防止可能由path参数传递伪造值引起的exploits。为避免这些问题，应该用apache直接发送header。rewrite规则语句允许当规则匹配时设置环境变量（environment variable），当给定的环境变量设置后，Header命令就可以添加header。结合以下两条语句，我们就把rewrite规则和header设置绑定在了一起：

RewriteEngine onRewriteRule ^/(.*.)v[0-9.]+.(css|js|gif|png|jpg)$ /$1$2 [L,E=VERSIONED_FILE:1]Header add "Expires" "Mon, 28 Jul 2014 23:30:00 GMT" env=VERSIONED_FILEHeader add "Cache-Control" "max-age=315360000" env=VERSIONED_FILE

考虑到apache的执行顺序，应该把rewrite规则加在主配置文件（httpd.conf）而不是目录配置文件（.htaccess）中。否则在环境变量设置之前，header行会先执行（就那没意义了）。至于header行，则可以放在两文件任何一个当中，没什么区别。

眼观六路

（htmlor注：多谢tchaikov告知“skinning rabbits”的含义，但我不想翻的太正式，眼下的这个应该不算太离谱吧。）

通过结合使用以上技术，我们可以建立一个灵活的开发环境和一个快速又高性能的产品环境。当然，这离终极目标“速度”还有一段距离。有许多更深层的技术（比如分离伺服静态内容，用多域名提升并发量等）值得我们关注，包括与我们谈到的方法（建立apache过滤器，修改资源url，加上版本信息）殊途同归的其他路子。你可以留下评论，告诉我们那些你正在使用的卓有成效的技术和方法。

（完）