http://galaxystar.iteye.com/blog/169765
一直没时间玩js，看到douban网的开放api后，查了些文档，了解了一下 jsonp 跨域请求方式.跟大家分享一下。
其实 jsonp 是个很简单的一个东西。
主要是利用了 <script/> 标签对 javascript 文档的动态解析来实现。（其实也可以用eval函数）
来个超简单的例子：
首先是准备客户端的代码，
- <!DOCTYPEhtmlPUBLIC"-//W3C//DTDXHTML1.0Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
- <htmlxmlns="http://www.w3.org/1999/xhtml">
- <head>
- <title>TestJsonp</title>
- <scripttype="text/javascript">
- functionjsonpCallback(result)
- {
- alert(result.msg);
- }
- </script>
- <scripttype="text/javascript"src="http://crossdomain.com/jsonServerResponse?jsonp=jsonpCallback"></script>
- </head>
- <body>
- </body>
- </html>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Test Jsonp</title>
<script type="text/javascript">
function jsonpCallback(result)
{
alert(result.msg);
}
</script>
<script type="text/javascript" src="http://crossdomain.com/jsonServerResponse?jsonp=jsonpCallback"></script>
</head>
<body>
</body>
</html>
其中 jsonCallback 是客户端注册的，获取跨域服务器上的json数据后，回调的函数。
http://crossdomain.com/jsonServerResponse?jsonp=jsonpCallback
这个 url 是跨域服务器取 json 数据的接口，参数为回调函数的名字，返回的格式为
- jsonpCallback({msg:'thisisjsondata'})
jsonpCallback({msg:'this is json data'})
Jsonp原理：
首先在客户端注册一个callback,然后把callback的名字传给服务器。
此时，服务器先生成 json 数据。
然后以 javascript 语法的方式，生成一个function,function 名字就是传递上来的参数 jsonp.
最后将 json 数据直接以入参的方式，放置到 function 中，这样就生成了一段 js 语法的文档，返回给客户端。
客户端浏览器，解析script标签，并执行返回的 javascript 文档，此时数据作为参数，传入到了客户端预先定义好的 callback 函数里.（动态执行回调函数）
评论
<script type="text/javascript"> function A(para){ alert(para); } </script> <script type="text/javascript"> A('this is test data'); </script><scrīpt LANGUAGE="Javascrīpt">
<!--
Function.prototype.bind = function() {
var __method = this,args = [],ōbject = arguments[0];
for (var i = 1; i < arguments.length; i++)
args.push(arguments[i]);
return function(moreargs) {
for (var i = 0; i < arguments.length; i++)
args.push(arguments[i]);
return __method.apply(object,args);
}
};
var scrīptTagProxy=function(){
this.head = document.getElementsByTagName("head")[0];
}
scrīptTagProxy.TRANS_ID=1000;
scrīptTagProxy.prototype={
loadUrl : function(url,params,caller,onComplete,onFailure){
transId=++scrīptTagProxy.TRANS_ID;
var trans = {
id : transId,
cb : "stcCallback"+transId,
scrīptId : "stcscrīpt"+transId,
url : url,
params : params,
caller : caller,
onComplete : onComplete,
onFailure :onFailure
};
var conn = this;
window[trans.cb] = function(o){
conn.handleResponse(o,trans);
};
params='callback='+trans.cb+'&'+params;
var scrīpt = document.createElement("scrīpt");
scrīpt.setAttribute("src",url+params);
scrīpt.setAttribute("type","text/javascrīpt");
scrīpt.setAttribute("id",trans.scrīptId);
//设置超时
trans.timeoutId=setTimeout(this.handleFailure.bind(conn,trans),10000);
this.head.appendChild(scrīpt);
},
handleResponse : function(o,trans){
this.destroyTrans(trans,true);
trans.onComplete.call(trans.caller||window,o);
},
handleFailure : function(trans){
this.destroyTrans(trans,false);
if(trans.onFailure){
trans.onFailure.call(trans.caller||window,null);
}else{
alert('超时');
}
},
destroyTrans : function(trans,isLoaded){
this.head.removeChild(document.getElementById(trans.scrīptId));
clearTimeout(trans.timeoutId);
if(isLoaded){
window[trans.cb] = undefined;
try{
delete window[trans.cb];
}catch(e){}
}else{
window[trans.cb] = function(){
window[trans.cb] = undefined;
try{
delete window[trans.cb];
}catch(e){}
};
}
}
}
function init(){
var proxy=new scrīptTagProxy();
proxy.loadUrl('http://search.yahooapis.com/ImageSearchService/V1/imageSearch?','appid=YahooDemo&query=Madonna&output=json',window,process)
}
function process(a){
alert('这个结果从服务器返回:'+a)
}
//-->
</scrīpt>
<body ōnload = "init()">
</body>
我的意思是，无论你用iframe或是只能用于ie的documentFragment（这明显是ie的一个问题，凭什么要为任意一个新节点产生一个新的脚本scope？而且我怀疑这会引起内存泄漏——ms的人在说memory leak的patterns那个文章里曾经提到过由这一问题引起的内存泄漏），所付出的代价似乎比不上得到的好处。
因为不用iframe，你也可以达到向最终编程者隐藏callback名字的目标，只需要callback是由你的框架托管和包装起来就可以了。差别只在于，这种方式，这个callback名字会污染当前的global上的命名空间，iframe则不会，因为它在一个独立的scope里——但是付出的代价是有独立的browserContext（包括window、document等对象）。
因此，iframe只是一个锦上添花的工具。我认为理想的目标是：
1. callback名字最好是可配置的。因为万一有些人写死了callback名字。。。
2. 有些人不仅写死了，而且不是callback({...json...})，而是var hardCodeJSON = {...json...}，最好也能处理这种情况（肯定是可以做到的）。
3. 不能每次都搞一个iframe，这样太浪费。iframe的唯一目的其实是搞一个独立的scope，所以弄一个iframe就可以了。还有基于前面提到的因素，建议不要用documentFragment。
那么在一个iframe情况下，你说的“多个一模一样的callback”的冲突还是存在。这就需要用其他技巧解决。所以反过来，如果其他技巧解决了这个问题，那么iframe的唯一好处就是一丁点都不污染全局命名空间——个人来讲，我认为这个好处还是相当有限的。
下面说一个一般化（也就是不需要iframe）的最土的思路。原本我们插入一个<script>标签来读取json。现在我们可以插入3个 <script>。第一个做初始化，建立服务器所需要的callback函数，如果有命名冲突，则把之前的那个变量保存起来。第二个还是 load JSON。第三个做清理，去掉服务器所用的callback，并把之前的变量恢复起来。
当然这只是一个一般的描述，实际做的时候，肯定有很多问题要解决，但是从大体上看，应该是行得通的。
原来firefox需要用绝对地址才可以,safari需要往iframe write html才行,我做了个简单的demo,唯一的一个约定就是输出的json文件的格式是var json = {...};
演示:http://wfsr.net/temp/loadjson.html
loadjson.html(没有写兼容safari的方式)
json.js
var json = {"number" : Math.random() * 100};比如第一次回调就是xxx?_callback1
第二次就是xxx?_callback2
当然这个过程是被包装起来自动的，最终程序员不用管它。
有人说全局命名污染，这个是没错。但是问题其实没那么严重，大不了你产生一个GUID好了，再有冲突，宇宙都毁灭几次了。
这样的唯一问题是它不是静态化的。
要静态化，其实就是避免不了对callback名字的约定。那么我们就污染吧，反正就污染一个，比如叫他 _九天十地菩萨摇头怕怕劈雳金光雷电掌_json_callback。当然考虑到每次都要写，我建议还是搞短点，例如 JSON.CB
JSON.CB完全可以鉴别自己是在哪个script里被调用的（具体方法就省略了），所以你在生成script时，插点草标就可以了。
iframe在这里唯一的好处就是连这个小小污染都没有了。不过考虑是否值得呢？这就贱人贱智啦！
问题是，emu同学花了那么多力气，其实绕了一圈也没有能提供更好的方案。因为所做的，不过是对最终编程者隐藏掉callback名字而已。这种活，不用iframe技巧，其实一样可以达到的。
山人讲的其他问题，我理解是这样的：
1. 我不想调一个全局函数，我想调一个局部函数，或者方法，总之那才是我的逻辑。
2. 我可能出于某种原因要同时发起若干个回调。
这种需求我觉得确实需要对callback上做包装。
首先，他隐含了个条件（或者说这句“想要用一致的callback接口来回传数据”稍稍说到了一点）文章里没说，就是服务器的输出，实际上是带有callback名字的，他的例子里是visitCountCallBack。
这说明两点：
第一：服务器输出的不是真正的json。
第二：仍然是耦合。只不过现在client code看不到这个耦合，而是library和server代码的隐藏耦合。对于同时包含两端的框架来说，这也许ok，但是我很不喜欢这种隐匿式的耦合。
这两点比之xxx?callback=myCallback，毛病大许多。
第一条就是强制了callback接口，你爽了，别人（别的调用者）都不爽。
第二条就是对耦合的认识，我认为是有失偏颇的。
BTW，documentFragment来得到一个单独的script作用域，我担心会有内存泄漏，可能应该多多测试看看。
另外推荐一下emu的这种方法:
http://www.blogjava.net/emu/articles/129240.html
不过我测试发现只有ie和opera支持,firefox和safari没效果,如果能兼容,这个方法才比较有吸引力