json与jsonp的区别、同源策略

有关json与jsonp的区别（json才是目的，jsonp只是手段）介绍如下所示：

一言以蔽之，json返回的是一串数据；而jsonp返回的是脚本代码（包含一个函数调用）；

JSON其实就是JavaScript中的一个对象，跟var obj={}在质上完全一样，只是在量上可以无限扩展。简单地讲，json其实就是JavaScript中的对象（Object）和数组（Array，其实也是对象）这倆好基友在那儿你嵌我我嵌你地套上n多层，以此模拟出许多复杂的数据结构。

json易于人阅读和编写，也易于机器解析和生成，相对网络传输速率较高，功能型网站前后端往往要频繁大量交换数据，而json凭借其强大的表现力和高颜值渐渐地成为理想的前后端数据交换语言。那xml前辈呢，我觉得应该会像微软的xp那样功成身退。

同源下的前后端数据交换格式确定使用json了，那么问题来了，如果我想获取别人网站上提供的数据肿么做到呢？也就是跨域读取数据问题（不要钻牛角说你不需要读取其他网站的数据，相信我，你早晚得需要），json行不行呢？答案是No Way，为什么呢，因为json只是普通的文本格式，能让你这样就轻松拿到那服务端就没有任何安全和保密性可言了，这样的话互联网世界非乱套不可，这个问题那些牛X的规范制定者早就想到了，所以使用了同源策略来限制文件获取。最后的结果就是只有像img、script、iframe这类可以指定src属性的标签有跨域获取别人网站上数据（图片，脚本，源文件其实都是数据）的能力。比如：

<！--京东商品图片--><img src="http://img30.360buyimg.com/jgsq-productsoa/jfs/t2407/323/1635505465/47386/f2d89d88/56615e00N7a475ee6.jpg" /><！--百度CDN--><script src="http://apps.bdimg.com/libs/jquery/2.1.4/jquery.min.js"></script> 

看来直接获取json是行不通了，那有没有其他方法能拿到数据呢？于是乎jsonp就这样被聪明的开发者给发现了，为什么说是发现而不是发明呢，因为并没有涉及到任何新技术，就像发现ajax一样。

jsonp原理是这样的，网站A需要获取网站B的数据，网站B说我给你们一个方法，【1. 你们使用<script src="http://www.B.com/open.js"></script>标签先获取到open.js文件（网站B的责任），这里边有你们需要的数据。2. 你们获取数据后处理数据（总得处理数据吧）的方法名必须命名为foo（数据请求者的责任和义务）】，这里相当于B网站和请求获取数据者之间建立了一个协议，要求请求者务必按照规则办事，如果请求者不能同时遵守上面两条就不能按预期获取数据。

open.js内容

foo（{"name":"B","age":23}）;  //为什么不直接写成json数据{"name":"B","age":23}呢，原因很简单，在js文件总得合乎js语法吧//这也是为什么协议中明确规定处理数据的方法名必须命名为foo，因为B网站是在假定请求者的脚本中已经定义了数据处理方法foo的情况下返回数据；//不然就会报foo is not defined错误

网站A脚本须有

