set x=%cd%\%1
cd %x%\chrome
7z a -tzip %1.jar * -r
cd ..
7z a -tzip %1.xpi * -ir!*.jar -x!*.zip -x!*.xpi
del %x%\chrome\%1.jar
cd ..

执行以下命令即可：

build.bat 扩展的相对路径

关于7z命令行的说明，在这里：http://www.anywolfs.com/liuhui/article.asp?id=291

在google reader中将要导出的博客归入一个新建的类别（label），最好为英文，并在“设置”中将此类别设为“公开”。

通过以下URL即可查看该博客的atom格式的种子（feed）输出：

http://www.google.com/reader/public/atom/user/{userid}/label/{labelname}?n=1000

其中{userid}，可以在 这个页面 的“在新窗口中预览共享条目页”连接中找到。{labelname}是刚刚那个新建的类别名称。n=1000代表一次性输出1000条。

google reader只提供了atom格式的feed输出(后来知道blogger也是如此)，但wordpress却只接受rss格式的输入。他俩不会有仇吧？

为了将atom转换成rss，于是在GAE上做了个atom2rss的工具：http://atom2rss.appspot.com。如果不知道修改hosts文件直接访问appspot的方法，访问可能需要翻墙。

简单介绍下atom2rss这个小工具吧。

1，只支持Atom1.0到RSS2.0的转换并需要提供atom1.0格式种子的URL

2，使用jython+modjy编写，运行于Google AppEngine

3，使用了 http://atom.geekhood.net/ 提供的XSLT转换模板。

4，代码在这里：http://code.google.com/p/atom2rss-jython/

/usr/local/apache-2.2.4/bin/htpasswd -c ./passwd kevin

这样，就为用户名为“kevin”的用户在当前目录下的passwd文件中创建了一条记录，内容包含用户名及将用户输入的密码加密后字符串。如果文件已存在，则可忽略参数“-c”。

用久了，就会发现，相同的用户名和密码，每一次使用htpasswd命令之后生成的加密字符串都是不同的。那么在随后的应用中，apache又是怎么来校验“用户输入密码经加密后的结果”与“文件中已存在的加密结果”是否匹配呢？

htpasswd默认情况，是使用系统库中的crypt()函数来对密码明文进行单向加密的。在网上找到该函数的说明：

crypt()将使用Data Encryption Standard(DES)演算法将参数key所指的字符串加以编码，key字符串长度仅取前8个字符，超过此长度的字符没有意义。参数salt为两个字 符组成的字符串，由a-z,A-Z,0-9,".",和"/"所组成，用来决定使用4096种不同内建表格的哪一个。函数执行成功后会返回指向编码过的字符串指针，参数key所指的字符串不会有所更动。编码过的字符串长度为13个字符，前两个字符为参数salt代表的字符串。

默认情况下，htpasswd在对密码明文加密的时候，会随机生成一个两位的salt值。加密后的13位字符串的头两位即是这个salt的值。

在应用过程中，apache根据用户输入的用户名查找出密码文件中已存在的加密字符串，并取该字符串的头两位作为salt，以此对用户输入的密码明文进行crypt()加密，如果结果与密码文件中的加密字符串相同，则匹配上了。

综上所述，对于同一个字符串，crypt()函数的加密结果受到第二个可选参数“salt”(干扰串)影响，而加密结果中又含有这个干扰串。这就明白了虽然用htpasswd每次生成的加密结果不同(随机生成salt并包含在结果中)但apache又可以进行正确校验(salt已知)的原因了。

还有，因为htpasswd默认使用crypt()函数进行加密，所以，在这种情况下密码内容超过8位的字符没有意义。即，“12345678”与“123456789”的加密结果是一样的。

我们通常说的基于HTTP的基本验证(Basic Authorization)的英文全称应该是“Basic Access Authorization”，这是在RFC2617中定义的。

在一个HTTP交互的过程中，“基本连接认证”(没有找到中文翻译，姑且这么叫吧)是一个允许浏览器或其他客户端程序在发起请求时向服务器端以用户名+密码的方式提供身份证明的方法。

在传输之前，用户名和密码被一个冒号连接在一起，并以base64算法进行编码，如用户名“kevin”和密码“9511.net”先用冒号进行连接成“kevin:9511.net”，然后再对这个新字符串用base64算法编码，结果就是“a2V2aW46OTUxMS5uZXQ==”。这个经base64算法编码后的字符串被提交到服务器端，并由服务器端用base64算法进行解码，然后用一个冒号分割出用户名和密码，最后由服务器端针对用户和密码进行认证。

在具体的传输环节上，由于此认证方式是基于HTTP协议，所以请求和响应的内容都是存在于header中。For Example：

客户端请求
GET /private/index.html HTTP/1.0
Host: localhost

服务器端响应：
HTTP/1.0 401 Authorization Required   <== 状态码
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:18:15 GMT
WWW-Authenticate: Basic realm=”Secure Area”  <==必要值，realm的值可自定义
Content-Type: text/html
Content-Length: 311

此时客户端收到响应后，会出现一个对话框，由用户填写用户名和密码。并将用户填写的内容经处理发送到服务器端：
GET /private/index.html HTTP/1.0
Host: localhost
Authorization: Basic a2V2aW46OTUxMS5uZXQ==

