"cgi" --- 通用网关接口支持
**************************

**源代码：** Lib/cgi.py

======================================================================

通用网关接口 (CGI) 脚本的支持模块

本模块定义了一些工具供以 Python 编写的 CGI 脚本使用。


概述
====

CGI 脚本是由 HTTP 服务器发起调用，通常用来处理通过 HTML "<FORM>" 或
"<ISINDEX>" 元素提交的用户输入。

在大多数情况下，CGI 脚本存放在服务器的 "cgi-bin" 特殊目录下。 HTTP 服
务器将有关请求的各种信息（例如客户端的主机名、所请求的 URL、查询字符串
以及许多其他内容）放在脚本的 shell 环境中，然后执行脚本，并将脚本的输
出发回到客户端。

脚本的输入也会被连接到客户端，并且有时表单数据也会以此方式来读取；在其
他时候表单数据会通过 URL 的“查询字符串”部分来传递。 本模块的目标是处理
不同的应用场景并向 Python 脚本提供一个更为简单的接口。 它还提供了一些
工具为脚本调试提供帮助，而最近增加的还有对通过表单上传文件的支持（如果
你的浏览器支持该功能的话）。

CGI 脚本的输出应当由两部分组成，并由一个空行分隔。 前一部分包含一些标
头，它们告诉客户端后面会提供何种数据。 生成一个最小化标头部分的 Python
代码如下所示:

   print("Content-Type: text/html")    # HTML is following
   print()                             # blank line, end of headers

后一部分通常为 HTML，提供给客户端软件来显示格式良好包含标题的文本、内
联图片等内容。 下面是打印一段简单 HTML 的 Python 代码:

   print("<TITLE>CGI script output</TITLE>")
   print("<H1>This is my first CGI script</H1>")
   print("Hello, world!")


使用cgi模块。
=============

通过敲下 "import cgi" 来开始。

当你在写一个新脚本时，考虑加上这些语句:

   import cgitb
   cgitb.enable()

This activates a special exception handler that will display detailed
reports in the Web browser if any errors occur.  If you'd rather not
show the guts of your program to users of your script, you can have
the reports saved to files instead, with code like this:

   import cgitb
   cgitb.enable(display=0, logdir="/path/to/logdir")

在脚本开发期间使用此特性会很有帮助。 "cgitb" 所产生的报告提供了在追踪
程序问题时能为你节省大量时间的信息。 你可以在完成测试你的脚本并确信它
能正确工作之后再移除 "cgitb" 行。

要获取提交的表单数据，请使用 "FieldStorage" 类。 如果表单包含非 ASCII
字符，请使用 *encoding* 关键字参数并设置为文档所定义的编码格式值。 它
通常包含在 HTML 文档的 HEAD 部分的 META 标签中或者由 *Content-Type* 标
头所指明。 这会从标准输入或环境读取表单内容（取决于根据 CGI 标准设置的
多个环境变量的值）。 由于它可能会消耗标准输入，它应当只被实例化一次。

"FieldStorage" 实例可以像 Python 字典一样来检索。 它允许通过 "in" 运算
符进行成员检测，也支持标准字典方法 "keys()" 和内置函数 "len()"。 包含
空字符串的表单字段会被忽略而不会出现在字典中；要保留这样的值，请在创建
"FieldStorage" 实例时为可选的 *keep_blank_values* 关键字形参提供一个真
值。

举例来说，下面的代码（假定 *Content-Type* 标头和空行已经被打印）会检查
字段 "name" 和 "addr" 是否均被设为非空字符串:

   form = cgi.FieldStorage()
   if "name" not in form or "addr" not in form:
       print("<H1>Error</H1>")
       print("Please fill in the name and addr fields.")
       return
   print("<p>name:", form["name"].value)
   print("<p>addr:", form["addr"].value)
   ...further form processing here...

在这里的字段通过 "form[key]" 来访问，它们本身就是 "FieldStorage" (或
"MiniFieldStorage"，取决于表单的编码格式) 的实例。 实例的 "value" 属性
会产生字段的字符串值。 "getvalue()" 方法直接返回这个字符串；它还接受可
选的第二个参数作为当请求的键不存在时要返回的默认值。

