同步 Claws Mail 的回收站到邮件服务器

Gmail 依然是经常抽风,没办法了,只好弄个客户端用, 至少工作的时候用起来比较方便,不用老是等待、重试。

我的使用模式比较复杂,简单描述如下: 工作邮箱主要从 Web 和 Mutt 客户端访问, 主要作用一个是搜索浏览,一个是存档。 所有邮件还会自动转发到另外一个个人邮箱, 这个邮箱使用 Claws Mail 客户端下载,本地管理。 日常工作中,以个人邮箱的客户端为主, 工作邮箱的 Web 界面为辅。

这篇文章所解决的问题就是, 在 Claws Mail 客户端中删除邮件后, 实现这些邮件在上述两个邮箱中也删除到回收站。 用于处理一些垃圾邮件和确定不再需要的正常邮件。

如果用 IMAP 客户端来管理可以达到同样效果, 但我的邮件比较多, IMAP 太慢了,动不动就要刷新上千封邮件信息, 耗不起。

闲话扯完,下面来讲处理思路和一些心得, 希望直接找结果的请猛击 imap-del-for-mh.php ,运行环境中需要包含 Fwlib

  1. 定位邮件文件

    Claws Mail 使用 MH 格式存储邮件, 一封邮件对应一个文件, 一个目录就对应 Claws Mail 中的一个目录, 结构非常清晰。

  2. 连接邮件服务器

    由于邮件都已经使用 POP3 方式下载过了, 所以这里只能采用 IMAP 方式连接了(不然列不出邮件)。 连接 Gmail 不敢说快,倒也能够接受。

  3. 解析邮件文件,找出用于在服务器上定位邮件的必要信息

    读文件,用正则。 IMAP 中查找邮件所用时间是 d-M-Y ,减号可以省略, 比如 11-May-2013 或者 11 May 2013 。 From 和 Subject 中可能会有非英文字符,需要进行转码。 Message-ID 应该是邮件的唯一标识, 但不是是否因为其包含了部分隐私信息的原因, IMAP 服务器没法依据它来检索邮件。

  4. 第一次查找、比对邮件

    由于 IMAP 并没有提供准确查找、定位邮件的方法, 所以只能按照各种条件来检索邮件, 然后一封封的检查 Message-ID, 看与本地邮件文件中是否一致。

    第一次查找邮件使用 From 发件人和 Date 邮件时间, 尝试过使用 Subject 邮件标题, 反正有可能搜索不到, 原因大概是无法依据其中的中文进行模糊匹配。 From 也是只使用 <> 尖括号以内的部分,更准确。 Date 检索条件稍微麻烦一点,PHP 文档中有 ON date 方法, 但实际没法用,所以使用的是 SINCE [前一天] BEFORE [后一天] 。 由于无论怎么检索都无法匹配, 转而寻找“一定”包含指定邮件的最小结果集。

    这种方式能够匹配到大部分正常发送的邮件。

  5. 第二次查找、比对邮件

    一些不正常邮件,尤其以各类垃圾邮件为代表, 存在着信息不全、时间不对等稀奇古怪的问题, 所以如果第一次没有找到,再换条件补查一次。 这次使用的是邮件头中的 Recieved 接收时间, 这是邮件服务器接收到这封邮件的时间, 然后以这个时间为基准, 在 前一天、后一天 的范围内查找邮件、逐一匹配。 虽然速度要慢一些, 但理论上所有邮件采用这种方式都能找到。

  6. 删除邮件

    通过 Message-ID 匹配准确定位到邮件后, 便得到了邮件的 UID。 UID 和 msgid 是不同的,msgid 是在某一目录或者列表下的序号, 而 UID 才是 IMAP 下邮件的唯一编号。 不过邮件被删除到回收站,再从回收站恢复的时候, UID 也是会改变的。

    Gmail 的 IMAP delete 操作和一般的“删除”含义并不同, 只是把邮件从 Inbox 中去除了,跑到 All Mails 里面了, 所以把邮件先 move 到 trash 目录下,再进行 delete, 最后执行 expunge 操作。