服务端对再次收到的数据进行处理，如果认为此用户通过，则返回正常的请求结果。

基本连接认证的整个过程就是这么简单，在最流行、装机量最大的WEB服务器软件apache中内置了对基本连接认证的支持。怎么在apache内配置实用，网上到处都是复制来复制去的文章，就不多说了。

其实包括PHP在内的语言好多语言，都可以通过自定义header信息来提供独立于web server之外的基本连接认证支持。比如PHP，如果一个Request中包含“Authorization: Basic a2V2aW46OTUxMS5uZXQ==”这样的内容，PHP就会将“a2V2aW46OTUxMS5uZXQ==”进行解码然后将用户名和密码分别放入$_SERVER['PHP_AUTH_USER']和$_SERVER['PHP_AUTH_PW']两个超全局变量中，那么剩下的就跟上面说的过程都一样了。

由于checksetup.pl脚本的存在，其实bugzilla的安装应该是非常顺利的，10多分钟，基本所有bugzilla需要的cpan扩展包都安装成功，最后出了一个数据库选择的提示。bugzilla目前可支持MySQL、PostgreSQL、Oracle三种数据库，需要要按自己的实际环境安装不同数据库的CPAN模块。所有的中文文档里，对这个步骤的形容都是跟其他模块一样，一条“/usr/bin/perl install-module.pl DBD::mysql”就可以搞定，可实际上……并非如此，起码我这么装没有成功，我个人估计，是因为他们安装Bugzilla的服务器跟mysql所运行的服务器在一台上面。我要安装Bugzilla的服务器，只编译安装了mysqlclient，并没有server存在。

在安装Bugzilla的时候，通过其提供的“install-module.pl”命令安装的CPAN模块，都是装在Bugzilla所在目录的lib目录下。而手动下载CPAN模块并安装的时候，在我的这台服务器上，默认是安装到“/usr/lib/perl5/5.8.5/”目录下的。这两个目录的结构相同。Bugzilla的checksetup.pl脚本在检测安装所需模块的时候，这连个路径都会扫描。

通过http://search.cpan.org搜索“DBD-mysql”，并下载“DBD::mysql”。解压缩后运行下面命令：

perl Makefile.PL –libs=”-L/usr/local/mysql-5.1.36/lib/mysql -lmysqlclient -L/usr/lib -lz” –cflags=-I/usr/local/mysql-5.1.36/include/mysql –mysql_config=/usr/local/mysql-5.1.36/bin/mysql_config –testhost=192.168.1.208 –testdb=test –testuser=bugs –testpassword=bugs

其中的“/usr/local/mysql-5.1.36”是安装mysqlclient的路径。在安装DBD::mysql的时候，会检测与mysql服务器的联通性，这里的testhost、testdb、testuser、testpassword就是做这个用的。用户bugs我事先在mysql服务器添加好了。

安装好“DBD::mysql”后，再次运行checksetup.pl脚本，出现了如下提示：

Reading ./localconfig…
Checking for       DBD-mysql (v2.9003) ok: found v4.005
Had to create DBD::mysql::dr::imp_data_size unexpectedly at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/DBI.pm line 1213, <DATA> line 228.
Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/DBI.pm line 1213, <DATA> line 228.
Had to create DBD::mysql::db::imp_data_size unexpectedly at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI.pm line 1243, <DATA> line 228.
Use of uninitialized value in subroutine entry at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBI.pm line 1243, <DATA> line 228.
There was an error connecting to MySQL:

Undefined subroutine &DBD::mysql::db::_login called at /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/DBD/mysql.pm line 142, <DATA> line 228.

在网上查了很长时间，按照网上的描述，修改localconfig文件n次，重新安装配置DBD::mysqln次，依然未果，而且就网上的说法，造成这个错误提示的原因有很多种。正在抓耳挠腮，郁闷之极的时候，突然看到一个邮件里表里有说mysql lib的问题。马上想到自己安装mysql的时候，是rpm卸载掉系统默认的4.0后，手动编译安装的mysql5.1。赶紧运行ldconfig，靠的，还真没有mysql的lib。修改/etc/ld.so.conf文件，把mysql的lib路径加进去，运行ldconfig。然后回到bugzilla目录重新运行checksetup.pl，一切哦耶了。

在中文论坛里，也看到一些人说mysql本来是4.x，bugzilla运行正常，后来升级成5.x之后，就出错了。这些错误应该也是跟我的问题一样，跟mysql的版本没什么关系。

关于ldconfig的问题，再次提醒下自己……http://kevin.9511.net/archives/177.html

>tasklist|findstr “xxxxx”           OVER

不像Unix/Linux平台还有一个 TZ 环境变量可以用，在WIN32平台下， 不设置时区，那么时间都是按照格林威治标准时间走的。比如“北京时间上午10点”，在你的脚本里就会认为是凌晨2点(减8小时)。

PHP的默认时区，可以通过修改php.ini的 date.timezon 值来设定。

date_default_timezone_get()函数可以得到你的脚本中所有日期时间函数所使用的默认时区。如果它返回的是UTC，则说明没有被设置一个默认的时区。除了修改php.ini文件，我们还可以在脚本中用 date_default_timezone_set()函数来进行默认时区的设置。

