无可置疑的,写 CGI 的方式有很多种,而 PHP 只是其中的一种选择罢了。对资深的 Webmaster 而言,CGI 的写作界面应是随着需求而改动。毕竟,在一个对系统反映速度要求极严格的系统而言,恐怕只有 NSAPI 界面写的 CGI 程序才能符合要求了。在其它的场合,相信使用 PHP 来作为 CGI 的界面是游刃有余,而且是最适合的。
程序界面 | PHP | ASP | CGI | NSAPI | ISAPI |
操作系统 | 均可 | Win32 | 均可 | 均可 | Win32 |
Web服务器 | 数种 | IIS | 均可 | Netscape Server | IIS |
执行效率 | 快 | 快 | 慢 | 极快 | 极快 |
稳定性 | 佳 | 中等 | 最高 | 差 | 差 |
开发时间 | 短 | 短 | 中等 | 长 | 长 |
修改时间 | 短 | 短 | 中等 | 长 | 长 |
程序语言 | PHP | VB | 不限 | C/C++ | C/ Delphi |
网页结合 | 佳 | 佳 | 差 | 差 | 差 |
学习门槛 | 低 | 低 | 高 | 极高 | 高 |
函数支持 | 多 | 少 | 不定 | 中等 | 少 |
系统安全 | 佳 | 极差 | 最佳 | 佳 | 尚可 |
使用网站 | 超多 | 多 | 多 | 极少 | 少 |
改版速度 | 快 | 慢 | 无 | 慢 | 慢 |
其中的 PHP 可用在数种 Web 服务器上;传统 CGI 就不限是哪种操作系统或 Web 服务器平台;NSAPI 一定要在 Netscape 的服务器 (如 Netscape Enterprise Server 或 FastTrack Server) 上才可以执行,但可支持多种操作系统 (UNIX 或 Win32);ASP 及 ISAPI 只在 IIS 上有完整的功能。
在稳定性上,由于 NSAPI 或 ISAPI 是动态链接的方式,因此在执行若出现问题,会使得 Web 服务器一起瘫痪。而 ASP 在我实际应用经验上,隔阵子就会使系统不稳定,需要重新启动操作系统。PHP 在许多的网站使用上,不但长期使用都没有问题,而且程序的稳定性也不错。当然最稳的还是传统 CGI 程序,因为它是由操作系统负责控制,不会因 CGI 程序的错误导致 Web 服务器的不稳定。
在开发及维护时间上,PHP 及 ASP 都有不错的表现。而 NSAPI 及 ISAPI 则需要长时间的开发过程,在稳定上线后,这两种界面反倒是效率最佳的方法。传统的 CGI 程序则要视开发工具语言而定了,用 Perl 或是 shell script 不需要编译的过程,直接就可以执行,若用 Delphi 或 VC/BCB 甚至用组合语言等都要经过编译才能执行,至于用 VB 来写传统 CGI,唉....。
要比较和网页结合的能力,PHP 和 ASP 是并驾齐驱的,其它的方式就不能内嵌 HTML 语法了。而这也是影响开发时间的因素之一。
就系统安全性而言,ASP 是最差的,在没有经过微软的 IIS Service Pack 处理过,使用 ::$DATA 就可以看到 ASP 的源代码,这真是叫人不敢领教。当然,传统 CGI 的程序,由于是由操作系统直接管理,要破解的难度最高,黑客必须由操作系统下手,而不能由 Web 服务器下手。PHP 在许多商业及非商业使用时,也没有听过有什么安全的问题。
在新增功能及改版方面,传统的 CGI 由于不受任何语言限制,没有这方面的问题。PHP 是最有活力的,数天至数周就有一个新版本出现,每次的新版,就代表更多的功能及修正更多的错误。其它的 ASP、NSAPI、ISAPI 就视它的 Web 服务器改版速度了,ASP 要等到 IIS 5.0 出现时才会有 ASP 3.0,也就是要等到 Windows 2000 正式上市。
总而言之,在 Web 的后端 CGI 程序,就像鱼与熊掌一般,没有高效率又开发方便的选择。不过相信 PHP 是处于开发容易、效率也不错的平衡点上。 字串9
在开发及维护时间上,PHP 及 ASP 都有不错的表现。而 NSAPI 及 ISAPI 则需要长时间的开发过程,在稳定上线后,这两种界面反倒是效率最佳的方法。传统的 CGI 程序则要视开发工具语言而定了,用 Perl 或是 shell script 不需要编译的过程,直接就可以执行,若用 Delphi 或 VC/BCB 甚至用组合语言等都要经过编译才能执行。