最后回想一下,如果一次性把所有邮件头都读取出来, 再和本地的 Message-ID 进行对应, 在需处理邮件相当多的情况下应该会有总体效率的提升, 但不适用于我这个场景

如果 IMAP 能够直接使用 Message-ID 来精确匹配, 那就省事多了。

-EOT-

一直在忙,聊以凑数。

参考

PHP foreach 中使用引用的注意事项

问题

先看一个例子:

<?php
$ar = array(1, 2, 3);
var_dump($ar);
foreach ($ar as &$v) {}
foreach ($ar as $v) {}
var_dump($ar);
?>

输出为:

array(3) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  int(3)
}
array(3) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  &int(2)
}

???为什么没有进行赋值操作,数组最后一个元素的值却发生了改变呢?

我早就发现了这个问题,一开始以为是 PHP 的 bug,就扔着没管它, foreach 中不使用引用就没事, 用 foreach $k => $v 然后 $ar[$k] 来改变原始数组, 略微损失点效率。

分析

今天花了点时间,看了 参考 中的文章, 算是稍微明白一点了,原来是这个样子的:

在执行第一个使用引用的 foreach 时, 一开始, $v 指向 $ar[0] 的存储空间,空间内存储着 1 , foreach 结束时, $v 指向 $ar[2] 的存储空间,空间内存储着 3 。 下面要开始执行第二个 foreach 了,注意和第一个 foreach 不同, 第二个 foreach 没有使用引用,那么就是赋值方式, 即将 $ar 的值依次 赋值$v 。 进行到第一个元素时,要将 $ar[0] 赋值给 $v 。 问题就在这里,由于刚刚执行完第一个 foreach, $v 不是一个新变量,而是已经存在的、指向 $ar[2] 的那个 引用 , 如此一来,对 $v 进行赋值的时候,就将 $ar[0] = 1 写入了 $ar[2] 的实际存储空间, 相当于对 $ar[2] 进行赋值。 依此类推,第二个 foreach 执行的结果, 就是数组的最后一个元素变成了倒数第二个元素的值。 参考文章 2 中有详细的示意图。

如果说这是一个错误,那么错误的原因就在于对引用变量的使用。 当引用变量指向和其他变量时,改变引用变量的值当然会影响到他指向的其他变量。 单独说谁都明白,但在这个 foreach 例子中,凑巧了, 同一个变量两次被使用,前一次是引用的身份,后一次是普通变量身份, 就产生了意料之外的效果。 PHP 的开发者也认为,这种情况属于语言特性造成的,不是 bug。 的确,如果要修复这个问题,一种方法是对 foreach 进行特殊处理之外, 另外一种就是限制 foreach 中 $v 的作用域, 这两种方式都与目前 PHP 的语言特性不符,开发人员不愿改, 但还是在 官方文档 中用 Warning 进行了说明。

解决方法

简单,但谈不上完美,就是在使用了引用的 foreach 之后, unset 掉 $v , 开始的例子改为:

<?php
$ar = array(1, 2, 3);
var_dump($ar);
foreach ($ar as &$v) {}
unset($v);
foreach ($ar as $v) {}
var_dump($ar);
?>

运行结果:

array(3) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  int(3)
}
array(3) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  int(3)
}

Curl奇怪的403错误

自己用的小PHP应用,使用curl抓网页下来处理,为了穿墙方便,使用Privoxy作为代理,便于选择哪些网站使用proxy、哪些不用。但今天却遇到了奇怪的问题,访问google baidu这些网站居然都返回403错误,而访问其他的一些网站没事,如果设置为不使用proxy则都能正常访问。

难道google baidu就不让用proxy连接么?显然不可能,所以打开curl的信息输出(curl_setopt($this->mSh, CURLOPT_VERBOSE, 1);)看看,得到以下结果:

*   Trying 127.0.0.1... * connected
* Connected to 127.0.0.1 (127.0.0.1) port 8118 (#0)
* Establish HTTP proxy tunnel to www.baidu.com:80
> CONNECT www.baidu.com:80 HTTP/1.0
Host: www.baidu.com:80
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Proxy-Connection: Keep-Alive

< HTTP/1.0 403 Connection not allowable
< X-Hint: If you read this message interactively, then you know why this happens ,-)
< 
* The requested URL returned error: 403
* Received HTTP code 403 from proxy after CONNECT
* Closing connection #0
... Failed.

可以看到proxy服务器工作正常,的确是baidu返回了403错误,但原因肯定还在我这边。终于,从网上(1of2, 2of2)得到了点启发──我使用的是proxytunnel而非proxy。

在代码中,有这么一句:

	curl_setopt($this->mSh, CURLOPT_HTTPPROXYTUNNEL, true);
	curl_setopt($this->mSh, CURLOPT_PROXY, $phost);

php文档中没有详细说明,不过man curl中有详细解释,两者都是代理,proxytunnel(-p参数)允许其他协议通过http代理传输,而proxy(-x参数)则只能走http协议。所以我猜测,google baidu的服务器和curl的proxytunnel不和,所以返回403。

禁用掉上面2行代码的第一句后,curl访问恢复正常。

比较奇怪的是,几种操作系统下还不一样,一台MAC OSX就要显式的禁用proxytunnel才可以,curl版本:

$ curl --version
curl 7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IPv6 Largefile NTLM SSL libz 

而另外一台ubuntu则完全不受影响,怎么都能用,curl版本:

$ curl --version
curl 7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

MT主机上的centos也没事,curl版本:

$ curl --version
curl 7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

看来不完全是curl版本问题,MAC OSX的确与众不同啊。

还有一个原因也会导致curl返回403错误,如果设置了:

	curl_setopt($ch, CURLOPT_NOBODY, true);

则需要紧跟着设置:

	curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'GET');

不然会因为http服务器不允许 HEAD 命令而返回403错误。参考:Trouble with a cURL request in PHP。MAC OSX上curl之所以特殊,也不排除是这种原因吧。

配置安全的共享web服务器(抛砖引玉)

本文所讲的共享web服务器,并非共享文件的服务器,而是多人一起使用的web服务器,各有各自的网站、管理自己的文件,互不干涉,且对系统无影响。鉴于功力较浅,只敢对较信得过的朋友开放这种账号,本文涉及的范围也有限,所以安全漏洞可能还有,请诸位切勿直接用于生产环境。

服务器环境:Ubuntu 8.10, OpenSSH_5.1p1 Debian-3ubuntu1, Apache 2.2.9, PHP 5.2.6-2ubuntu4

登录 – SFTP

传统的 FTP 肯定是不如这个安全,telnet 更不用说了。使用 SFTP 还有一个起始想法是想配置证书自动登录,后来发现 SFTP 客户端(FileZilla)没这功能,就没再作下去,命令行下 scp 的自动登录倒是 和 ssh 的一样很好配置。

网上很多文章介绍把 sftp 用户限制在 $HOME 目录下的方法,使用的是 sshd 的 ChrootGroups 选项,这个选项在我的版本里没有找到,找到另外一篇参考文章使用的是 ChrootDirectory,也很好用。

创建一个用户组,作为所有 sftp 用户的用户组:

$ sudo groupadd sftp

创建用户,设置密码,并归入 sftp 组:

$ sudo useradd -m friend
$ sudo passwd friend
$ sudo usermod -g sftp friend

为了进一步增强安全性,还可以将用户的登录 shell 设置为 /bin/false,是个好习惯,但在本例中并非必须,下面的 sshd 设置也会让用户无法登录 shell (我观察的结果)。

$ sudo usermod -s /bin/false friend

下来就要配置 sshd 了,编辑配置文件 /etc/ssh/sshd_config

