谨防 url 传递参数未编码（转码）产生的陷阱

最新推荐文章于 2021-03-25 09:41:18 发布

转载最新推荐文章于 2021-03-25 09:41:18 发布 · 161 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/jyc_wy/archive/2009/03/04/1402737.html

文章标签：

#javascript #php #ViewUI

本文讲述了在web项目中因URL参数未正确编码导致的问题，包括不同文件编码间的集成问题及跨系统调用失败案例。

       在最近的项目中，碰到些因为 url 传递参数时未编码（转码）所引起的一些“莫名其妙”的错误，特此记下来，以免大家再像我一样走弯路。

      我们知道，web项目总少不了参数传递的情况，如 http://www.google.cn/search?hl=zh-CN&q=%E5%95%8A，这就带了hl 与 q 两个参数，并且 q 是经过编码的（中文为 “啊”）。但在项目中，我们有时候传递参数却会忘记对参数进行编码（解码、转码），这样，会产生什么样的陷阱呢？

      1、公司原有的OA（asp开发，文件编码：gb2312）与刚开发的内部业务系统（asp.net开发，文件编码：uft-8）进行集成，登陆OA，将用户名写入cookie（cookies["user_name"]），然后在业务系统中读取此 cookie，死活都读取不到，为什么？文件编码不同，导致业务系统里面cookie的名称已经变成了 “user%5Fname”！

      2、业务系统（文件编码：uft-8）内部调用外部的一个php文件（编码：gb2312）发送短信：http://sms.XXX.cn/index.php?controller=BoSends&action=sendSms&username=某公司&password=password&mobile=139********&content=Hello，也是一样发送不成功！看看php文件的编码，才知道是 gb2312，当username 和 password 传递过去的时候，系统里面找不到相关资料，因为username("某公司"）已经发生改变了！

      在这两种情况下，我们就必须对文件进行转码了：如2、HttpUtility.UrlEncode("某公司"，System.Text.Encoding.GetEncoding("gb2312"))，当然我们可以写一个方法：

转载于:https://www.cnblogs.com/jyc_wy/archive/2009/03/04/1402737.html