在Visual Studio 2008/2010中，当网站需要进行web调试的时候，我们一般都是直接使用VS自带的Server进行调试，也就是直接F5就解决了问题，但并不是所有的问题都能在这种问题下解决，因此我们有的时候需要使用IIS作为Web Server来进行调试。使用IIS作为宿主的时候，很有可能不会像使用VS自带的Web　Server调试来的顺利，而我最近的一次调试中就出现下面这个报错： 英文报错：Unable to start debugging on the web server.An authentication error occured while communicating with the web server. 中文报错：无法在WEB服务器上启动调试。 　　当然，也可能出现其他的错误，经过摸索，问题解决了，在网上也看到有很多人在使用IIS6/7进行调试的时候出现不能调试的情况，为了让有同样的问题朋友们能够有一个更简单的处理方式，我将可能出现问题的地方做了个初步汇编，如果出现不能使用IIS来调试Web程序时，可以按照这个步骤来检查下开发机器上的配置是否正确。 No1. IIS配置检查 　　要使用IIS来调试网站，自然要在IIS中配置好网站，具体的配置请参见IIS新建网站的配置说明，这里不赘述。为了保证网站能够正常运行，你可能需要关注网站的权限问题。在网站能够正常运行的情况下，却无法使用Visual Studio进行Web Debugging的时候，请检查下面配置： 网站配置项中，网站标签下的连接是否启用了保持HTTP连接项，IIS6的操作路径： IIS6管理器中右键当前调试网站--属性--网站--连接--保持HTTP连接  检查是否启用Windows身份验证。IIS6路径： IIS6管理器中右键当前调试网站--属性--目录安全--身份验证和访问控制--编辑--用户访问需经过身份验证--集成Windows身份验证 如果是ASP这样的网站也许你要启用在服务端进行ASP调试的选项，路径为：  IIS6管理器中右键当前调试网站--属性--主目录--应用程序设置--配置...--调试--调试标志--启用ASP服务器端脚本调试 && 启用ASP客户端脚本调试 启用IIS中ASP.NET的调试项，这项也可以从web.config中设置，路径为： IIS6管理器中右键当前调试网站--属性--ASP.NET--Edit Configuration（编辑配置）--应用程序--公共编译、页和运行时设置--勾选：启用调试--确定 如果你是IIS7，可以尝试启用IIS7中的Class .NET AppPool，经典的.NET应用程序池，路径： 当前调试站点--高级设置--应用程序池--Class .NET AppPool（经典模式) 上述问题配置配置如果设置之后，还是无法正常使用IIS调试VS中的Web程序，那么你可能还需要检查。 No2. 注册表配置检查[1] 禁用环回检查，将DisableLoopbackCheck 注册表项值置为1，Mitchell自己在Windows2003的问题就是这个方法解决的，注册表路径： 开始--运行--输入：regedit--确定--路由到下面路径： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa --右键：Lsa--新建--DWORD值--键入：DisableLoopbackCheck--右键：DisableLoopbackCheck--修改--数值数据框输入：1--确定。 ##注意： 操作后如果无法直接生效，可能需要重启系统。 ...