下面这些，都是设置为北京时间(GMT+8)的

date_default_timezone_set(’Asia/Chongqing’); //重庆
date_default_timezone_set(’Asia/Chungking’); //重庆
date_default_timezone_set(’Asia/Harbin’);//哈尔滨
date_default_timezone_set(’Asia/Hong_Kong’);//香港
date_default_timezone_set(’Asia/Macau’);//澳门
date_default_timezone_set(’Asia/Macao’);//澳门
date_default_timezone_set(’Asia/Shanghai’);//上海
date_default_timezone_set(’Asia/Taipei’);//台北
date_default_timezone_set(’Asia/Urumqi’);//乌鲁木齐

参见：date_default_timezone_get() date_default_timezone_set PHP所支持时区列表

$root_path = ‘/web/www’; //网站根目录
$file_path = ‘/data/t.txt’;  //文件路径

//发送下载的头信息
header(”Content-type: application/x-octet-stream”);
header(”Accept-Ranges: bytes”);
header(”Content-Disposition: attachment; filename=”.basename($file_path));
header(”Content-Length: “.filesize($root_path.$file_path));

//发送文件定位，是相对网站目录的路径
header(”X-Accel-Redirect: “.$file_path);

MEDIUMTEXT 是 2G

LONGTEXT 是 4G .

psql my_db < backup.sql

但是，如果通过这个命令导入，就会成功，并且数据是完全正确的：

psql -d my_db -f backup.sql

上面的两种导入方式，在linux下面都是没有问题的。至于为什么windows下出问题，完全不知道……

网上的很多关于ProFTPD搭载数据库进行管理的文章，大多用的都是MySQL(搜baidu的结果)和PostgreSQL(搜google的结果)，可是单单为了一个公司内部使用的这么一个小平台，使用这么两个重量级的数据库，是在有点杀鸡用牛刀的感觉。对于我的需求，Sqlite这个轻量级的嵌入式数据库，显然是最最合适的选择。在网上跑来跑去找了1个多小时，也没有一篇像样的配置文档，甚至连ProFTPD的官方doc里，提起sqlite也是只言片语。没办法，只有自己对着英文的Howto，自己摸索了。

1，Install Sqlite3 and ProFTPD
下载安装Sqlite3最新版：http://www.sqlite.org/

#tar -zxf sqlite-amalgamation-3.6.13.tar.gz
#cd sqlite-3.6.13/
#./configure
#make
#make install

下载安装ProFTPD最新版：http://www.proftpd.org/
ProFTPD对于数据库的支持，并不是通过linux的PAM方式来实现的
而是内置了模块，这点曾经让我走了很多弯路，TMD居然没有文章提及这点。使用sqlite模块:

#tar -zxf proftpd-1.3.2.tar.gz
#cd proftpd-1.3.2
#./configure –prefix=/usr/local/proftpd –with-modules=mod_sql:mod_sql_sqlite
#make
#make install

2，配置ProFTPD
编辑/usr/local/proftpd/etc/proftpd.conf文件，加入下面列出来的这一大坨参数。
这里只说说跟Sqlite3有关的参数，其他比较有用的参数配置说明，满世界都是。完整配置文件放在最后。
其实除了SQLBackend和SQLConnectInfo两个参数之外，剩下的一些参数在配置其他数据库时也会用到
我在配置这些数据库相关参数的时候，走了很多弯路，查了很多文档，记下来也给自己脑子备个份。

#首先来说这俩，定义proftpd以什么身份来运行，跟apache里的是一个意思
#我是习惯了apache定义为www用户和www组，配置proftpd也就这样了
#以什么身份运行，我个人感觉没啥特别意义，关键是虚拟用户对实体用户的映射！
User www
Group www
#sqlite2跟3差别较大，各软件平台对其支持也是分开来的，比如PHP
#这里就是指明，使用sqlite3
SQLBackend sqlite3
#数据库文件的绝对路径，一定要绝对
SQLConnectInfo /home/www/ftpd.db
#数据库内虚拟用户的密码认证方式
#我认为Backend的意思就是数据库自己的认证方式，比如mysql的password方案
#该方案可以指定多种，使用空格隔开，按照先后，依次try
#下面这句的意思就是“先用sqlite自己的认证方式(我用的明文，其他解决方案没研究)
#如果不行，再使用crypt(3)的方案”，实际配置文件里我只要了一个Backend
SQLAuthTypes Backend Crypt
#自定义存放用户信息的表和字段
#下面这句的意思就是
#users表 里的 字段：用户名 密码 系统映射uid 系统映射gid 主目录 shell路径
#切记：表和字段的名字可以随便起(跟实际数据库中的表和字段相对应)，但顺序不可乱
#按照我对英文howto的理解，前4个字段名是必须要设置的，后两个如果自己用不上
#必须使用NULL来填补，这样mod_sql模块就不会去检索这俩字段了
SQLUserInfo users user_name user_passwd uid gid home_dir NULL
#如果主目录字段名设置为NULL，那么这里这个就必须要定义
#这个是用来定义那些没有“主目录定义的用户”的主目录，有点绕口:P
#SQLDefaultHomedir “/tmp”
#这个参数设置为off的意思，是不让proftpd去检查该FTP用户映射到系统里的用户的shell
#就是说，有没有shell，我都让你登陆。特别是上面的字段，将shell路径这个设置为了NULL
RequireValidShell off
#组信息，没啥意思，就这么放着吧，意思跟上面那个SQLUserInfo一样
#表名 组名 组id 成员
SQLGroupInfo groups group_name gid members
#这里是用户身份认证的程度，只验证user，连带group啥的都验证
#图简单，我这里只验证user这一层
SQLAuthenticate users
#设置ProFTPD允许登陆的最小UID，这个UID是映射到linux系统内实际用户的UID，小于这个值将不允许登陆
#这个值如果不设置，系统默认的是999，在很多国内的文章里，uid和gid都是设置5000多
#所以即使不管这个值，也不会有问题，可是如果你跟我一样，映射用户的uid和gid都小于999了，就要注意它了
#我的www用户的uid和gid都是504，在这里，卡了我有一个多小时，TNND
SQLMinUserUID 500
#这两个的意思，是所有未在数据库中定义uid和gid的用户的默认uid及gid
SQLDefaultUID 504
SQLDefaultGID 504

