我的网络主机拒绝帮助我，所以我来这里的聪明人帮忙“黑盒子调试”。这是我发给他们的编辑版本：
我在dreamhost有两个（以及其他）域名：
1）thefigtrees.net 2）shouldivoteformccain.com
我今天注意到，当我在＃1上托管一个CGI脚本时，到那时候 CGI脚本运行，HTTP GET查询字符串作为QUERY_STRING传递给它 环境变量已经被URL解码。这是一个问题，因为 它意味着标准CGI库（如perl的CGI.pm）将尝试 拆分＆符号然后解码字符串本身。那里有两个 这个潜在的问题：
1）字符串被双重解码，因此如果将值提交给脚本 例如“％2525”，它最终会被视为“％”（解码两次） 而不是“％25”（解码一次）
2）（更常见）如果提交的值中有＆符号，那么它 将（正确）提交为％26，但QUERY_STRING环境。变量会 把它解码成“＆amp;”然后CGI库将不正确 将查询字符串拆分为该＆符号。这是一个大问题！
http://thefigtrees.net/test.cgi处的脚本证明了这一点。它回应了 它被调用的环境变量。在浏览器中导航到：
http://thefigtrees.net/lee/test.cgi?x=y%26z
您可以看到REQUEST_URI正确包含x = y％26z（未编码）但是 QUERY_STRING已将其解码为x = y＆amp; z。 如果我在域＃2重复测试（ http://www.shouldivoteformccain.com/test.cgi?x=y%26z）我明白了 QUERY_STRING保持未解码状态，因此CGI.pm会进行拆分和解码 正确。
我尝试在两者上禁用我的.htaccess文件，以确保不是 问题，并没有看到任何区别。
有人可以推测这可能的原因，因为我的网站主持人似乎不愿意帮助我吗？
感谢， 利
答案 0 :(得分：1)
我在Apache中有相同的行为。
我相信如果安装了URL，mod_rewrite会自动解码URL，但是，即使没有它，我也看到了自动解码行为。我没有找到另一个罪魁祸首。
一个常见的解决方法是对输入参数进行双重编码（在未编码的URL上调用时，利用URL解码是安全的。）
答案 1 :(得分：0)
好奇。我从这里看到的任何内容都无法告诉我们为什么会发生这种情况......我只能确认这是一个环境错误，并且怀疑可能是配置差异，例如重写规则。
根据CGI 1.1，此解码应仅发生在SCRIPT-NAME和PATH-INFO，而不是QUERY-STRING。它完全没有意义，也很烦人，但这就是规范。使用REQUEST-URI而不是那些可用的变量（即Apache）是一个常见的解决方法，适用于你想在路径部分中放置越界和Unicode字符的地方，因此对查询字符串执行相同的操作可能是合理的直到主机提供某种解决方案。
现在VPS很便宜......