正文
关于cgi脚本的常见问题
在运行CGI脚本的时候，时常会出现一些小的烦人的问题。有时看起来似乎正确的脚本不会像预期那样工作，原因是某些小的隐藏问题很难被发现。
以下是一些潜在的问题：
-
Python脚本没有被标记为可执行的。当CGI脚本不能被执行时，大部分服务器不会运行它并发送结果给用户，反而是让用户来下载它。在类Unix系统中，要正确运行CGI脚本，需要设置
+
x
位（修改执行权限）。使用
chmod a
+
x your_script
.
py
可能会解决问题。
-
在类Unix系统中，编程文件行结束必须是Unix风格的。这相当重要，因为服务器会检查脚本文件的第一行(称为shebang)，并尝试运行那里指定的程序。如果是Windows的行结束(回车和换行Carriage Return&Line Feed, 所以称为CRLF)，服务器就很容易混淆。因而你要将文件转为Unix的行结束(只有换行Line Feed，LF)。在通过FTP上传文件时，选择文本模式而非二进制模式，转换就可以自动完成。但更好的方式是在编辑器中用Unix风格的行结束保存文件。目前大多数的编辑器都支持这一选项。
-
你的Web服务器必须能够读取文件，还要保证相关权限的正确。在类Unix系统中，服务器常在用户和用户组为
www
-
data
的状态下运行。所以可以试着去修改文件的所有权，或者用
chmod a
+
r your_script
.
py
命令将文件改为可读状态。
-
在类Unix系统中，shebang(#!/usr/bin/env python)中解释器的路径必须正确。这行代码在
/usr/
bin
/
python
中寻找Python，但如果该目录不存在或者路径不正确，查找都会失败。你如果知道你的Python安装在哪里，可以使用绝对路径。命令
whereis python
和
type
-
p python
都能帮助你找到它的安装位置。一旦你知道了正确的路径，你就可以相应地修改shebang:
#!/usr/bin/python
。
-
文件中不能包含BOM(Byte Order Mark)。使用BOM意味着使用UTF-16或UTF-32编码，但有的编辑器也将这些内容写进UTF-8编码的文件。BOM干扰了shebang一行，所以要确保你的编辑器不要将BOM写到文件中。
-
如果Web服务器在使用
mod_python
，
mod_python
可能会有问题。
mod_python
能够自己处理CGI脚本，但也能成为问题的源头。
mod_python
从PHP来的人经常很难抓住用Python进行Web开发的要领。他们第一时间想到的通常是
mod_python
，因为他们想
mod_python
等价于
mod_php
。事实上，它们之间有很多不同。
mod_python
做的是将解释器嵌入到Apache的进程里，这样就不用再为每个请求各启动一个解释器，从而加快了运行速度。另一方面，PHP经常混合着HTML，但Python不是。实际上，在Python中与之相当的是模板引擎。比起
mod_php
,
mod_python
本身要强大得多，它提供了更多的权限来访问Apache的内部。在一个Python混合HTML的"Python服务器页面"模式(与JSP相似)下，它可以模拟CGI工作。它还有一个"发布者"，可以指定一个文件来接收所有请求并决定接下来如何处理它们。
mod_python
确实有很多问题。不同于PHP解释器，Python解释器在运行文件时是使用缓存的，所以修改文件时需要重启服务器。另一个问题是关于Apache的工作原理 --- Apache启动子进程来处理请求，即使用不到Python，每个子进程依然要加载整个Python解释器。这让整个服务器运行得更慢了。另一个问题则是，如果不重新编译
mod_python
，它就不能切换版本(例如从2.4升级到2.5)，理由是
mod_python
依赖于一个特定版本的
libpython
。还有，
mod_python
是绑定到Apache上的，所以用
mod_python
写的程序不能轻易移植到在其他Web服务器上。
已经有很多原因解释了应该避免用
mod_python