我的完整的proftpd.conf文件

http://rui7905.googlecode.com/svn/trunk/proftpd_sqlite3

3，建立数据库及用户表
#sqlite3 /home/www/ftpd.db 数据库就建好了，简单吧~
其实理论上，这个文件的路径，是放在哪里都可以的。我配置完这个平台后，又用php写了一个简单的管理平台
为了方便我的apache运行用户www读写数据库，就放在了www的主目录下。。
在sqlite3环境下，用下面这个语句建立数据表

CREATE TABLE “users” (”user_name” varchar(20), “user_passwd” varchar(50), “uid” int(11) NOT NULL DEFAULT 504, “gid” int(11) NOT NULL DEFAULT 504, “home_dir” varchar(200), “shell” varchar(200))

下面创建一个新用户：

INSERT INTO “users” VALUES(’test’,'test’,504,504,’/home/www/ftp/test’,NULL);

表的uid和gid的默认值都设置为了504，即www用户在系统内的uid和gid的值。新添加字段时，这两个字段我也设置了。www用户和组在我系统内是早就建好的，uid和gid分别都是504。通过这两个字段的值，就完成了proftpd内的虚拟用户跟系统内实体用户的映射。具体到自己，请根据实际情况来设置这两个字段的默认值，及新添加记录的值。
4，最后
到现在，整个配置应该是完成了，使用这个命令来启动ProFTPD:

/usr/local/proftpd/sbin/proftpd -c /usr/local/proftpd/etc/proftpd.conf &

参考资料：
ProFTPD Howto:SQL and mod_sql:
http://www.proftpd.org/docs/howto/SQL.html
ProFTPD module mod_sql:
http://www.proftpd.org/docs/contrib/mod_sql.html
ProFTPD module mod_sql_sqlite:
http://www.proftpd.org/docs/contrib/mod_sql_sqlite.html
Configuration Directive List:
http://www.proftpd.org/docs/directives/linked/by-name.html
Simple MySQL Authentication:
http://www.proftpd.org/docs/configs/mysql_simple.conf

搞了一个晚上，最终还是采取了proxy的办法，把发向nginx的svn请求转到apache上去了 ，哎。
为啥nginx没有这方面的解决方案，也大概查了个水落石出。因为这方面中文资料实在是少，让我费了颇多的周折，
现在就明明白白的说一下吧。

在nginx.net的Mailing list里，nginx的作者Igor Sysoev说了，支持SVN需要有三个东西

1) full WebDAV support,
2) DeltaV support,
3) SVN repo format support.

而在nginx里的NginxHttpDavModule，仅仅对以上三项中的第一项WebDAV有了初步的支持(目前来看Igor Sysoev并没有升级的想法)，对于几个高级的WebDAV操作（比如OPTIONS、PROPFIND）并不支持，而这些操作，恰恰是SVN所必须的。而剩下的两项，更是一点支持都没。

所以，就目前来说，想单纯的nginx+subversion，基本上是不可能的。

在刚开始研究这个问题的时候，并不知道除了WebDAV还必须要有其他两个东西。所以满世界找nginx上WebDAV的解决方案，以为搞定这个，就万事大吉了。别说，还真让我在一个老外的博客上给找着一个。这家伙的方法很巧妙，他用通过查阅WebDAV的RFC文档，将绝大多数NginxHttpDavModule不支持的操作用PHP代码实现了，并且通过配置nginx，根据header信息把这些请求重定向到了这个PHP程序。这是这篇博客的地址，有志于自己动手解决这个问题的人，可以参考一下：）

最后感叹一下，为什么计算机方面的问题，总是能在国外的网站和MaillingList找到答案呢？是中国人都不会么？还是这些问题只有我这一个中国人遇到了？

#tar -zxf apr-1.3.3.tar.gz
#cd apr-1.3.3
#./configure
#make
#make install

#tar -zxf apr-util-1.3.4.tar.gz
#cd apr-util-1.3.4
#./configure –with-apr=/usr/local/apr/
#make
#make install

编译apache，加如下参数