# 修改下面这句
#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

然后在此配置文件末尾添加:

Match group sftp
    X11Forwarding no
    ChrootDirectory %h
    AllowTcpForwarding no
    ForceCommand internal-sftp

配置含义大概为:凡是 sftp 组的用户,关闭 X 转发,chroot 到 $HOME 目录,关闭 TCP 转发(无法使用隧道了?),强制使用 internal-sftp(这个不明白)。

现在,重启 ssh 服务,用户就只能通过 sftp 访问 /home/friend 下的文件了。

PS: 我发现 sshd 如果配置错误,在 restart 服务的时候会先检查,而不是直接 stop 服务然后在 start 的时候出现错误,搞得服务启不来。大概是考虑到很多人都是远程 ssh 上来进行维护,服务 down 了以后就麻烦了,很贴心的设置。

Apache & PHP

Apache 配置简单,创建 /home/friend/www 目录,约定网站文件都放在这个目录下,然后弄个 Alias 指向就可以了。

但有一个极大的安全隐患需要堵上,用户可以通过编写 PHP 程序,读取系统中任何 www-data 用户有权限访问的文件,包括系统的 shadow 文件,包括 其它用户的网站文件等等。解决这个问题,一种是开启 PHP 的 safe_mode ,安全模式下 PHP 将只能访问 owner 为自己(也就是 www-data)的文件;另外一种是使用 open_basedir,这将限制 PHP 只能打开某一目录树下的文件,并且不可能通过符号链接避开此限制。显然 safe_mode 的副作用太多,后一种方法更适合我的这种情况,配置写到 Apache 的 conf 里就行了:

<Directory /home/friend>
    php_admin_value open_basedir "/home/friend/"
</Directory>

注意open_basedir 后面的参数只代表文件路径的前缀,所以要带上末尾的斜杠,明确指出是目录。

不使用 safe_mode 的另外一个原因是在未来的 PHP6 里就要删掉它了。

缺点

最大的缺点就是 sftp 用户无法自己更改密码,除非自己写个守护程序啥的。这个程序在写的时候要非常小心,因为操作的是系统用户文件,如果遗留有安全漏洞可能会使别人获得其它用户权限。一个折中的方法是写个程序,定期更改密码并通过邮件告知用户,虽不方便但安全性要好一些。

小巧的编辑器Geany

我对PHP编辑器的要求不高,不过很多软件却不合我意:

首先,最好是免费的,所以挺好用的Zend Studio落选了。并且我发现似乎Zend Studio与ibus或者ubuntu jaunty有点冲突,有时候中文就出不来了。

其次,小巧,java的最好不要,所以Eclipse也落选了。

最后,最小功能集:语法高亮(废话)以及类函数列表(可以帮助我快速定位)。就这两项功能,淘汰了gedit(支持得不好)、vim(无法列出类函数)等工具。

当然,隐含要求,支持中文输入法,所以gphpedit也不能用,正好也不喜欢它的颜色高亮模式(色彩搭配)。

所以,选来选去,今天才算碰到一个比较满意的────Geany,ubuntu源中有,目前版本0.14,看来开发历史并不长。使用gtk2,操作流畅。除了类函数列表以外,还有一些贴心的小功能,比如自动补齐文件末尾的空行、保存时自动删除行尾空格等。

geany screenshot

默认的,Geany的快捷键Complete Word与中文输入法冲突,还好,可以通过设置删掉:双击-->Del-->回车

geany-solve-conflict-with-input-method

可怜的gphpedit也是这种快捷键冲突,不过我没找到设置方法。

其实Geany不仅能够处理PHP文件,还能够编辑多种脚本文件,新建文件时有内置模板可选,能够自动生成文件头的copyright及GPL声明。

总之,到目前的感觉,挺好用的。

Update @ 2009-12-29

ubuntu 中 geany 的版本更新较慢,喜欢追新的可以自行添加它的 PPA源

在GLPI中输出中文PDF文件

