日期:2014-05-16  浏览次数:20401 次

Javascript函数数字类型参数传值隐患
         今天在写程序的时候出现了一个奇怪的情况,业务需求很简单,只是通过客户端的JS方法进行AJAX请求,传入后台的参数是一个订单子项号,在后台用beanshell通过ID获取订单子项并修改其还款状态后进行保存。

function passRefundApply(orderItemId){
	 	//alert(orderItemId);
	 	$.ajax({  
			     type: "get",  
			     url: "/openorder/control/updateRefundStatus",  
			     data:"orderItemId="+orderItemId+"&refundStatus=P",  
			     cache: false,  
			     success: function(msg){  
			        var result = eval("("+removeDivTag(msg)+")");
			        try{
				        if(result.result!="success"){
				        	alert("修改失败,请重试!");
				        	return;
				        }	
				    }catch(e){
				    	alert("修改失败,请重试!");
				        return;
				    }		        
			        $("#refundStatus_"+orderItemId)[0].innerHTML = "退款审核已通过";
			     }  
			});			
	 }


       因为该方法的调用入口是用过JS即时生成的:
       $("#refundStatus_"+orderItemId)[0].innerHTML = "<a href=\"javascript:void(0);\" onclick=\"passRefundApply("+orderItemId+")\">审核通过</a>&nbsp;&nbsp;<a href=\"javascript:void(0);\" onclick=\"rejectRefundApply("+orderItemId+")\">审核拒绝</a>";

       其中传入的订单子项ID是10201005021047710584,并确认了该数据在数据库中有相应的记录对应。但是在后台却无法通过传入的订单子项ID取到数据库中相应的数据,查看日志后发现传入的订单子项ID为10201005021047710000。通过跟踪,并借助firebug,发现ID在函数调用passRefundApply(10201005021047710584)时还是正常的,但是在函数passRefundApply中第一行alert出来已是10201005021047710000,原来是在传值后被默认的篡改了....
       鉴于上述现象,做了个实验,用记事本新建一个htm文件,只在里面写入
       <script>
	      alert(12345678900987654321);
       </script>

       那打出来的是什么呢?
       是12345678900987654000.......精度丢失了。原本以为JS的弱类型很好用,结果在此处有着危险的陷阱,下次尽量在项目中使用字符串传值,加上引号以保万全。


       此处补充下关于精度丢失的问题,Javascript的数字数据类型不区分整型数值和浮点型数值,所有数字都由浮点型表示。对于十进制数,Javascript能精确表示-9007199254740992(- 2的53次)到 9007199254740992(2的53次)之间(闭区间)的所有整数,超过的就会丢失位数的精度。可以参考《Javascript权威指南》。