　　ASP.NET MVC在IIS6上绝少出现因为文件编码问题而导致的乱码问题，即使出现，也可以通过web.config的配置或者修改文件编码来解决，然而今天碰到的这例乱码问题，却无法使用这些方法来解决，无论怎么修改，乱码依旧。让人懊恼不已！ 　　问题是这样的：ASP.NET MVC2在IIS6上进行部署，由于系统还有一些暂时未能完全使用MVC架构的代码存在，就利用了IIS6中自定义错误页面的URL重定向机制，将404错误页面转发回系统页面进行处理，在系统中进行判定页面是否不存在或者重新配置页面地址重定向，让MVC Routing能够进行处理。想法是不错的，处理英文的时候也是非常顺畅的，但碰到中文的时候，系统就情不自禁的抽起疯来，根本就无法达到预期的效果。—— 一查，参数未解码的时候中文编码都是%ufffd，一解码全是乱码，能达到预期效果反而奇怪了！ 　　开始以为是配置上问题，检查了下config文件，发现request和response的Encoding都是UTF8，进而检查文件编码，也是UTF8，这和配置中的编码一致。理论上这样乱码应该不存在的，但理论往往和实际相差甚远！只好进一步检查，在历尽千辛万苦，最后发现问题原来出现在IIS的URL重定向上。当访问一个不存在的页面（含中文参数），IIS6会触发404错误，并将产生错误的内容重定向到指定的URL上，目标页面获取参数信息，但在处理中文时，需要进行解码，但根据IIS6定向过来的内容解码就会出现乱码，这就导致组合后的新地址经过MVC 路由后，无法正确的加载指定功能 —— 参数不对。 　　以前我一直的说法是找到问题就是成功解决问题的关键，这话的确没错，接下来要解决它，只需要找到为什么IIS6传递过来的内容会出现解码错误即可。然而，随着进一步的检查发现，问题远没有想象的那么简单，IIS6.0在处理字串的时候默认使用的是Unicode编码（注：这里比较乱，有说GBK，也有说GB2312，还有说是ASCII，谁知道请告诉我，IIS6使用的默认编码是什么？这里用Unicode）。这个编码和我们有什么关系么？—— 我现在是没有想出具体的关系的，但是肯定是有关系的。以下为本人观点，猜测成分比较大，如果你有更详细的这方面资料请分享，将非常感激。 　　在我们站点都使用UTF8的时候—— 这里我们需要补充个基础知识，UTF8的字符集是明显大于Unicode编码的。当IIS6检测到错误的时候，需要将UTF8转为IIS6的编码，并进行封装再转交给我们站点内处理，由于IIS6使用的是Unicode编码，在将UTF8字串转为Unicode时，因为字符集不够，所以出现无法转换现象，在无法转换是，系统用%ufffd来表示未能转换的字符。因此使用Unicode处理数据，再转交给站点内模块，程序设置为UTF8编码，UTF8去解码Unicode编码字串，结果可想而知，解码出来的中文自然而然就是乱码。这个思路大概用下面的图来概括（注：图中用的是GBK表示） 这个图片描述的可能有误，但迄今为止尝试了很多各种编码的组合方式，都没有很好的将中文转成在程序中获取到的那种样子，所以也不能确定到底IIS6使用的是什么东西。 　　解决方法网上有提供一些，但他们能真正的解决问题吗？ 　　1. 最多人的建议是使用UrlEncode方法将所有的中文进行编码之后传到服务端。 　　但这种方法对于自定义错误页面的方法根本就无法解决。IIS6同样会将URL中的中文变成乱码。 　　2. 另一种比较多的方法是在BeginRequest事件中处理，用Encoding去尝试转码来解决编码问题。 　　个人认为这个方法也没能真正解决问题，因为我们一旦获取到的是%ufffd这种的参数时，就意味着我们的参数已经出现问题了。再说，这个方法和前一种方法一样，真正错误的是在IIS6中的自定错误页面过来的参数，在这之前已经出现错误，后面怎么弥补都无济于事。 　　调试可以发现，在Request对象中，虽然QueryString，Url中的所有的都是乱码，但是RawUrl是正常的。如下图： 　　经过多次的测试发现，如果要比较好的解决这个问题，可以使用以下两种方法： 　　1. 如果真的要在BeginRequest中处理乱码——当然，你也可以在你需要获取参数的时候进行处理，使用RawUrl。因为只有这个参数能够完整的保留中文信息。 　　2. 对当前处理逻辑调整，直接处理掉可以处理的页面内容，而不要依赖IIS6的自定义错误页面来解决在程序中原本是非错误的页面，比如：数据库中页面，先要进行404跳转之后，再进入指定页面再来处理，这种处理方式比较闹心，但当下却还是有一些在用，我这篇文章就是这么来的。  　　当然了，上面的建议都是理想状态的，对于现存的项目来说，要实现不是一时半会，还需要仔细斟酌。针对我当前特定版本的解决方法，项目是MVC的，直接在Route中添加了对应规则，让这些都转入指定的模块中"销毁"吧，这和上述第二点原理一样，但却治不了根。  　　根据网上的一些信息综合起来看，这个问题应该是出自IIS6内部，不仅是中文，就连很多国际友人在做开发的时候也碰到过各种各样的Unicode Problem。有些反馈是说在IIS7下面没有这种现象，这个我没有测试，如果哪位有条件的可以测试下。   　　问题暂时解决了，可以先休息会，毕竟这个问题折腾了我好几天啊！   参考： CSDN 设置404页面所导致的乱码问题的帖子： http://bbs.csdn.net/topics/390358009 IIS.NET上面关于Unicode字符丢失的帖子：http://forums.iis.net/t/1085091.aspx/1