PDF,好东西,就是麻烦,以前鼓捣ThingkingRock的时候打过交道,感觉挺复杂,现在捣鼓GLPI时又遇到了,GLPI用的是ezpdf。

先说点闲话,有些比较偏门的东西是真难找啊,比如今天要说的,算不上是学术问题,也没有企业级的支持(如果你愿意打电话咨询GLPI官方又懂法语我没话说),只能在网上大海捞针的找,一方面这是很辛苦的,查阅各类资料几十篇(前提还是你得能找到),写下来也就寥寥百余字,所以我一般愿意把我翻到的资料列在后面作为参考,或许能为别人省点力气;另一方面就是搜索引擎的功劳了,记得还没有google和百度的时候,只有一个yahoo分类目录,要搜问题就得到几个大型论坛比如CSDN里去翻,信息量就窄多了,另外搜索引擎的质量在这里也起到了很大的作用,信息重复率高不高、能否最快速度找到原创内容、信息关联度、是否有用等因素都关系到用户花费时间的多少,这也是我很少用百度的原因之一,还有就是感觉百度的英文资料差太多了。────谨以此纪念我几乎24小时的连续工作以及疲惫的眼睛和脖子。

EZPDF

EZPDF一般是不支持unicode多字节编码的,不过还是作了一些尝试,毕竟是GLPI内置的,搞定了用着方便。首先EZPDF使用afm字体,要得到afm字体,需要用到ttf2tex,在pdfTeX包里:

	$ aptitude install ttf2tex

转换字体,这次我不用宋体了,用于打印的,还是仿宋看着舒服,用了个方正仿宋简体:

	$ ttf2afm -e T1-WGL4.enc -o fzfangsong.afm fzfangsong.TTF

试了试不能用,然后用afm2font处理:

	$ php5 afm2font.php fzfangsong

得到php_fzfangsong.font等文件,但这些文件无论怎么套上ezpdf都是不行,什么文字都没了,pdf文件中倒是显示了正确的字体名:

fzfangsong
Type1
Not embedded

再在网上翻资料,简直就是钻到TeX用户堆儿里去了,忽然发现windows字体应该是TrueType字体,而ezpdf使用的难道是Type1字体,两者之间还需要转换?终于查到基于texlive2008的中文绿色免安装tex系统中有打包的字体,这里面有给TeX用的Type1字体,就是大了点,“dottexlive2008.tar.bz2 仅包含全部字体包和相关宏包”一共是685M,拉下来,好在网速还算很快。把里面的afm字体单独解压出来:

	$ tar xjvf /big1/dottexlive2008.tar.bz2 .texlive2008/texmf-var/fonts/afm/
	$ cd .texlive2008/texmf-var/fonts/afm/cjk/gbkfs
	$ cat gbkfs??.afm > gbkfs.afm

拿这个gbkfs.afm配置到ezpdf里,能打出字来了,但中文还是问号,估计是因为数据是utf-8编码,而字体是gbk编码的?修改class.ezpdf.php,在function ezProcessText的第一行加上(参考:ezpdf打印德文的处理):

	$text = mb_convert_encoding($text, 'gbk', 'utf-8');

还是问号,难道字体要嵌入pdf才行?

结果又查到一篇Choosing a PHP PDF generation library for Dokeos,说ezpdf根本、确实、100%就不支持utf-8编码,合着白折腾了。

ezpdf官网确认一下,最近的新闻是17 June 2006的,比上面那篇文章还晚,看来ezpdf确实是没法用了。用tcpdf吧,不过在glpi的roadmap里,换上tcpdf是要在0.80实现的,前面还有100+ ticket没完成,也是遥遥无期啊,只好自己动手,丰衣足食了。

TCPDF