–enable-dav –with-apr=/usr/local/apr/bin/apr-1-config –with-apr-util=/usr/local/apr/bin/apu-1-config

2. Install Neon(http://www.webdav.org/neon/)
neon is an HTTP and WebDAV client library, with a C interface.

#tar -zxf neon-0.28.3.tar.gz
#cd neon-0.28.3
#./configure –prefix=/usr/local/neon
#make
#make install

3. Install Subversion (http://subversion.tigris.org/)

#tar -zxf subversion-1.5.2.tar.gz
#cd subversion-1.5.2
#./configure –prefix=/usr/local/subversion –with-apxs=/usr/local/apache2/bin/apxs –with-apr=/usr/local/apr –with-apr-util=/usr/local/apr –with-neon=/usr/local/neon
#make
#make install

编译过程中，发生如下错误

/usr/bin/ld: cannot find -lexpat
collect2: ld returned 1 exit status

确认libexpat已经被载入

# ldconfig -p|grep expat
libexpat.so.0 (libc6) => /usr/lib/libexpat.so.0

做个链接，并重载libs，最后检查一下

#cd /usr/lib
#ln -s libexpat.so.0.5.0 libexpat.so
#ldconfig
#ldconfig -p|grep expat
libexpat.so.0 (libc6) => /usr/lib/libexpat.so.0
libexpat.so (libc6) => /usr/lib/libexpat.so

继续编译，通过，OY
4. 配置
打开apache的httpd.conf文件，查找下面两行内容，如果存在，则表示subversion已经安装成功

LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

建立代码仓库及配置文件

#cd /usr/local/subversion/
#mkdir repos
#mkdir www
#touch auth
#cd repos
#svnadmin create myproject

通过apache的htpasswd工具创建用户，并按提示输入密码

#cd ..
#/usr/local/apache2/bin/htpasswd -c /usr/local/subversion/passwd kevin

编辑auth文件，写入以下内容，赋予此用户对于myproject的读写权限（例子很简单，更复杂的权限配置，请自己去查官方文档或google搜索“SVN权限”）

[/]
* = rw

[/svn]
* = rw

[/svn/myproject]
lirui=rw

配置apache，设置svn的工作目录

<Location /svn>
DAV svn
SVNParentPath /usr/local/subversion/repos
AuthType Basic
AuthName “Subversion repository”
AuthUserFile /usr/local/subversion/passwd
AuthzSVNAccessFile /usr/local/subversion/auth
Require valid-user
</Location>

重启apache

也不知道是机器慢，还是的确如此，编译gcc花了快一个小时。。。很是吐血。

结果编译安装完成后，去编译其他东西，结果发现了找不到编译器的提示。。。

东查西找，左蒙右猜，终于把问题搞定了，问题就出在这个 LD_LIBRARY_PATH 上面

从别处摘抄总结一下。

1. 往/lib和/usr/lib里面加东西，是不用修改/etc/ld.so.conf的，但是完了之后要调一下ldconfig，不然这个library会找不到

2. 想往上面两个目录以外加东西的时候，一定要修改/etc/ld.so.conf，然后再调用ldconfig，不然也会找不到
比如安装了一个mysql到/usr/local/mysql，mysql有一大堆library在/usr/local/mysql/lib下面，这时就需要在/etc/ld.so.conf下面加一行/usr/local/mysql/lib，保存过后ldconfig一下，新的library才能在程序运行时被找到。

3. 如果想在这两个目录以外放lib，但是又不想在/etc/ld.so.conf中加东西（或者是没有权限加东西）。那也可以，就是export一个全局变量LD_LIBRARY_PATH，然后运行程序的时候就会去这个目录中找library。一般来讲这只是一种临时的解决方案，在没有权限或临时需要的时候使用。

4. ldconfig做的这些东西都与运行程序时有关，跟编译时一点关系都没有。编译的时候还是该加-L就得加，不要混淆了。

5. 总之，就是不管做了什么关于library的变动后，最好都ldconfig一下，不然会出现一些意想不到的结果。不会花太多的时间，但是会省很多的事。

LD_LIBRARY_PATH 的意思：告诉loader在哪些目录中可以找到共享库。可以设置多个搜索目录，这些目录之间用冒号分隔开。在linux下，还提供了另外一种方式来完成同样的功能，你可以把这些目录加到/etc/ld.so.conf中，或则在/etc/ld.so.conf.d里创建一个文件，把目录加到这个文件里。当然，这是系统范围内全局有效的，而环境变量只对当前shell有效。按照惯例，除非你用上述方式指明，loader是不会在当前目录下去找共享库的，正如shell不会在当前目前找可执行文件一样。

simply use

#tcpdump -i eth0 -A -s 1024 port 80 | tee dump.log

to log all the packet sent to port 80 to dump.log

MySQL 4.1开始把多国语言字符集分的更加详细，所以导致数据库迁移，或则dz论坛升级到4.0后（dz4.0开始使用gbk或utf-8编码）出现乱码问题。

MySQL 4.1的字符集支持(Character Set Support)有两个方面：字符集(Character set)和排序方式(Collation)。对于字符集的支持细化到四个层次: 服务器(server)，数据库(database)，数据表(table)和连接(connection)。

查看系统的字符集和排序方式的设定可以通过下面的两条命令：
QUOTE:
mysql> SHOW VARIABLES LIKE ‘character_set_%’;
+————————–+—————————-+
| Variable_name | Value |
+————————–+—————————-+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+————————–+—————————-+
7 rows in set (0.00 sec)

mysql> SHOW VARIABLES LIKE ‘collation_%’;
+———————-+——————-+
| Variable_name | Value |
+———————-+——————-+
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
+———————-+——————-+
3 rows in set (0.00 sec)

MySQL 4.1 对于字符集的指定可以细化到一台机器上安装的 MySQL，其中的一个数据库，其中的一张表，其中的一栏，应该用什么字符集。但是，传统的 Web 程序在创建数据库和数据表时并没有使用那么复杂的配置，它们用的是默认的配置，那么，默认的配置从何而来呢？

编译 MySQL 时，指定了一个默认的字符集，这个字符集是 latin1；
安装 MySQL 时，可以在配置文件 (my.ini) 中指定一个默认的的字符集，如果没指定，这个值继承自编译时指定的；
启动 mysqld 时，可以在命令行参数中指定一个默认的的字符集，如果没指定，这个值继承自配置文件中的；
此时 character_set_server 被设定为这个默认的字符集；
当创建一个新的数据库时，除非明确指定，这个数据库的字符集被缺省设定为 character_set_server；
当选定了一个数据库时，character_set_database 被设定为这个数据库默认的字符集；
在这个数据库里创建一张表时，表默认的字符集被设定为 character_set_database，也就是这个数据库默认的字符集；
当在表内设置一栏时，除非明确指定，否则此栏缺省的字符集就是表默认的字符集；
这个字符集就是数据库中实际存储数据采用的字符集，mysqldump 出来的内容就是这个字符集下的；
当我们按照原来的方式通过PHP存取MySQL数据库时，就算设置了表的默认字符集为utf8并且通过UTF-8编码发送查询，你会发现存入数据库的仍然是乱码。问题就出在这个connection连接层上。
想要进行“正确”的存储和得到“正确”的结果，最方便的是在所有query开始之前执行一下：

SET NAMES ‘gbk’;
其中gbk是数据库字符集。

它相当于下面的三句指令：
SET character_set_client = gbk;
SET character_set_results = gbk;
SET character_set_connection = gbk;

4.1和5.0默认使用的是latin1字符集(木头:妈的,老外真霸道,妄想让全世界都是使用瑞典字符集吗)
如果我们只想使用gbk字符集存储和获取数据,
我们在编译mysql 4.1和 5.0的时候，需要注意在my.ini或者my.cnf中添加两处参数
[mysqld]
default-character-set=utf8

#settings for clients (connection, results, clients)
[mysql]
default-character-set=utf8

下面我们来说主题，如何转换数据库字符集

更改存储字符集
主要的思想就是把数据库的字符集有latin1改为gbk，big5,或者utf8; 以下操作必须拥有主机权限。假设当前操作的数据库名为：database

导出
首先需要把数据导为mysql4.0的格式，具体的命令如下：
mysqldump -uroot -p –default-character-set=latin1 –set-charset=gbk –skip-opt databse > d4.sql

–default-characte-set 以前数据库的字符集，这个一般情况下都是latin1的，
–set-charset 导出的数据的字符集，这个可以设置为gbk，utf8,或者big5
导入
首先使用下面语句新建一个GBK字符集的数据库（test）

CREATE DATABASE `d4` DEFAULT CHARACTER SET gbk COLLATE gbk_chinese_ci;
然后把刚才导出的数据导入到当前的数据库中就ok了。

mysql -uroot -p –default-character-set=gbk -f d4<d4.sql
通过以上的导出和导入就把数据库的字符集改为正确的存储方式了。

其中d4为新建库的名称，d4.sql为导出文件的名字

但是这种方法，发现数据库数据存储量无端变大30%，真是郁闷

sqlite.c:56: error: ‘BYREF_NONE’ undeclared here (not in a function)

GOOGLE一番，原来这是个从2006年7月就存在的BUG。虽然官方在pecl.php.net的关于此bug的详情页里说已经修复了，但不止一个人在1年甚至2年后依然表示错误依旧～！看来老外干活也会偷懒啊，出了sqlite3的模块，老的sqlite模块就不维护了，哎～～

在那个页面里，也有人提供了自己修复此BUG的方法：
1，来到PHP安装目录内的bin目录下

cd /usr/local/php-5.2.3/bin

2，下载这个模块的源码

pecl download sqlite

3，解压并开始编译

$ tar zxvf SQLite-1.0.3.tgz
$ cd SQLite-1.0.3
$ ../phpize
$ ./configure –with-php-config=/usr/local/php-5.2.3/bin/php-config
$ make

4，在make的过程如报告以上错误则编辑sqlite.c文件，将下面这行注释掉

/* static unsigned char arg3_force_ref[] = {3, BYREF_NONE, BYREF_NONE, BYREF_FORCE }; */

然后将下面这三行

function_entry sqlite_functions[] = {
PHP_FE(sqlite_open, arg3_force_ref)
PHP_FE(sqlite_popen, arg3_force_ref)

改为:

function_entry sqlite_functions[] = {
PHP_FE(sqlite_open, third_arg_force_ref)
PHP_FE(sqlite_popen, third_arg_force_ref)

5，重新编译

$ make
$ make install

将编译生成的sqlite.so文件，复制到extension_dir指定的目录中，编辑php.ini文件，加入如下一行

extension=sqlite.so

重启web服务后即可

1，Install Pcre

来这里获取Pcre的最新版本
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/

#tar -zxf pcre-7.8.tar.gz
#cd pcre-7.8
#./configure
#make
#make install

2. Install Nginx(http://www.nginx.net/)

#tar -zxf nginx-0.6.32.tar.gz
#cd nginx-0.6.32
#./configure –prefix=/usr/local/nginx-0.6.32
#make
#make install

3. Install PHP with php-fpm (http://www.php.net/)

nginx是通过fastcgi来支持PHP的，使用php-fpm补丁是一个比较方便的管理fastcgi进程的解决方案。
比通过脚本或是lighttpd的spawn模块要简单的多。

下载好PHP后，来这里获取与PHP版本相对应的php-fpm补丁：http://php-fpm.anight.org/

#tar -zxf php-5.2.6.tar.gz
#cd php-5.2.6
#zcat ../php-5.2.6-fpm-0.5.8.diff.gz | patch -p1  #为PHP打补丁
#./configure –prefix=/usr/local/php-5.2.6 –with-sqlite=shared –enable-fastcgi –enable-fpm
#make
#make install
注：PHP的其他模块(如mysql、gd等)请按需自己配置

#cp php.ini-recommended /usr/local/php-5.2.6/lib/php.ini

修改php.ini

cgi.fix_pathinfo=1

4. Configuring

A. 配置nginx，在/usr/local/nginx-0.6.32/conf目录下新建名为php_fcgi.conf的文件，内容如下：

location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

修改nginx.conf文件，在需要支持PHP的虚拟主机配置中，加入如下一行：

include php_fcgi.conf;

B. 配置php-fpm模块，编辑/usr/local/php-5.2.6/etc/php-fpm.conf文件
找到“Unix user of processes”和“Unix group of processes”两段，将前面注释去掉，并将值改为与nginx配置相同的用户和组。如下：

Unix user of processes
<value name=”user”>www</value>

Unix group of processes
<value name=”group”>www</value>

5. Test and Over

至此，所有安装配置的工作都已经完成。运行下面两行命令来启动nginx和php-fpm服务：

/usr/local/php-5.2.6/sbin/php-fpm start
/usr/local/nginx-0.6.32/sbin/nginx

正确配置后，phpinfo() 页应如下显示：

CGI/FastCGI work as Server API

由于文件内容太长，nginx.conf和虚拟主机的配置文件的内容就不放上来了
将这些乱七八糟的配置文件和php-fpm.conf一起打个包，放在这里提供下载吧

http://rui7905.googlecode.com/svn/trunk/nginx_php_fpm

在这一堆东西里，还有一个名为nginx.sh的启动控制脚本。
当确认nginx和php-fpm均正确的配置并可以正常运行后，可以使用此脚本进行日常维护。

1.如果一个方法可静态化，就对它做静态声明。速率可提升至4倍。

2.echo 比 print 快。

3.使用echo的多重参数（译注：指用逗号而不是句点）代替字符串连接。

4.在执行for循环之前确定最大循环数，不要每循环一次都计算最大值。

5.注销那些不用的变量尤其是大数组，以便释放内存。

6.尽量避免使用__get，__set，__autoload。

7.require_once()代价昂贵。

8.在包含文件时使用完整路径，解析操作系统路径所需的时间会更少。

9.如果你想知道脚本开始执行（译注：即服务器端收到客户端请求）的时刻，使用$_SERVER[‘REQUEST_TIME’]要好于time()。

10.函数代替正则表达式完成相同功能。

11.str_replace函数比preg_replace函数快，但strtr函数的效率是str_replace函数的四倍。

12.如果一个字符串替换函数，可接受数组或字符作为参数，并且参数长度不太长，那么可以考虑额外写一段替换代码，使得每次传递参数是一个字符，而不是只写一行代码接受数组作为查询和替换的参数。

13.使用选择分支语句（译注：即switch case）好于使用多个if，else if语句。

14.用@屏蔽错误消息的做法非常低效。

15.打开apache的mod_deflate模块。

16.数据库连接当使用完毕时应关掉。

17.$row[‘id’]的效率是$row[id]的7倍。

18.错误消息代价昂贵。

19.尽量不要在for循环中使用函数，比如for ($x=0; $x < count($array); $x)每循环一次都会调用count()函数。

20.在方法中递增局部变量，速度是最快的。几乎与在函数中调用局部变量的速度相当。

21.递增一个全局变量要比递增一个局部变量慢2倍。

22.递增一个对象属性（如：$this->prop++）要比递增一个局部变量慢3倍。

23.递增一个未预定义的局部变量要比递增一个预定义的局部变量慢9至10倍。

24.仅定义一个局部变量而没在函数中调用它，同样会减慢速度（其程度相当于递增一个局部变量）。PHP大概会检查看是否存在全局变量。

25.方法调用看来与类中定义的方法的数量无关，因为我（在测试方法之前和之后都）添加了10个方法，但性能上没有变化。

26.派生类中的方法运行起来要快于在基类中定义的同样的方法。

27.调用带有一个参数的空函数，其花费的时间相当于执行7至8次的局部变量递增操作。类似的方法调用所花费的时间接近于15次的局部变量递增操作。

28.用单引号代替双引号来包含字符串，这样做会更快一些。因为PHP会在双引号包围的字符串中搜寻变量，单引号则不会。当然，只有当你不需要在字符串中包含变量时才可以这么做。

29.输出多个字符串时，用逗号代替句点来分隔字符串，速度更快。注意：只有echo能这么做，它是一种可以把多个字符串当作参数的“函数”（译注：PHP手册中说echo是语言结构，不是真正的函数，故把函数加上了双引号）。

30.Apache解析一个PHP脚本的时间要比解析一个静态HTML页面慢2至10倍。尽量多用静态HTML页面，少用脚本。

31.除非脚本可以缓存，否则每次调用时都会重新编译一次。引入一套PHP缓存机制通常可以提升25%至100%的性能，以免除编译开销。

32.尽量做缓存，可使用memcached。memcached是一款高性能的内存对象缓存系统，可用来加速动态Web应用程序，减轻数据库负载。对运算码 (OP code)的缓存很有用，使得脚本不必为每个请求做重新编译。

33. 当操作字符串并需要检验其长度是否满足某种要求时，你想当然地会使用strlen()函数。此函数执行起来相当快，因为它不做任何计算，只返回在zval 结构（C的内置数据结构，用于存储PHP变量）中存储的已知字符串长度。但是，由于strlen()是函数，多多少少会有些慢，因为函数调用会经过诸多步骤，如字母小写化（译注：指函数名小写化，PHP不区分函数名大小写）、哈希查找，会跟随被调用的函数一起执行。在某些情况下，你可以使用isset() 技巧加速执行你的代码。

（举例如下）
if (strlen($foo) < 5) { echo “Foo is too short”; }
（与下面的技巧做比较）
if (!isset($foo{5})) { echo “Foo is too short”; }

调用isset()恰巧比strlen()快，因为与后者不同的是，isset()作为一种语言结构，意味着它的执行不需要函数查找和字母小写化。也就是说，实际上在检验字符串长度的顶层代码中你没有花太多开销。

34. 当执行变量$i的递增或递减时，$i++会比++$i慢一些。这种差异是PHP特有的，并不适用于其他语言，所以请不要修改你的C或Java代码并指望它们能立即变快，没用的。++$i更快是因为它只需要3条指令(opcodes)，$i++则需要4条指令。后置递增实际上会产生一个临时变量，这个临时变量随后被递增。而前置递增直接在原值上递增。这是最优化处理的一种，正如Zend的PHP优化器所作的那样。牢记这个优化处理不失为一个好主意，因为并不是所有的指令优化器都会做同样的优化处理，并且存在大量没有装配指令优化器的互联网服务提供商（ISPs）和服务器。

35.并不是事必面向对象(OOP)，面向对象往往开销很大，每个方法和对象调用都会消耗很多内存。

36.并非要用类实现所有的数据结构，数组也很有用。

37.不要把方法细分得过多，仔细想想你真正打算重用的是哪些代码？

38.当你需要时，你总能把代码分解成方法。

39.尽量采用大量的PHP内置函数。

40.如果在代码中存在大量耗时的函数，你可以考虑用C扩展的方式实现它们。

41.评估检验(profile)你的代码。检验器会告诉你，代码的哪些部分消耗了多少时间。Xdebug调试器包含了检验程序，评估检验总体上可以显示出代码的瓶颈。

42.mod_zip可作为Apache模块，用来即时压缩你的数据，并可让数据传输量降低80%。

43.另一篇优化PHP的精彩文章，由John Lim撰写。

在PHP手册中，关于session_set_save_handler()有一个警告

As of PHP 5.0.5 the write and close handlers are called after object destruction and therefore cannot use objects or throw exceptions. The object destructors can however use sessions.It is possible to call session_write_close() from the destructor to solve this chicken and egg problem.

意思是而从PHP5.0.5开始，write和close处理函数的调用，是在所有对象被destruct之后的，这样就无法在这两个方法中使用对象和错误捕获了。从php5.0.5开始，在定制session保存方式时，就必须得用到session_write_close()了。

简单写了个使用memcache保存session数据的类，改成其他方式保存也是很简单的事。不过如果存在数据库中，是需要对数据进行一些处理的。memSession.rar

在这里顺便提一下PHP.net网站上的手册。跟下载到本地的chm不同，网站的手册，每个函数说明页面的下面，基本都有一大堆的note。这些note，都是大家在使用这个函数时遇到问题后的解决方法，或者是更深一层应用的扩展。其中的亮点很多，有时候都晃眼。比如在这个session_set_save_handler函数下面的notes中，就有使用NFS，Mysql，LDAP等保存session的代码。在php.net上查手册，有时候看notes比看函数说明更能让人明白函数的用法。所以，玩PHP，对于自己陌生的函数，只要能上网，严重推荐上php.net查手册。

行了，广告做完，洗洗睡了。