由于有很多文献要读，我在这个http
server上建了一个目录，然后用脚本定时将实验室机器上的Paper同步到这个目录上，再在俺的MacBook上用另一个脚本下载回寝室。为了阅读方便，这个http
server上存放文献的目录开着Index。但是今天发现autoindex模块无法在Linux系统上显示中文文件名。于是在Firefox里面查看了一下Index页面的信息，发现发送编码居然是ISO-8859-1，也就是Western西方字符编
码。这就奇怪了，我明明在httpd.conf里指定了AddDefaultCharset UTF-8的啊。。。。
于是我打开autoindex模块的源代码，modules/generators/mod_autoindex.c，发现其中是这样判断编码的：
if (autoindex_conf->ctype) {
ctype = autoindex_conf->ctype;
}
if (autoindex_conf->charset) {
charset = autoindex_conf->charset;
}
else {
#if APR_HAS_UNICODE_FS
charset = "UTF-8";
#else
charset = "ISO-8859-1";
#endif
}
所以使用ISO-8859-1貌似是因为编译时预处理else中的判断结构出现了错误。那么APR_HAS_UNICODE_FS是个什么东西呢？查了一下，APR是Apache Portable
Runtime（Apache可移植运行库）的缩写，这是一个用来保证上层程序可以跨平台编译运行的中间层。APR_HAS_UNICODE_FS是在srclib/apr/include/apr.h中定义的，而这个apr.h则是在configure时由srclib/apr/include/apr.h.i生成的：在Windows下APR_HAS_UNICODE_FS＝1，而在Linux及Unix下APR_HAS_UNICODE_FS＝0，然后根据APR_HAS_UNICODE_FS的值，在编译autoindex模块时选择采用ISO-8859-1或者UTF－8编码。
这下问题就很明白了，这个http server系统是RHEL
5，locale是UTF-8，这样的话正好与mod_autoindex.c的初衷相违背：只要是在Linux系统下编译时，不管系统locale如何
设置都使用ISO-8859-1编码生成Index。
目前几乎所有主流Linux发行版的默认locale几乎清一色都是UTF-8，但是Apache中的autoindex_module非但不能判断locale采用相应的编码，反而不分青红皂白就用了ISO-8859-1编码。。。。这实在是。。。太汗了。
嗯，有时候Hacking一下软件还是很有意思的。