从官网下载tcpdf放到php的include路径下,对照字体设置方法来准备字体:

	$ cd tcpdf/fonts
	# Simsun字体好像还不是truetype(嵌入了点阵字体),转换有些问题,先拿方正字体来用,正好方正仿宋简体打印用更好看
	#$ ln -s /big2/fonts/xpfonts/simsun.ttf
	# 注意文件名转为小写
	$ ln -s /big2/fonts/fzfont/fzfangsong.TTF fzfangsong.ttf
	$ utils/ttf2ufm -a -F fzfangsong.ttf 
	# 生成了3个新文件
	$ ls
	fzfangsong.ufm fzfangsong.t1a fzfangsong.afm	
	# 我选的这个方正字体应该是TrueTypeUnicode字体,用TrueType转的不显字
	# 文中有说明,在ttf ufm后面还可以跟参数,这里的false代表不将字体嵌入PDF文档,
	# 那样会使pdf文件大小增大为自身+字体文件大小,很恐怖的
	$ php5 -q utils/makefont.php fzfangsong.ttf fzfangsong.ufm false
	# 生成可用的文件了
	$ls
	fzfangsong.z fzfangsong.php

现在弄个简单的例子,能够用tcpdf输出pdf文件了,里面要有这么一句:

	$pdf->SetFont('fzfangsong', '', 16);

现在文件尺寸还是太大,因为字体依然是全嵌入的(如果是embedded subset更好,不过TCPDF现在还做不到)。按照那篇文章修改fzfangsong.php文件:

	//$type='TrueTypeUnicode';
	$type='cidfont0';
	...
	//$dw=600;
	$dw=1000;
	...
	//$enc='';
	$diff='';
	//$file='fzfangsong.z';
	//$ctg='fzfangsong.ctg.z';
	$originalsize=3548232;
 
	// Chinese Simplified
	$enc='UniGB-UTF16-H';
	$cidinfo=array('Registry'=>'Adobe', 'Ordering'=>'GB1','Supplement'=>2);
	include(dirname(__FILE__).'/uni2cid_ag15.php');

现在生成的pdf文件尺寸倒是很小了,但用eivnce看文字全部是空白,这是在Linux下看,跑到windows下看正常,而且完美,gb和big5编码都能显示。又用其它一些字体试了试,都是windows正常但linux下看不了,应该是刚才作的步骤正确,但与平台配合起来还欠点什么。

仔细对比了上面生成的两种pdf文件,以及另外一个用openoffice.org生成的pdf文件(这个应该比较标准吧),发现还是openoffice.org生成的文件又小、效果又好,用的是“已嵌入子集/embedded subset”方式,

最终查到,我基本上已经作好了,问题出在evince身上,安装poppler-data包(evince用这个来处理中文)后,完美解决,字体为非嵌入not embedded方式。生成的pdf文件非常小,用windows和evince浏览也都正常。混合gb2312和big5编码的内容也没问题:evince下中文出西欧字符不出,windows下Adobe Reader只出gb2312的字,Foxit Reader全部中文和西欧字符完美。而在全内嵌字体的情况下,用evince查看big5字符都是小黑块。

hack GLPI