function foo（data）{console.log（data）;//ToDo.. } 

啊！虽然拐了个弯，但数据总算得到了，网站A，网站B都非常高兴，那么问题又来了，网站C说也需要获取网站B的数据，网站B把协议甩给它，网站C拿过来一看，foo这个名字已经在自己的脚本文件的6868行用过了，而且已经使用在脚本的各个角落，批量替换会导致很多潜在bug啊，网站B情急之下决定把foo改成fool，网站A立马蹦起来，因为自己的网站已经在很多地方使用foo引用了数据。

为了避免上面情况发生，那些牛X哄哄的开发者使用了动态生成js文件的方法，php版本如下：

open.php

<?phpheader（"Content-type: application/javascript"）;$jsonCallback = htmlspecialchars（$_REQUEST ["callback"]）; //获取请求者自定义的回调函数名$jsonData ="{"name":"B","age":23}"; //待返回的json数据echo $jsonCallback . "（" . $jsonData . "）"; //输出jsonp格式的数据，即一行函数调用语句?> 

于是网站A用<script src="http://www.B.com/open.php?callback=foo"></script>来请求数据，不需要修改任何变量，返回给A的脚本文件内容是： 

foo（{"name":"B","age":23}）; //所谓的jsonp，就是一句函数调用，数据都被包裹传递到参数中了，千万别穿个马甲就不认识了 网站C就用<script src="http://www.B.com/open.php?callback=blah"></script>来请求数据，返回给C的脚本文件内容是：blah（{"name":"B","age":23}）; 网站N就用<script src="http://www.B.com/open.php?callback=what"></script>来请求数据，返回给N的脚本文件内容是：what（{"name":"B","age":23}）; 

Problem Solved，大家都取到了期望的数据，并且避免了命名冲突。

jsonp全名叫做json with padding，很形象，就是把json对象用符合js语法的形式包裹起来以使其它网站可以请求得到，也就是将json数据封装成js文件；

json是理想的数据交换格式，但没办法跨域直接获取，于是就将json包裹（padding）在一个合法的js语句中作为js文件传过去。这就是json和jsonp的区别，json是想要的东西，jsonp是达到这个目的而普遍采用的一种方法，当然最终获得和处理的还是json。所以说json是目的，jsonp只是手段。json总会用到，而jsonp只有在跨域获取数据才会用到。

理解了json和jsonp的区别之后，其实ajax里的跨域获取数据就很好理解和实现了，同源时候并没有什么特别的，直接取就行，跨域时候需要拐个弯来达到目的。

附上jquery中ajax请求json数据实例：

（同源）：

$.ajax（{url:"persons.json",success:function（data）{    console.log（data）;     //ToDo..  }}）; 

（跨域）：

$.ajax（{url:"http://www.B.com/open.php?callback=?",dataType:"jsonp",success:function（data）{console.log（data）;//ToDo..}}）; 

jquery已把jsonp封装进ajax，很合理，因为毕竟绝大多数的jsonp请求都是ajax，另外要注意的一点就是不同的网站提供的数据接口的$_REQUEST ["callback"]中不一定绝对是callback也可能是cb,cbk等，具体使用时务必阅读服务端提供的有关接口使用的详细文档。

通过ajax获得json数据后格式的转换

在有些情况下获取到的json数据可能是string类型的，需要把其格式化为json对象才方便解析。

a）原生js通过ajax获取到的json

此时返回的数据默认是string型的，所以需要用eval（）函数将其转化为json对象。需要注意函数内字符串的格式：eval（“（” + data+“）”），因为返回的string是在{}里面的，eval会将大括号识别为js代码块开始和结束的标志，所以必须加上（），将其强制转化为对象来处理。

b）jquery获取

1：通过ajax（）异步请求并把type设置为json，返回的就是json对象。

2：通过用与ajax（）等价的$.getJSON（url,data1,function（data2,status,xhr）{//......}）方法获取的也是json对象。其中data1为连同请求发送的数据，data2为服务器返回的数据即json对象。

同源策略：

同源策略（Same origin policy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说Web是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。

同源策略，它是由Netspace提出的一个著名的安全策略。现在所有支持JavaScript 的浏览器都会使用这个策略。所谓同源是指，域名，协议，端口相同。当一个浏览器的两个tab页中分别打开来 百度和谷歌的页面当浏览器的百度tab页执行一个脚本的时候会检查这个脚本是属于哪个页面的，即检查是否同源，只有和百度同源的脚本才会被执行。

概念:同源策略是客户端脚本（尤其是Javascript）的重要的安全度量标准。它最早出自Netscape Navigator2.0，其目的是防止某个文档或脚本从多个不同源装载。
   这里的同源指的是：同协议，同域名和同端口。
   它的精髓很简单：它认为自任何站点装载的信赖内容是不安全的。当被浏览器半信半疑的脚本运行在沙箱时，它们应该只被允许访问来自同一站点的资源，而不是那些来自其它站点可能怀有恶意的资源。
为什么要有同源限制？
   我们举例说明：比如一个黑客程序，他利用IFrame把真正的银行登录页面嵌到他的页面上，当你使用真实的用户名，密码登录时，他的页面就可以通过Javascript读取到你的表单中input中的内容，这样用户名，密码就轻松到手了。
Ajax应用：
   在Ajax应用中这种安全限制被突破。
   在普通的Javascript应用中，我们可以修改Frame的href，或者IFrame的src，以实现GET方式的跨域提交，但是却不能访问跨域的Frame/IFrame中的内容。
   而Ajax它通过XMLHTTP进行异步交互，这个对象同样能够与远程的服务器进行信息交互，而且更加危险的是，XMLHTTP是一个纯粹的Javascript对象，这样的交互过程，是在后台进行的，不被用户察觉。因此，XMLHTTP实际上已经突破了原有的Javascript的安全限制。
   如果我们又想利用XMLHTTP的无刷新异步交互能力，又不愿意公然突破Javascript的安全策略，可以选择的方案就是给XMLHTTP加上严格的同源限制。这样的安全策略，很类似于Applet的安全策略。IFrame的限制还仅仅是不能访问跨域HTMLDOM中的数据，而XMLHTTP则根本上限制了跨域请求的提交。
浏览器支持:而IE其实给这个安全策略开了两个想当然的后门，一个是：他假设你的本地文件，自然清楚将会访问什么内容，所以任何你的本地文件访问外部数据， 都不会收到任何的警告。另一个是：当你访问的网站脚本打算访问跨域的信息时， 他居然仅仅是弹出一个对话框来提醒你一下。如果一个欺诈网站，采用这样的手段，提供一个假页面给你，然后通过XMLHTTP帮你远程登录真实的银行服务器。只要10个用户里，有一个用户糊涂一下，点了一个确定。他们的盗取帐号行为，就成功了！ 你想想看，这是何等危险的事情！ 
FireFox就不是这样的做法，缺省的情况下，FireFox根本就不支持跨域的XMLHTTP请求，根本就不给黑客这样的机会。
避免同源策略：
JSON和动态脚本标记
<script type="text/javascript"
  src="http://travel.com/findItinerary?username=sachiko&
  reservationNum=1234&output=json&callback=showItinerary" />  
  当 JavaScript 代码动态地插入 <script> 标记时，浏览器会访问 src 属性中的 URL。这样会导致将查询字符串中的信息发送给服务器。在 清单 1中，所传递的是 username 和 reservation 作为名称值对传递。此外，查询字符串还包含向服务器请求的输出格式和回调函数的名称（即 showItinerary）。<script> 标记加载后，会执行回调函数，并通过回调函数的参数把从服务返回的信息传递给该回调函数。
Ajax代理
  Ajax 代理是一种应用级代理服务器，用于调解 Web 浏览器和服务器之间的 HTTP 请求和响应。Ajax 代理允许 Web 浏览器绕过同源策略，这样便可以使用 XMLHttpRequest 访问第三方服务器。要实现这种绕过，有如下两种方法可供选择：
客户端 Web 应用程序知道第三方 URL 并将该 URL 作为 HTTP 请求中的一个请求参数传递给 Ajax 代理。然后，代理将请求转发给 [url]www.remoteservice.com[/url]。注意，可以把代理服务器的使用隐藏在 Web应用程序开发人员所使用的 Ajax 库的实现中。对于 Web 应用程序开发人员而言，它看上去可能完全不具有同源策略。 
客户端 Web 应用程序不知道第三方 URL，并且尝试通过 HTTP 访问 Ajax 代理服务器上的资源。通过一个预定义的编码规则，Ajax 代理将 所请求的 URL 转换为第三方服务器的 URL 并代表客户检索内容。这样一来，Web 应用程序开发人员看上去就像是在和代理服务器直接进行通信。 
Greasemonkey
  Greasemonkey 是一个 Firefox 扩展，它允许用户动态地对 Web 页面的样式和内容进行修改。Greasemonkey 用户可以把用户脚本（user script）文件与一个 URL 集合建立关联。当浏览器通过该 URL 集合加载页面时，便会执行这些脚本。Greasemonkey 为用户脚本的 API 提供了额外的许可（与运行在浏览器沙盒中的脚本的许可相比较）。
  GM_XMLHttpRequest 是其中的一个 API，它从本质上说就是一个不具有同源策略的 XMLHttpRequest。用户脚本可以将浏览的内置 XMLHttpRequest 替代为 GM_XMLHttpRequest，从而许可 XMLHttpRequest 执行跨域访问。
  GM_XMLHttpRequest 的使用只能通过用户同意的途径才能受到保护。也就是说，Greasemonkey 只有在建立新用户脚本与特定 URL 的集合之间的关联时才会要求用户配置。然而，不难想象一些用户可能会被欺骗，在没有完全理解其后果时就接受该安装。