请指点中文名附件问题（立即支付5000元顾问费！）

这个问题的原因在于url的中文编码问题和服务器和浏览器的实现问题，很多地方都会遇到。不仅是IE5.0即使在IE 5.5和IE 6.0，某些特殊的中文字组合也不行的。按照uri/url的规范（http://www.ietf.org/rfc/rfc2396.txt），uri一般只能由一部分ascii字符组成。但是其他字符可以通过escape来转码。而混乱也来源于此。首先我们要区分字符和octets（八位字节）。这里有两种映射，一是从uri字符到八位字节，二是从八位字节到原来的字符。
URI character sequence->octet sequence->original character sequence
通常这种转换是清晰的，例如“a”被转为八位字节的97（十进制），而字符序列"%0a"，被转为八位字节的10（十进制）。
但是对于某些资源来说有第二种转译，uri的一部分八位字节序列随后被用于呈现字符序列，“charset”定义了这种映射。例如utf-8编码定义了unicode到八位字节的映射。于是情况就复杂了，我们需要了解到底uri用了哪种charset编码，但是一般的uri语法不能提供这个信息。
浏览器一般简单的根据系统缺省编码发送，例如GB2312。兼容性很好的utf-8（中文字符被转换为3个八位字节，然后进一步表示为%HH也就是共9个字节）和最常用的gb2312（中文字符被转为2个八位字节并变成%HH共6个字节）截然不同，但这还不是最糟糕的情况，因为IE有所谓“始终以utf-8编码url”的选项。可是资源的获取并非仅仅依靠浏览器，还要服务器识别这个url并最终映射到真正的磁盘上的物理地址（于是还牵扯到操作系统的编码问题）。遗憾的是即使是微软的iis在url的编码识别方面也存在问题，我们不能确切的了解到底web服务器把浏览器发送的请求所包含的url怎么处理。况且还有文件系统的编码问题。任何一个环节都可能造成错误。也许详细的web服务器文档会回答这个问题。而且对于apache和iis，或者其他web服务器，答案可能截然不同。这个问题在ftp服务上同样甚至更严重的存在着。
通常从经验的角度，多数web server（包括中文IIS）通常按照ansi（gb2312兼容）的方式（每个中文字为%HH%HH）处理url，这也是很多时候取消utf-8奏效的原因。但遗憾的是，一个是GBK扩展字符，另外也许是服务器的实现有bug，或者浏览器的实现有bug？，某些字符组合（估计主要因为在某个环节，某些中文字符的特定组合的内码高位与其他扩展拉丁字符冲突，造成解析错误）不能奏效。这时候折衷的办法也许是换个中文文件名，或者使用每个中文字后加空格？总而言之，目前为止，实践上最佳的解决方法是
1. 全部使用US-ASCII字符，即英文文件（汉语拼音？）名。
或者2. 使用完全支持Unicode的操作系统（文件系统）和Web Server，浏览器端打开utf-8。