如果提交的表单数据包含一个以上的同名字段，由 "form[key]" 所提取的对象
将不是一个 "FieldStorage" 或 "MiniFieldStorage" 实例而是由这种实例组成
的列表。 类似地，在这种情况下，"form.getvalue(key)" 将会返回一个字符串
列表。 如果你预计到这种可能性（当你的 HTML 表单包含多个同名字段时），
请使用 "getlist()" 方法，它总是返回一个值的列表（这样你就不需要对只有
单个项的情况进行特别处理）。 例如，这段代码拼接了任意数量的 username
字段，以逗号进行分隔:

   value = form.getlist("username")
   usernames = ",".join(value)

如果一个字段是代表上传的文件，请通过 "value" 属性访问该值或是通过
"getvalue()" 方法以字节形式将整个文件读入内存。 这可能不是你想要的结果
。 你可以通过测试 "filename" 属性或 "file" 属性来检测上传的文件。 然后
你可以从 "file" 属性读取数据，直到它作为 "FieldStorage" 实例的垃圾回收
的一部分被自动关闭 ("read()" 和 "readline()" 方法将返回字节数据):

   fileitem = form["userfile"]
   if fileitem.file:
       # It's an uploaded file; count lines
       linecount = 0
       while True:
           line = fileitem.file.readline()
           if not line: break
           linecount = linecount + 1

"FieldStorage" 对象还支持在 "with" 语句中使用，该语句结束时将自动关闭
它们。

如果在获取上传文件的内容时遇到错误（例如，当用户点击回退或取消按钮中断
表单提交时）该字段中对象的 "done" 属性值将被设为 -1。

