问题？
如果一个发出的资源请求中包含中文，浏览器是怎么处理的？
拾遗！
本文档旨在说明目前主流浏览器对于资源请求中夹杂中文的处理办法。
Browser： IE8、FireFox3.6.8、Chrome7dev。
AppServer：IIS6.0+ASP.net2.0
对于一个URI的资源来说，W3C是这样定义其包含的组成部分：scheme，authority，path，query，fragment（下图会有说明是什么意思）。对于互联网开发而言，scheme一般是http，https。authority也不会出现中文。所以中文出现的可能就只有 path和query这两部分。
我们假设有这个一个请求 "http://mysite.com/这是一个中文的文件夹/test_ajaxhadnler.ashx?条件=值"。这个请求在各个浏览器下怎么显示的呢？
我们使用专门的抓包工具抓获以后，如下图所示：
图
可以看到以下这些现象：
1，对于IE、FireFox和Chrome而言，他们对于path的编码恒定。IE是GBK，Chrome、FireFox是UTF-8。他们不会随着页面显示编码的改变而改变。而且服务端均可以正常识别这个编码指的是哪个路径。
2，所有的变化均出自query的部分。由于我的抓包工具的缘故（Fiddler2，请求部分不支持中文）。我猜测IE对于query的编码是恒定为 GBK。这也解释了为什么第一次并不乱码，后来却乱码了。同理FireFox也是如此，第一次乱码，后来不乱码。他们不乱码的时候都是和后台配置的字符集吻合的时候。
3，Chrome这方面处理的比较好。虽然Chrome的处理path采用的统一的方法，但是对于query部分的处理是跟着页面字符集走的。也就是页面什么字符集，发出去的请求就是什么字符集。这一点从两次都没有乱码提交到后台和捕获的http请求可以清晰的看出来。
4，这是一个猜想，就是IE之所以会使用GBK进行编码处理，也许和系统的字符集设定或是浏览器的语言版本的设定有关。比如我测试用的IE8是简体中文版的，那么他就按照GBK编码。猜测IE的测试结果应该是属于一个特例。没理由所有语言版本的浏览器都进行GBK编码。
结论？
1，少用或者不用中文，对于身处中国大陆进行互联网开发而言，在URL中夹杂任何中文对于兼容性而言简直是自觉坟墓，而且完全没有必要。而且一个中文字对应的任何一种编码都会变得很长。
2，后台无论编码如何，收到都是unicode编码（U码形式）。这对于字符集转换是非常有帮助的，U码可以转换成任何一种字符。但是如果后台收到的 Unicode码显示是乱码的时候，请坚信，在服务器收到的时候就已经错了。错的原因是发送方（客户端浏览器）和接受方（服务器）的字符集不匹配造成的。这种不匹配是人力无法解决的（不可能改变客户端行为，更改服务器又不可能满足所有条件）。