接下来是大工程,把ezpdf换成tcpdf。修改inc/export.function.phpfunction displaySearchFooter函数,把case PDF_OUTPUT_LANDSCAPEcase PDF_OUTPUT_PORTRAIT两部分的内容都换成TCPDF的处理,源数据还借用原来的$PDF_HEADER,$PDF_ARRAY。除了纸张参数不一样,两部分的处理是相同的,下面是一个简单的例子:

	// --------
	require_once('tcpdf/tcpdf.php');
	global $PDF_HEADER,$PDF_ARRAY;
 
	// create new PDF document
	$pdf = new TCPDF('L', PDF_UNIT, PDF_PAGE_FORMAT, true, 'UTF-8', false); 
 
	// set document information
	$pdf->SetCreator(PDF_CREATOR);
	$pdf->SetAuthor('Fwolf');
	$pdf->SetTitle($title);
	$pdf->SetSubject('GLPI Export');
	$pdf->SetKeywords('TCPDF, PDF, GLPI, export, fwolf, work, asset');
 
	// set header and footer fonts
	$pdf->setHeaderFont(Array(PDF_FONT_NAME_MAIN, '', PDF_FONT_SIZE_MAIN));
	$pdf->setFooterFont(Array(PDF_FONT_NAME_DATA, '', PDF_FONT_SIZE_DATA));
	// remove default header/footer
	$pdf->setPrintHeader(false);
	$pdf->setPrintFooter(true); 
 
	// set default monospaced font
	$pdf->SetDefaultMonospacedFont(PDF_FONT_MONOSPACED);
 
	//set margins
	$pdf->SetMargins(PDF_MARGIN_LEFT, PDF_MARGIN_TOP - 10, PDF_MARGIN_RIGHT);
	$pdf->SetHeaderMargin(PDF_MARGIN_HEADER);
	$pdf->SetFooterMargin(PDF_MARGIN_FOOTER);
 
	//set auto page breaks
	$pdf->SetAutoPageBreak(TRUE, PDF_MARGIN_BOTTOM);
 
	//set some language-dependent strings
	$pdf->setLanguageArray($l); 
 
	// ---------------------------------------------------------
 
	// add a page
	$pdf->AddPage();
 
	// Column width, by conteng max length
	$w_max = $pdf->getPageWidth() - PDF_MARGIN_LEFT - PDF_MARGIN_RIGHT;
	$w = array();
	foreach($PDF_ARRAY as $row) {
		foreach ($row as $i => $cell) {
			// Chinese utf8 2 words length=6, should be 4 here
			$cell = trim($cell);
			$l = mb_strwidth($cell, 'utf-8');
			// FZFangSong is not fixed font, so add some to en chars
			// eg: 哈哈abc
			// strlen = 6 + 3 = 9
			// mbstrlen = 5
			// mbstrwidth = 7
			$l += ($l + mb_strlen($cell, 'utf-8') - strlen($cell))
				* 0.3;
 
			if (!isset($w[$i])) {
				$w[$i] = $l;
			}
			elseif ($w[$i] < $l) {
				$w[$i] = $l;
			}
		}
	}
	// Compare with max width, maybe below 0
	$i = $w_max - array_sum($w);
	// Add back spaces left to each width
	$i = $i / count($w);
	foreach ($w as $k => $v) {
		$w[$k] = $v + $i;
	}
 
 
	// Table title
	$pdf->SetFont('fzfangsong', '', 14);
	$pdf->Write(0, '设备一览表', 0, 0, 'C', 1);
 
	// set font
	$pdf->SetFont('fzfangsong', '', 10);
 
	// Table header
	$pdf->SetFillColor(208, 220, 255);
	$pdf->SetTextColor(0);
	foreach ($PDF_HEADER as $i => $head) {
		$pdf->Cell($w[$i], 7, $head, 1, 0, 'C', 1);
	}
	$pdf->Ln();
 
	// Rows
	$pdf->SetFillColor(224, 235, 255);
	$pdf->SetTextColor(0);
	$fill = 0;
	foreach($PDF_ARRAY as $row) {
		foreach ($row as $i => $cell) {
			$pdf->Cell($w[$i], 6, $cell, 'LR', 0, 'L', $fill);
		}
		$pdf->Ln();
		$fill=!$fill;
	}
	$pdf->Cell(array_sum($w), 0, '', 'T'); 
 
	// ---------------------------------------------------------
 
	//Close and output PDF document
	$pdf->Output('glpi.pdf', 'I'); 
	return;
	break;

总体上这个例子是照着官网Colored Tables例子来的。

最后,把这个文件中所有的utf8_decode处理都去掉,完成。

参考

Update @ 2009-11-06

Print to pdf 的时候,Historical 中的 Comments 如何显示?默认的不好,可以考虑换成 diff 信息,如果又不愿用 pear 里的 xdiff,可以考虑它的前身──用 php 直接实现的 PHP inline diff