文件上传标准草案考虑到了从一个字段上传多个文件的可能性（使用递归的
*multipart/** 编码格式）。 当这种情况发生时，该条目将是一个类似字典的
"FieldStorage" 条目。 这可以通过检测它的 "type" 属性来确定，该属性应当
是 *multipart/form-data* (或者可能是匹配 *multipart/** 的其他 MIME 类
型)。 在这种情况下，它可以像最高层级的表单对象一样被递归地迭代处理。

当一个表单按“旧”格式提交时（即以查询字符串或是单个 *application/x-www-
form-urlencoded* 类型的数据部分的形式），这些条目实际上将是
"MiniFieldStorage" 类的实例。 在这种情况下，"list", "file" 和
"filename" 属性将总是为 "None"。

通过 POST 方式提交并且也带有查询字符串的表单将同时包含 "FieldStorage"
和 "MiniFieldStorage" 条目。

在 3.4 版更改: "file" 属性会在创建 "FieldStorage" 实例的垃圾回收操作中
被自动关闭。

在 3.5 版更改: 为 "FieldStorage" 类增加了上下文管理协议支持。


更高层级的接口
==============

前面的部分解释了如何使用 "FieldStorage" 类来读取 CGI 表单数据。 本部分
则会描述一个更高层级的接口，它被添加到此类中以允许人们以更为可读和自然
的方式行事。 这个接口并不会完全取代前面的部分所描述的技巧 --- 例如它们
在高效处理文件上传时仍然很有用处。

此接口由两个简单的方法组成。 你可以使用这两个方法以通用的方式处理表单
数据，而无需担心在一个名称下提交的值是只有一个还是有多个。

在前面的部分中，你已学会当你预期用户在一个名称下提交超过一个值的时候编
写以下代码:

   item = form.getvalue("item")
   if isinstance(item, list):
       # The user is requesting more than one item.
   else:
       # The user is requesting only one item.

这种情况很常见，例如当一个表单包含具有相同名称的一组复选框的时候:

   <input type="checkbox" name="item" value="1" />
   <input type="checkbox" name="item" value="2" />

但是在多数情况下，一个表单中的一个特定名称只对应一个表单控件。 因此你
可能会编写包含以下代码的脚本:

   user = form.getvalue("user").upper()

这段代码的问题在于你绝不能预期客户端会向你的脚本提供合法的输入。 举例
来说，如果一个好奇的用户向查询字符串添加了另一个 "user=foo" 对，则该脚
本将会崩溃，因为在这种情况下 "getvalue("user")" 方法调用将返回一个列表
而不是字符串。 在一个列表上调用 "upper()" 方法是不合法的（因为列表并没
有这个方法）因而会引发 "AttributeError" 异常。

因此，读取表单数据值的正确方式应当总是使用检查所获取的值是单一值还是值
列表的代码。 这很麻烦并且会使脚本缺乏可读性。

一种更便捷的方式是使用这个更高层级接口所提供的 "getfirst()" 和
"getlist()" 方法。

FieldStorage.getfirst(name, default=None)

   此方法总是只返回与表单字段 *name* 相关联的单一值。 此方法在同一名称
   下提交了多个值的情况下将仅返回第一个值。 请注意所接收的值顺序在不同
   浏览器上可能发生变化因而是不确定的。 [1]  如果指定的表单字段或值不
   存在则此方法将返回可选形参 *default* 所指定的值。 如果未指定此形参
   则默认值为 "None"。

FieldStorage.getlist(name)

   此方法总是返回与表单字段 *name* 相关联的值列表。 如果 *name* 指定的
   表单字段或值不存在则此方法将返回一个空列表。 如果指定的表单字段只包
   含一个值则它将返回只有一项的列表。

使用这两个方法你将能写出优雅简洁的代码:

   import cgi
   form = cgi.FieldStorage()
   user = form.getfirst("user", "").upper()    # This way it's safe.
   for item in form.getlist("item"):
       do_something(item)


函数
====

These are useful if you want more control, or if you want to employ
some of the algorithms implemented in this module in other
circumstances.

cgi.parse(fp=None, environ=os.environ, keep_blank_values=False, strict_parsing=False, separator="&")

   Parse a query in the environment or from a file (the file defaults
   to "sys.stdin").  The *keep_blank_values*, *strict_parsing* and
   *separator* parameters are passed to "urllib.parse.parse_qs()"
   unchanged.

   在 3.8.8 版更改: Added the *separator* parameter.

cgi.parse_multipart(fp, pdict, encoding="utf-8", errors="replace", separator="&")

   Parse input of type *multipart/form-data* (for  file uploads).
   Arguments are *fp* for the input file, *pdict* for a dictionary
   containing other parameters in the *Content-Type* header, and
   *encoding*, the request encoding.

   Returns a dictionary just like "urllib.parse.parse_qs()": keys are
   the field names, each value is a list of values for that field. For
   non-file fields, the value is a list of strings.

   This is easy to use but not much good if you are expecting
   megabytes to be uploaded --- in that case, use the "FieldStorage"
   class instead which is much more flexible.

   在 3.7 版更改: Added the *encoding* and *errors* parameters.  For
   non-file fields, the value is now a list of strings, not bytes.

   在 3.8.8 版更改: Added the *separator* parameter.

cgi.parse_header(string)

   Parse a MIME header (such as *Content-Type*) into a main value and
   a dictionary of parameters.

cgi.test()

   Robust test CGI script, usable as main program. Writes minimal HTTP
   headers and formats all information provided to the script in HTML
   form.

cgi.print_environ()

   Format the shell environment in HTML.

cgi.print_form(form)

   Format a form in HTML.

cgi.print_directory()

   Format the current directory in HTML.

cgi.print_environ_usage()

   Print a list of useful (used by CGI) environment variables in HTML.


Caring about security
=====================

There's one important rule: if you invoke an external program (via the
"os.system()" or "os.popen()" functions. or others with similar
functionality), make very sure you don't pass arbitrary strings
received from the client to the shell.  This is a well-known security
hole whereby clever hackers anywhere on the Web can exploit a gullible
CGI script to invoke arbitrary shell commands.  Even parts of the URL
or field names cannot be trusted, since the request doesn't have to
come from your form!

To be on the safe side, if you must pass a string gotten from a form
to a shell command, you should make sure the string contains only
alphanumeric characters, dashes, underscores, and periods.


Installing your CGI script on a Unix system
===========================================

Read the documentation for your HTTP server and check with your local
system administrator to find the directory where CGI scripts should be
installed; usually this is in a directory "cgi-bin" in the server
tree.

Make sure that your script is readable and executable by "others"; the
Unix file mode should be "0o755" octal (use "chmod 0755 filename").
Make sure that the first line of the script contains "#!" starting in
column 1 followed by the pathname of the Python interpreter, for
instance:

   #!/usr/local/bin/python

Make sure the Python interpreter exists and is executable by "others".

Make sure that any files your script needs to read or write are
readable or writable, respectively, by "others" --- their mode should
be "0o644" for readable and "0o666" for writable.  This is because,
for security reasons, the HTTP server executes your script as user
"nobody", without any special privileges.  It can only read (write,
execute) files that everybody can read (write, execute).  The current
directory at execution time is also different (it is usually the
server's cgi-bin directory) and the set of environment variables is
also different from what you get when you log in.  In particular,
don't count on the shell's search path for executables ("PATH") or the
Python module search path ("PYTHONPATH") to be set to anything
interesting.

If you need to load modules from a directory which is not on Python's
default module search path, you can change the path in your script,
before importing other modules.  For example:

   import sys
   sys.path.insert(0, "/usr/home/joe/lib/python")
   sys.path.insert(0, "/usr/local/lib/python")

(This way, the directory inserted last will be searched first!)

Instructions for non-Unix systems will vary; check your HTTP server's
documentation (it will usually have a section on CGI scripts).


Testing your CGI script
=======================

Unfortunately, a CGI script will generally not run when you try it
from the command line, and a script that works perfectly from the
command line may fail mysteriously when run from the server.  There's
one reason why you should still test your script from the command
line: if it contains a syntax error, the Python interpreter won't
execute it at all, and the HTTP server will most likely send a cryptic
error to the client.

Assuming your script has no syntax errors, yet it does not work, you
have no choice but to read the next section.


Debugging CGI scripts
=====================

First of all, check for trivial installation errors --- reading the
section above on installing your CGI script carefully can save you a
lot of time.  If you wonder whether you have understood the
installation procedure correctly, try installing a copy of this module
file ("cgi.py") as a CGI script.  When invoked as a script, the file
will dump its environment and the contents of the form in HTML form.
Give it the right mode etc, and send it a request.  If it's installed
in the standard "cgi-bin" directory, it should be possible to send it
a request by entering a URL into your browser of the form:

   http://yourhostname/cgi-bin/cgi.py?name=Joe+Blow&addr=At+Home

If this gives an error of type 404, the server cannot find the script
-- perhaps you need to install it in a different directory.  If it
gives another error, there's an installation problem that you should
fix before trying to go any further.  If you get a nicely formatted
listing of the environment and form content (in this example, the
fields should be listed as "addr" with value "At Home" and "name" with
value "Joe Blow"), the "cgi.py" script has been installed correctly.
If you follow the same procedure for your own script, you should now
be able to debug it.

The next step could be to call the "cgi" module's "test()" function
from your script: replace its main code with the single statement

   cgi.test()

This should produce the same results as those gotten from installing
the "cgi.py" file itself.

When an ordinary Python script raises an unhandled exception (for
whatever reason: of a typo in a module name, a file that can't be
opened, etc.), the Python interpreter prints a nice traceback and
exits.  While the Python interpreter will still do this when your CGI
script raises an exception, most likely the traceback will end up in
one of the HTTP server's log files, or be discarded altogether.

Fortunately, once you have managed to get your script to execute
*some* code, you can easily send tracebacks to the Web browser using
the "cgitb" module. If you haven't done so already, just add the
lines:

   import cgitb
   cgitb.enable()

to the top of your script.  Then try running it again; when a problem
occurs, you should see a detailed report that will likely make
apparent the cause of the crash.

If you suspect that there may be a problem in importing the "cgitb"
module, you can use an even more robust approach (which only uses
built-in modules):

   import sys
   sys.stderr = sys.stdout
   print("Content-Type: text/plain")
   print()
   ...your code here...

This relies on the Python interpreter to print the traceback.  The
content type of the output is set to plain text, which disables all
HTML processing.  If your script works, the raw HTML will be displayed
by your client.  If it raises an exception, most likely after the
first two lines have been printed, a traceback will be displayed.
Because no HTML interpretation is going on, the traceback will be
readable.


Common problems and solutions
=============================

* Most HTTP servers buffer the output from CGI scripts until the
  script is completed.  This means that it is not possible to display
  a progress report on the client's display while the script is
  running.

* Check the installation instructions above.

* Check the HTTP server's log files.  ("tail -f logfile" in a separate
  window may be useful!)

* Always check a script for syntax errors first, by doing something
  like "python script.py".

* If your script does not have any syntax errors, try adding "import
  cgitb; cgitb.enable()" to the top of the script.

* When invoking external programs, make sure they can be found.
  Usually, this means using absolute path names --- "PATH" is usually
  not set to a very useful value in a CGI script.

* When reading or writing external files, make sure they can be read
  or written by the userid under which your CGI script will be
  running: this is typically the userid under which the web server is
  running, or some explicitly specified userid for a web server's
  "suexec" feature.

* Don't try to give a CGI script a set-uid mode.  This doesn't work on
  most systems, and is a security liability as well.

-[ 备注 ]-

[1] Note that some recent versions of the HTML specification do state
    what order the field values should be supplied in, but knowing
    whether a request was received from a conforming browser, or even
    from a browser at all, is tedious and error-prone.
