一、定义

单页 Web 应用 (single-page application 简称为 SPA) 是一种特殊的 Web 应用。它将所有的活动局限于一个Web页面中，仅在该Web页面初始化时加载相应的HTML、JavaScript 和 CSS。一旦页面加载完成了，SPA不会因为用户的操作而进行页面的重新加载或跳转。取而代之的是利用 JavaScript 动态的变换HTML的内容，从而实现UI与用户的交互。由于避免了页面的重新加载，SPA 可以提供较为流畅的用户体验。

二、优缺点

单页Web程序的出现是富客户端发展的必然结果，但是该技术也是有些局限性，所以采用之前需要了解清楚它的优缺点。

1、优点：

1).良好的交互体验

用户不需要重新刷新页面，获取数据也是通过Ajax异步获取，页面显示流畅。

2).良好的前后端工作分离模式

单页Web应用可以和RESTful规约一起使用，通过REST API提供接口数据，并使用Ajax异步获取，这样有助于分离客户端和服务器端工作。更进一步，可以在客户端也可以分解为静态页面和页面交互两个部分。

3).减轻服务器压力

服务器只用出数据就可以，不用管展示逻辑和页面合成，吞吐能力会提高几倍；

4).共用一套后端程序代码
不用修改后端程序代码就可以同时用于Web界面、手机、平板等多种客户端；
 
2、缺点：

1).SEO难度较高

由于所有的内容都在一个页面中动态替换显示，所以在SEO上其有着天然的弱势，所以如果你的站点对SEO很看重，且要用单页应用，那么就做些静态页面给搜索引擎用吧。

2).前进、后退管理

由于单页Web应用在一个页面中显示所有的内容，所以不能使用浏览器的前进后退功能，所有的页面切换需要自己建立堆栈管理，当然此问题也有解决方案，比如利用URI中的散列+iframe实现。

3).初次加载耗时多

为实现单页Web应用功能及显示效果，需要在加载页面的时候将JavaScript、CSS统一加载，部分页面可以在需要的时候加载。所以必须对JavaScript及CSS代码进行合并压缩处理，如果使用第三方库，建议使用一些大公司的CDN，因此带宽的消耗是必然的

二、单页面应用实现的原理

1、基本实现原理：利用ajax请求替代了a标签的默认跳转，然后利用html5中的API修改了url，这项技术并没有特别标准的学名，大家都称呼为Pjax，意为PushState + Ajax。这并不完全准确，因为还有Hash + Ajax等方法

2、Pjax是一个优秀的解决方案，你有足够多的理由来使用它：
 
可以在页面切换间平滑过渡，增加Loading动画。可以在各个页面间传递数据，不依赖URL。可以选择性的保留状态，如音乐网站，切换页面时不会停止播放歌曲。所有的标签都可以用来跳转，不仅仅是a标签。避免了公共JS的反复执行，如无需在各个页面打开时都判断是否登录过等等。减少了请求体积，节省流量，加快页面响应速度。平滑降级到低版本浏览器上，对SEO也不会有影响。

3、深剖原理

拦截a标签的默认跳转动作。
2. 使用Ajax请求新页面。
3. 将返回的Html替换到页面中。
4. 使用HTML5的History API或者Url的Hash修改Url。

4、HTML5 History APIhistory.pushState(state, title, url)
pushState方法会将当前的url添加到历史记录中，然后修改当前url为新url。请注意，这个方法只会修改地址栏的Url显示，但并不会发出任何请求。我们正是基于此特性来实现Pjax。它有3个参数：
state: 可以放任意你想放的数据，它将附加到新url上，作为该页面信息的一个补充。title: 顾名思义，就是document.title。不过这个参数目前并无作用，浏览器目前会选择忽略它。url: 新url，也就是你要显示在地址栏上的url。
 history.replaceState(state, title, url)
replaceState方法与pushState大同小异，区别只在于pushState会将当前url添加到历史记录，之后再修改url，而replaceState只是修改url，不添加历史记录。

window.onpopstate 事件
一般来说，每当url变动时，popstate事件都会被触发。但若是调用pushState来修改url，该事件则不会触发，因此，我们可以把它用作浏览器的前进后退事件。该事件有一个参数，就是上文pushState方法的第一个参数state。 查看全部

history.pushState(state, title, url)

history.replaceState(state, title, url)

自Vue.js在官方推特第一次公开到现在，我们就一直在进行着将饿了么移动端网站升级为 Progressive Web App的工作。直到近日在GoogleI/O 2017上登台亮相，才终于算告一段落。我们非常荣幸能够发布全世界第一个专门面向国内用户的PWA，但更荣幸的是能与 Google、 UC以及腾讯合作，一起推动国内Web与浏览器生态的发展。

多页应用、 Vue.js、 PWA？

对于构建一个希望达到原生应用级别体验的PWA，目前社区里的主流做法都是采用SPA，即单页面应用模型（Single-page App）来组织整个Web应用，业内最有名的几个PWA案例Twitter Lite、 Flipkart Lite、Housing Go 与 Polymer Shop无一例外。

然而饿了么，与很多国内的电商网站一样，青睐多页面应用模型（MPA， Multi-page App）所能带来的一些好处，也因此在一年多前就将移动站从基于AngularJS的单页应用重构为目前的多页应用模型。团队最看重的优点莫过于页面与页面之间的隔离与解耦，这使得我们可以将每个页面当做一个独立的“微服务”来看待，这些服务可以被独立迭代，独立提供给各种第三方的入口嵌入，甚至被不同的团队独立维护。而整个网站则只是各种服务的集合而非一个巨大的整体。

与此同时，我们仍然依赖 Vue.js作为JavaScript框架。 Vue.js除了是React、 AngularJS这种“重型武器”的竞争对手外，其轻量与高性能的优点使得它同样可以作为传统多页应用开发中流行的“jQuery/Zepto/Kissy+模板引擎”技术栈的完美替代。 Vue.js提供的组件系统、声明式与响应式编程更是提升了代码组织、共享、数据流控制、渲染等各个环节的开发效率。 Vue 还是一个渐进式框架，如果网站的复杂度继续提升，我们可以按需、增量地引入Vuex或Vue-Router这些模块。万一哪天又要改回单页呢？（谁知道呢……）

2017年， PWA已经成为Web应用新的风潮。我们决定试试，以我们现有的“Vue.js+多页”架构，能在升级PWA的道路上走多远，达到怎样的效果。

实现“PRPL”模式

“PRPL”（读作“purple”）是Google工程师提出的一种Web应用架构模式，它旨在利用现代Web平台的新技术以大幅优化移动Web的性能与体验，对如何组织与设计高性能的PWA系统提供了一种高层次的抽象。我们并不准备从头重构我们的Web应用，不过我们可以把实现“PRPL”模式作为我们的迁移目标。“PRPL”实际上是“Push/Preload、 Render、 Precache、 Lazy-Load”的缩写，我们接下来会展开介绍它们的具体含义。

Push/Preload，推送/预加载初始URL路由所需的关键资源

无论是HTTP2 Server Push还是，其关键都在于，我们希望提前请求一些隐藏在应用依赖关系（Dependency Graph）较深处的资源，以节省HTTP往返、浏览器解析文档，或脚本执行的时间。比如说，对于一个基于路由进行code splitting的SPA，如果我们可以在Webpack清单、路由等入口代码（entry chunks）被下载与运行之前就把初始URL，即用户访问的入口URL路由所依赖的代码用Server Push推送或进行提前加载。那么当这些资源被真正请求时，它们可能已经下载好并存在缓存中了，这样就加快了初始路由所有依赖的就绪。

在多页应用中，每一个路由本来就只会请求这个路由所需要的资源，并且通常依赖也都比较扁平。饿了么移动站的大部分脚本依赖都是普通的 <script> 元素，因此他们可以在文档解析早期就被浏览器的preloader扫描出来并且开始请求，其效果其实与显式的是一致的，见图1所示。

图1 有无<link rel=“preload”>的效果对比
 
我们还将所有关键的静态资源都伺服在同一域名下（不再做域名散列），以更好地利用HTTP2带来的多路复用（Multiplexing）。同时，我们也在进行着对API进行Server Push的实验。

Render，渲染初始路由，尽快让应用可被交互

既然所有初始路由的依赖都已经就绪，我们就可以尽快开始初始路由的渲染，这有助于提升应用诸如首次渲染时间、可交互时间等指标。多页应用并不使用基于JavaScript的路由，而是传统的HTML跳转机制，所以对于这一部分，多页应用其实不用额外做什么。

Precache，用Service Worker预缓存剩下的路由

这一部分就需要Service Worker的参与了。Service Worker是一个位于浏览器与网络之间的客户端代理，它已可拦截、处理、响应流经的HTTP请求，使得开发者得以从缓存中向Web应用提供资源而闻名。不过， Service Worker其实也可以主动发起 HTTP 请求，在“后台”预请求与预缓存我们未来所需要的资源，见图2所示。

图2 Service Worker预缓存未来所需要的资源
 
我们已经使用Webpack在构建过程中进行.vue编译、文件名哈希等工作，于是我们编写了一个Webpack插件来帮助收集需要缓存的依赖到一个“预缓存清单”中，并使用这个清单在每次构建时生成新的Service Worker文件。在新的Service Worker被激活时，清单里的资源就会被请求与缓存，这其实与SW-Precache 这个库的运行机制非常接近。

实际上，我们只对标记为“关键路由”的路由进行依赖收集。你可以将这些“关键路由”的依赖理解为我们整个应用的“App Shell” 或者说“安装包”。一旦它们都被缓存，或者说成功安装，无论用户是在线离线，我们的Web应用都可以从缓存中直接启动。对于那些并不那么重要的路由，我们则采取在运行时增量缓存的方式。我们使用的SW-Toolbox提供了LRU替换策略与TTL失效机制，可以保证我们的应用不会超过浏览器的缓存配额。

Lazy-Load，按需懒加载、懒实例化剩下的路由

懒加载与懒实例化剩下的路由对于SPA是一件相对麻烦点儿的事情，你需要实现基于路由的code splitting与异步加载。幸运的是，这又是一件不需要多页应用担心的事情，多页应用中的各个路由天生就是分离的。

值得说明的是，无论单页还是多页应用，如果在上一步中，我们已经将这些路由的资源都预先下载与缓存好了，那么懒加载就几乎是瞬时完成的了，这时候我们就只需要付出实例化的代价。

至此，我们对PRPL的四部分含义做了详细说明。有趣的是，我们发现多页应用在实现PRPL这件事甚至比单页还要容易一些。那么结果如何呢？

根据Google推出的Web性能分析工具Lighthouse（v1.6），在模拟的3G网络下，用户的初次访问（无任何缓存）大约在2秒左右达到“可交互”，可以说非常不错，见图3所示。而对于再次访问，由于所有资源都直接来自于Service Worker缓存，页面可以在1秒左右就达到可交互的状态了。
 
图3 Lighthouse跑分结果
 
但是，故事并不是这么简单得就结束了。在实际体验中我们发现，应用在页与页的切换时，仍然存在着非常明显的白屏空隙，见图4所示。由于PWA是全屏运行，白屏对用户体验所带来的负面影响甚至比以往在浏览器内更大。我们不是已经用Service Worker缓存了所有资源了吗，怎么还会这样呢？

图4 从首页点击到发现页，跳转过程中的白屏
 
多页应用的陷阱：重启开销

与SPA不同，在多页应用中，路由的切换是原生的浏览器文档跳转（Navigating across documents），这意味着之前的页面会被完全丢弃而浏览器需要为下一个路由的页面重新执行所有的启动步骤：重新下载资源、重新解析HTML、重新运行JavaScript、重新解码图片、重新布局页面、重新绘制……即使其中的很多步骤本是可以在多个路由之间复用的。这些工作无疑将产生巨大的计算开销，也因此需要付出相当多的时间成本。

图5中为我们的入口页（同时也是最重要的页面）在两倍CPU节流模拟下的Profile数据。即使我们可以将“可交互时间”控制在 1 秒左右，我们的用户仍然会觉得这对于“仅仅切换个标签”来说实在是太慢了。

图5 入口页在两倍CPU节流模拟下的Profile数据

巨大的JavaScript重启开销

根据Profile，我们发现在首次渲染（First Paint）发生之前，大量的时间（900ms）都消耗在了JavaScript的运行上（Evaluate Script）。几乎所有脚本都是阻塞的（Parser-blocking），不过因为所有的UI都是由JavaScript/Vue.js驱动的，倒也不会有性能影响。这900ms中，约一半是消耗在Vue.js运行时、组件、库等依赖的运行上，而另一半则花在了业务组件实例化时Vue.js的启动与渲染上。从软件工程角度来说，我们需要这些抽象，所以这里并不是想责怪JavaScript或是Vue.js所带来的开销。

但是，在SPA中， JavaScript的启动成本是均摊到整个生命周期的：每个脚本都只需要被解析与编译一次，诸如生成Virtual DOM等较重的任务可以只执行一次，像Vue.js的ViewModel或是Virtual DOM这样的大对象也可以被留在内存里复用。可惜在多页应用里就不是这样了，我们每次切换页面都为JavaScript付出了巨大的重启代价。

浏览器的缓存啊，能不能帮帮忙？

能，也不能。

V8提供了代码缓存（code caching），可以将编译后的机器码在本地拷贝一份，这样我们就可以在下次请求同一个脚本时一次省略掉请求、解析、编译的所有工作。而且，对于缓存在Service Worker配套的Cache Storage中的脚本，会在第一次执行后就触发V8的代码缓存，这对于我们的多页切换能提供不少帮助。

另外一个你或许听过的浏览器缓存叫做“进退缓存”， Back-Forward Cache，简称bfcache。浏览器厂商对其的命名各异， Opera称之为Fast History Navigation， Webkit称其为Page Cache。但是思路都一样，就是我们可以让浏览器在跳转时把前一页留存在内存中，保留JavaScript与DOM的状态，而不是全都销毁掉。你可以随便找个传统的多页网站在iOS Safari上试试，无论是通过浏览器的前进后退按钮、手势，还是通过超链接（会有一些不同），基本都可以看到瞬间加载的效果。

Bfcache其实非常适合多页应用。但不幸的是，Chrome由于内存开销与其多进程架构等原因目前并不支持。 Chrome现阶段仅仅只是用了传统的HTTP磁盘缓存，来稍稍简化了一下加载过程而已。对于Chromium内核霸占的Android生态来说，我们没法指望了。

为“感知体验”奋斗

尽管多页应用面临着现实中的不少性能问题，我们并不想这么快就妥协。一方面，我们尝试尽可能减少在页面达到可交互时间前的代码执行量，比如减少/推迟一些依赖脚本的执行，还有减少初次渲染的DOM节点数以节省Virtual DOM的初始化开销。另一方面，我们也意识到应用在感知体验上还有更多的优化空间。

Chrome产品经理Owen写过一篇Reactive Web Design: The secret to building web apps that feel amazing，谈到两种改进感知体验的手段：一是使用骨架屏（Skeleton Screen）来实现瞬间加载；二是预先定义好元素的尺寸来保证加载的稳定。跟我们的做法可以说不谋而合。

为了消除白屏时间，我们同样引入了尺寸稳定的骨架屏来帮助我们实现瞬间的加载与占位。即使是在硬件很弱的设备上，我们也可以在点击切换标签后立刻渲染出目标路由的骨架屏，以保证UI是稳定、连续、有响应的。我录了两个视频放在Youtube上，不过如果你是国内读者，你可以直接访问饿了么移动网站来体验实地的效果。最终效果如图6所示。
 
为“感知体验”奋斗

尽管多页应用面临着现实中的不少性能问题，我们并不想这么快就妥协。一方面，我们尝试尽可能减少在页面达到可交互时间前的代码执行量，比如减少/推迟一些依赖脚本的执行，还有减少初次渲染的DOM节点数以节省Virtual DOM的初始化开销。另一方面，我们也意识到应用在感知体验上还有更多的优化空间。

Chrome产品经理Owen写过一篇Reactive Web Design: The secret to building web apps that feel amazing，谈到两种改进感知体验的手段：一是使用骨架屏（Skeleton Screen）来实现瞬间加载；二是预先定义好元素的尺寸来保证加载的稳定。跟我们的做法可以说不谋而合。

为了消除白屏时间，我们同样引入了尺寸稳定的骨架屏来帮助我们实现瞬间的加载与占位。即使是在硬件很弱的设备上，我们也可以在点击切换标签后立刻渲染出目标路由的骨架屏，以保证UI是稳定、连续、有响应的。我录了两个视频放在Youtube上，不过如果你是国内读者，你可以直接访问饿了么移动网站来体验实地的效果。最终效果如图6所示。
图6 在添加骨架屏后，从发现页点回首页的效果

这效果本该很轻松的就能实现，不过实际上我们还费了点功夫。

在构建时使用 Vue 预渲染骨架屏

你可能已经想到了，为了让骨架屏可以被Service Worker缓存，瞬间加载并独立于JavaScript渲染，我们需要把组成骨架屏的HTML标签、 CSS样式与图片资源一并内联至各个路由的静态*.html文件中。

不过，我们并不准备手动编写这些骨架屏。你想啊，如果每次真实组件有迭代（每一个路由对我们来说都是一个Vue.js组件），我们都需要手动去同步每一个变化到骨架屏的话，那实在是太繁琐且难以维护了。好在，骨架屏不过是当数据还未加载进来前，页面的一个空白版本而已。如果我们能将骨架屏实现为真实组件的一个特殊状态——“空状态”的话，从理论上就可以从真实组件中直接渲染出骨架屏来。

而Vue.js的多才多艺就在这时体现出来了，我们真的可以用Vue.js 的服务端渲染模块来实现这个想法，不过不是用在真正的服务器上，而是在构建时用它把组件的空状态预先渲染成字符串并注入到HTML模板中。你需要调整Vue.js组件代码使得它可以在Node上执行，有些页面对DOM/BOM的依赖一时无法轻易去除得，我们目前只好额外编写一个*.shell.vue来暂时绕过这个问题。

关于浏览器的绘制（Painting）

HTML文件中有标签并不意味着这些标签就能立刻被绘制到屏幕上，你必须保证页面的关键渲染路径是为此优化的。很多开发者相信将Script标签放在body的底部就足以保证内容能在脚本执行之前被绘制，这对于能渲染不完整DOM树的浏览器（比如桌面浏览器常见的流式渲染）来说可能是成立的。但移动端的浏览器很可能因为考虑到较慢的硬件、电量消耗等因素并不这么做。不仅如此，即使你曾被告知设为async或defer的脚本就不会阻塞HTML解析了，但这可不意味着浏览 器就一定会在执行它们之前进行渲染。

首先我想澄清的是，根据 HTML 规范 Scripting 章节， async脚本是在其请求完成后立刻运行的，因此它本来就可能阻塞到解析。只有defer（且非内联）与最新的type=module被指定为“一定不会阻塞解析”（不过defer目前也有点小问题……我们稍后会再提到），见图7所示。
图7 具有不同属性的Script脚本对HTML解析的阻塞情况

而更重要的是，一个不阻塞HTML解析的脚本仍然可能阻塞到绘制。我做了一个简化的“最小多页PWA”（Minimal Multi-page PWA，或MMPWA）来测试这个问题：我们在一个async（且确实不阻塞HTML解析）脚本中，生成并渲染1000个列表项，然后测试骨架屏能否在脚本执行之前渲染出来。图8是通过USB Debugging在我的Nexus 5真机上录制的Profile。


图8 通过USB Debugging在Nexus 5真机上录制的Profile

是的，出乎意料吗？首次渲染确实被阻塞到脚本执行结束后才发生。究其原因，如果我们在浏览器还未完成上一次绘制工作之前就过快得进行了DOM操作，我们亲爱的浏览器就只好抛弃所有它已经完成的像素，且一直要等待到DOM操作引起的所有工作结束之后才能重新进行下一次渲染。而这种情况更容易在拥有较慢CPU/GPU的移动设备上出现。

黑魔法：利用setTimeout()让绘制提前

不难发现，骨架屏的绘制与脚本执行实际是一个竞态。大概是Vue.js太快了，我们的骨架屏还是有非常大的概率绘制不出来。于是我们想着如何能让脚本执行慢点，或者说，“懒”点。于是我们想到了一个经典的Hack： setTimeout(callback, 0)。我们试着把MMPWA中的DOM操作（渲染1000个列表）放进setTimeout(callback, 0)里……

当当！首次渲染瞬间就被提前了，见图9所示。如果你熟悉浏览器的事件循环模型（Event Loop）的话，这招Hack其实是通过setTimeout的回调把DOM操作放到了事件循环的任务队列中以避免它在当前循环执行，这样浏览器就得以在主线程空闲时喘息一下（更新一下渲染）了。如果你想亲手试试 MMPWA的话，你可以访问github.com/Huxpro/mmpwa 或huangxuan.me/mmpwa/ ，查看代码与Demo。我把UI设计成了A/B Test的形式并改为渲染5000个列表项来让效果更夸张一些。

图9 利用Hack技术，提前完成骨架屏的绘制

回到饿了么PWA上，我们同样试着把new Vue()放到了setTimeout中。果然，黑魔法再次显灵，骨架屏在每次跳转后都能立刻被渲染。这时的Profile看起来是这样的，见图10所示。

 
图10 为感知体验进行各种优化后的最终Profile

现在，我们在400ms时触发首次渲染（骨架屏），在600ms时完成真实UI的渲染并达到页面的可交互。你可以详细对比下图9和图10所示的优化前后Profile的区别。

被我“defer”的有关defer的Bug

不知道你发现没有，在图10的Profile中，我们仍然有不少脚本是阻塞了HTML解析的。好吧，让我解释一下，由于历史原因，我们确实保留了一部分的阻塞脚本，比如侵入性很强的lib-flexible，我们没法轻易去除它。不过， Profile里的大部分阻塞脚本实际上都设置了defer，我们本以为他们应该在HTML解析完成之后才被执行，结果被Profile打了一脸。

我和Jake Archibald 聊了一下，果然这是Chrome的Bug： defer的脚本被完全缓存时，并没有遵守规范等待解析结束，反而阻塞了解析与渲染。Jake已经提交在crbug上了，一起给它投票吧。

最后，图11是优化后的Lighthouse跑分结果，同样可以看到明显的性能提升。需要说明的是，能影响Lighthouse跑分的因素有很多，所以我建议你以控制变量（跑分用的设备、跑分时的网络环境等）的方式来进行对照实验。

图11 优化后的Lighthouse跑分结果

最后为大家展示下应用的架构示意图，见图12所示。

图12 应用架构示意图

一些感想

多页应用仍然有很长的路要走

Web是一个极其多样化的平台。从静态的博客，到电商网站，再到桌面级的生产力软件，它们全都是Web这个大家庭的第一公民。而我们组织Web应用的方式，也同样只会更多而不会更少：多页、单页、 Universal JavaScript应用、 WebGL，以及可以预见的Web Assembly。不同的技术之间没有贵贱，但是适用场景的差距确是客观存在的。

Jake 曾在 Chrome Dev Summit 2016 上说过“PWA!== SPA”。可是尽管我们已经用上了一系列最新的技术（PRPL、 Service Worker、 App Shell……），我们仍然因为多页应用模型本身的缺陷有着难以逾越的一些障碍。多页应用在未来可能会有“bfcache API”、 Navigation Transition等新的规范以缩小跟SPA的距离，不过我们也必须承认，时至今日，多页应用的局限性也是非常明显的。

而PWA终将带领Web应用进入新的时代

即使我们的多页应用在升级PWA的路上不如单页应用来得那么闪亮，但是PWA背后的想法与技术却实实在在地帮助我们在Web平台上提供了更好的用户体验。

PWA作为下一代 Web 应用模型，其尝试解决的是Web平台本身的根本性问题：对网络与浏览器UI的硬依赖。因此，任何Web应用都可以从中获益，这与你是多页还是单页、面向桌面还是移动端、是用React还是Vue.js无关。或许，它还终将改变用户对移动Web的期待。现如今，谁还觉得桌面端的Web只是个看文档的地方呢？

还是那句老话，让我们的用户，也像我们这般热爱Web吧。

最后，感谢饿了么的王亦斯、任光辉、题叶，Google 的 Michael Yeung、 DevRel 团队， UC浏览器团队，腾讯X5浏览器团队在这次项目中的合作。感谢尤雨溪、陈蒙迪和Jake Archibald 在写作过程中给予我的帮助。
 
原文阅读：https://zhuanlan.zhihu.com/p/27836133 查看全部

这个其实之前火过一阵子，当时也没怎么注意，今天看到空间里又有人在刷这个字符了，所以决定分析下他是什么东西。
复制这个字符在控制台查看 "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎".length 发现他的长度是 20，怎么会是20呢？
我们依次调试  "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎".charAt(0), "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎".charAt(1), "a๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎๎".charAt(2)  可以发现第一个字符是a 后面都是其他什么东西组成的。

当你黏贴到notepad++之类的编辑器里，也会发现这个问题，后台那些是重复的字符，而且都可以看到。
这些字符到底是什么东西呢？

突然想起js圣经上貌似记载过一个 é 字符，他的 unicode 是 \u00e9, 但是也可以用 'e' + '\u0301' 实现 "é" 前者 length 是 1，后者 length 是 2。'\u0301' 在这里起到了语调符的作用，然后我就丧心病狂的  'e'+Array(20).join('\u0301');  发现竟然成功了，果然是这个东西，但是这个语调符有哪些呢。
继续寻找答案，在圣经的注释里发现了他貌似属于 Mn 类，去unicode官方找这个东西，一番寻找后终于找到他了，详情请参阅。

这里解释了 Mn 其实是 a nonspacing combining mark (zero advance width) (谷歌翻译: 一个非空格组合标志（零超前宽度）)。
虽然给了解释，但是还是没有说他有那些字符啊，所以我继续寻找答案，功夫不负有心人，终于找到了一张表。
Unicode Characters in the 'Mark, Nonspacing' Category 
这里详细的列出了每个编码以及对应的意思，还有图片展现。你可以点击头部那个 View all images 超链接，这样你就不必一个一个展开看图片了。

找到这个的时候我欣喜诺狂，各种测试，发现不仅仅是向上，还有 向左，向下的，但是暂时没发现向右的。
这里面有很多符号，虽然不知道他们在什么情况下使用，但是我的目的达到了，后续的东西暂时没欲望刨根问底了。

下面是我找的几个方向的小尾巴，大家也可以自己去各种测试起来。。
 
'呵呵'+Array(20).join('\u0310');  // "呵呵̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐"
 '呵呵'+Array(20).join('\u031D');             // "呵呵̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝̝"
 '呵呵'+Array(20).join('\u0E47');                          // "呵呵็็็็็็็็็็็็็็็็็็็"
 '呵呵'+Array(20).join('\u0e49');                                       // "呵呵้้้้้้้้้้้้้้้้้้้"
 '呵呵'+Array(20).join('\u0598');        // "呵呵֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘"
 
也可以这么玩...

 '呵呵'+Array(20).join('\u0310')+Array(20).join('\u0598')+Array(20).join('\u0e49');  // "呵呵้้้้้้้้้้้้้้้้้้้̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐̐֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘֘" 查看全部

json 是一种很简洁的协议，但可惜的是，它只能传递基本的数型(int,long,string等)，但不能传递byte类型。如果想要传输图片等二进制文件的话，是没办法直接传输。

本文提供一种思路给大家参考，让大家可以在json传输二进制文件，如果大家有这个需求又不知怎么实现的话，也许本文能够帮到你。思想适用于所有语言，本文以java实现，相信大家很容易就能转化为自己懂得语言。
 
思路

1. 读取二进制文件到内存

2. 用Gzip压缩一下。毕竟是在网络传输嘛，当然你也可以不压缩。

3. 用Base64 把byte[] 转成字符串
 
补充：什么是Base64

以下摘自阮一峰博客,Base64的具体编码方式，大家可以直接进入。

Base64是一种编码方式，它可以将8位的非英语字符转化为7位的ASCII字符。这样的初衷，是为了满足电子邮件中不能直接使用非ASCII码字符的规定，但是也有其他重要的意义：
 

a）所有的二进制文件，都可以因此转化为可打印的文本编码，使用文本软件进行编辑；

b）能够对文本进行简单的加密。

 
实现

主要思路就是以上3步，把字符串添加到json字段后发给服务端，然后服务器再用Base64解密–>Gzip解压，就能得到原始的二进制文件了。是不是很简单呢？说了不少，下面我们来看看具体的代码实现。/**
* @author xing
*/
public class TestBase64 {
public static void main(String[] args) {
byte[] data = compress(loadFile());

String json = new String(Base64.encodeBase64(data));
System.out.println("data length:" + json.length());
}

/**
* 加载本地文件,并转换为byte数组
* @return
*/
public static byte[] loadFile() {
File file = new File("d:/11.jpg");

FileInputStream fis = null;
ByteArrayOutputStream baos = null;
byte[] data = null ;

try {
fis = new FileInputStream(file);
baos = new ByteArrayOutputStream((int) file.length());

byte[] buffer = new byte[1024];
int len = -1;
while ((len = fis.read(buffer)) != -1) {
baos.write(buffer, 0, len);
}

data = baos.toByteArray() ;

} catch (IOException e) {
e.printStackTrace();
} finally {
try {
if (fis != null) {
fis.close();
fis = null;
}

baos.close() ;
} catch (IOException e) {
e.printStackTrace();
}
}

return data ;
}

/**
* 对byte[]进行压缩
*
* @param 要压缩的数据
* @return 压缩后的数据
*/
public static byte[] compress(byte[] data) {
System.out.println("before:" + data.length);

GZIPOutputStream gzip = null ;
ByteArrayOutputStream baos = null ;
byte[] newData = null ;

try {
baos = new ByteArrayOutputStream() ;
gzip = new GZIPOutputStream(baos);

gzip.write(data);
gzip.finish();
gzip.flush();

newData = baos.toByteArray() ;
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
gzip.close();
baos.close() ;
} catch (IOException e) {
e.printStackTrace();
}
}

System.out.println("after:" + newData.length);
return newData ;
}
} 最后输出了一下字符串长度，大家也许觉得经过压缩也没降低多少体积嘛。但大家可以试试不用gzip，你会发现经过转换的字符串比原来大多了。没办法，这是由Base64的算法决定的。所以嘛，还是压缩一下好。

本文所使用的方法比较简单，大家如果有更好或者觉得有更好的方式，不妨一起探讨一下。
 
【服务端传输】
 
我们都知道json是文本格式.所以我马上想到的是把文件编码成文本,再进行传输. 所以关键就是要把一个二进制文件翻译成文本,再翻译回去.如果可以,也就代表这个方案是可行的. 马上我就写出了第一个版本: 
// 读取文件
FileInputStream fileInputStream = new FileInputStream("d:/a.png");
ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
int i;
while ((i = fileInputStream.read()) != -1) {
byteArrayOutputStream.write(i);
}
fileInputStream.close();
// 把文件存在一个字节数组中
byte[] filea = byteArrayOutputStream.toByteArray();
byteArrayOutputStream.close();

String fileaString = new String(filea);
System.out.println(fileaString);
// 写入文件
FileOutputStream fileOutputStream = new FileOutputStream("d:/b.png");
fileOutputStream.write(fileaString.getBytes());
fileOutputStream.flush();
fileOutputStream.close();
发现b.png根本无法打开,很是奇怪?而且大小也不一样了. 检查代码后发现把数组转化成string的时候后面还可以加个参数charset[编码名称]. 

于是马上改了一下: .......
String fileaString = new String(filea,"uft-8");
.......
fileOutputStream.write(fileaString.getBytes("utf-8"));
结果还是不行,又改了一下: .......
String fileaString = new String(filea,"ISO-8859-1");
.......
fileOutputStream.write(fileaString.getBytes("ISO-8859-1"));
结果成功了. 

结合以前的编码知识,总算是想明白了：
把字节数组转换成字符串时,如果charset为空,那就表示用你的默认编码进行转换. 
而不管gb2312和utf8都不是用单字节表示一个字符的.只要他不认识的,他就会默认转换成一个特定字符,所以这样的转换是不可逆的. 
只有像ascii这样的单字节编码的转换才是可逆的. 
明白了这个道理.我们就可以用json协议来传任何的数据了.^_^,大功告成! 

有关编码的问题我推荐阮一峰的一篇博文,对字符编码有很好的解释. 
http://www.ruanyifeng.com/blog ... .html 
  查看全部

/** 

 * @author xing 

 */  

public class TestBase64 {  

    public static void main(String[] args) {  

        byte[] data = compress(loadFile());  

  

        String json = new String(Base64.encodeBase64(data));  

        System.out.println("data length:" + json.length());  

    }  

      

    /** 

     * 加载本地文件,并转换为byte数组 

     * @return 

     */  

    public static byte[] loadFile() {  

        File file = new File("d:/11.jpg");  

  

        FileInputStream fis = null;  

        ByteArrayOutputStream baos = null;  

        byte[] data = null ;  

  

        try {  

            fis = new FileInputStream(file);  

            baos = new ByteArrayOutputStream((int) file.length());  

  

            byte[] buffer = new byte[1024];  

            int len = -1;  

            while ((len = fis.read(buffer)) != -1) {  

                baos.write(buffer, 0, len);  

            }  

              

            data = baos.toByteArray() ;  

  

        } catch (IOException e) {  

            e.printStackTrace();  

        } finally {  

            try {  

                if (fis != null) {  

                    fis.close();  

                    fis = null;  

                }  

                  

                baos.close() ;  

            } catch (IOException e) {  

                e.printStackTrace();  

            }  

        }  

          

        return data ;  

    }  

      

    /** 

     * 对byte[]进行压缩 

     *  

     * @param 要压缩的数据 

     * @return 压缩后的数据 

     */  

    public static byte[] compress(byte[] data) {  

        System.out.println("before:" + data.length);  

          

        GZIPOutputStream gzip = null ;  

        ByteArrayOutputStream baos = null ;  

        byte[] newData = null ;  

          

        try {  

            baos = new ByteArrayOutputStream() ;  

            gzip = new GZIPOutputStream(baos);  

              

            gzip.write(data);  

            gzip.finish();  

            gzip.flush();  

              

            newData = baos.toByteArray() ;  

        } catch (IOException e) {  

            e.printStackTrace();  

        } finally {  

            try {  

                gzip.close();  

                baos.close() ;  

            } catch (IOException e) {  

                e.printStackTrace();  

            }  

        }  

          

        System.out.println("after:" + newData.length);  

        return newData ;  

    }  

}  

		// 读取文件

		FileInputStream fileInputStream = new FileInputStream("d:/a.png");

		ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();

		int i;

		while ((i = fileInputStream.read()) != -1) {

			byteArrayOutputStream.write(i);

		}

		fileInputStream.close();

		// 把文件存在一个字节数组中

		byte[] filea = byteArrayOutputStream.toByteArray();

		byteArrayOutputStream.close();



		String fileaString = new String(filea);

		System.out.println(fileaString);

		// 写入文件

		FileOutputStream fileOutputStream = new FileOutputStream("d:/b.png");

		fileOutputStream.write(fileaString.getBytes());

		fileOutputStream.flush();

		fileOutputStream.close();

....... 

String fileaString = new String(filea,"uft-8"); 

....... 

fileOutputStream.write(fileaString.getBytes("utf-8")); 

....... 

String fileaString = new String(filea,"ISO-8859-1"); 

....... 

fileOutputStream.write(fileaString.getBytes("ISO-8859-1")); 

当一个资源从与该资源本身所在的服务器不同的域或端口请求一个资源时，资源会发起一个跨域 HTTP 请求。
 
比如，站点 http://domain-a.com 的某 HTML 页面通过 <img> 的 src 请求 http://domain-b.com/image.jpg。网络上的许多页面都会加载来自不同域的CSS样式表，图像和脚本等资源。
 出于安全原因，浏览器限制从脚本内发起的跨源HTTP请求。 例如，XMLHttpRequest和Fetch API遵循同源策略。 这意味着使用这些API的Web应用程序只能从加载应用程序的同一个域请求HTTP资源，除非使用CORS头文件。

  （译者注：这段描述跨域不准确，跨域并不一定是浏览器限制了发起跨站请求，也可能是跨站请求可以正常发起，但是返回结果被浏览器拦截了。最好的例子是 CSRF 跨站攻击原理，请求是发送到了后端服务器无论是否跨域！注意：有些浏览器不允许从 HTTPS 的域跨域访问 HTTP，比如  Chrome 和 Firefox，这些浏览器在请求还未发出的时候就会拦截请求，这是一个特例。）
 

 
跨域资源共享标准（ cross-origin sharing standard  ）允许在下列场景中使用跨域 HTTP 请求： 
前文提到的由 XMLHttpRequest 或 Fetch 发起的跨域 HTTP 请求。Web 字体 (CSS 中通过 @font-face 使用跨域字体资源), 因此，网站就可以发布 TrueType 字体资源，并只允许已授权网站进行跨站调用。WebGL 贴图使用 drawImage 将 Images/video 画面绘制到 canvas样式表（使用 CSSOM）Scripts (未处理的异常)

本文概述了跨域资源共享机制及其所涉及的 HTTP 首部字段。 
概述

跨域资源共享标准新增了一组 HTTP 首部字段，允许服务器声明哪些源站有权限访问哪些资源。另外，规范要求，对那些可能对服务器数据产生副作用的 HTTP 请求方法（特别是 GET 以外的 HTTP 请求，或者搭配某些 MIME 类型的 POST 请求），浏览器必须首先使用 OPTIONS 方法发起一个预检请求（preflight request），从而获知服务端是否允许该跨域请求。服务器确认允许之后，才发起实际的 HTTP 请求。在预检请求的返回中，服务器端也可以通知客户端，是否需要携带身份凭证（包括 Cookies 和 HTTP 认证相关数据）。

接下来的内容将讨论相关场景，并剖析该机制所涉及的 HTTP 首部字段。 
若干访问控制场景

这里，我们使用三个场景来解释跨域资源共享机制的工作原理。这些例子都使用 XMLHttpRequest 对象。 
简单请求
 某些请求不会触发 CORS 预检请求。本文称这样的请求为“简单请求”，请注意，该术语并不属于 Fetch （其中定义了 CORS）规范。若请求满足所有下述条件，则该请求可视为“简单请求”：
 
1.使用下列方法之一：
GETHEADPOST

2.Fetch 规范定义了对 CORS 安全的首部字段集合，不得人为设置该集合之外的其他首部字段。该集合为：
AcceptAccept-LanguageContent-LanguageContent-Type （需要注意额外的限制）DPRDownlinkSave-DataViewport-WidthWidth

3.Content-Type 的值仅限于下列三者之一：
text/plainmultipart/form-dataapplication/x-www-form-urlencoded
 
比如说，假如站点 http://foo.example 的网页应用想要访问 http://bar.other 的资源。http://foo.example 的网页中可能包含类似于下面的 JavaScript 代码：var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/public-data/';

function callOtherDomain() {
if(invocation) {
invocation.open('GET', url, true);
invocation.onreadystatechange = handler;
invocation.send();
}
}客户端和服务器之间使用 CORS 首部字段来处理跨域权限：

 
分别检视请求报文和响应报文：GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/ac ... .html
Origin: http://foo.example


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[XML Data]第 1~10 行是请求首部。第10行 的请求首部字段 Origin 表明该请求来源于 http://foo.exmaple。

第 13~22 行是来自于 http://bar.other 的服务端响应。响应中携带了响应首部字段 Access-Control-Allow-Origin（第 16 行）。使用 Origin 和 Access-Control-Allow-Origin 就能完成最简单的访问控制。本例中，服务端返回的 Access-Control-Allow-Origin: * 表明，该资源可以被任意外域访问。如果服务端仅允许来自 http://foo.example 的访问，该首部字段的内容如下：

Access-Control-Allow-Origin: http://foo.example

现在，除了 http://foo.example，其它外域均不能访问该资源（该策略由请求首部中的 ORIGIN 字段定义，见第10行）。Access-Control-Allow-Origin 应当为 * 或者包含由 Origin 首部字段所指明的域名。 
预检请求
 
与前述简单请求不同，“需预检的请求”要求必须首先使用 OPTIONS   方法发起一个预检请求到服务器，以获知服务器是否允许该实际请求。"预检请求“的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响。

当请求满足下述任一条件时，即应首先发送预检请求：
 
1.使用了下面任一 HTTP 方法：
 PUTDELETECONNECTOPTIONSTRACEPATCH

2.人为设置了对 CORS 安全的首部字段集合之外的其他首部字段。该集合为：
AcceptAccept-LanguageContent-LanguageContent-Type (but note the additional requirements below)DPRDownlinkSave-DataViewport-WidthWidth

 3.Content-Type 的值不属于下列之一:
application/x-www-form-urlencodedmultipart/form-datatext/plain
 
如下是一个需要执行预检请求的 HTTP 请求：var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';

function callOtherDomain(){
if(invocation)
{
invocation.open('POST', url, true);
invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
invocation.setRequestHeader('Content-Type', 'application/xml');
invocation.onreadystatechange = handler;
invocation.send(body);
}
}

......上面的代码使用 POST 请求发送一个 XML 文档，该请求包含了一个自定义的请求首部字段（X-PINGOTHER: pingpong）。另外，该请求的 Content-Type 为 application/xml。因此，该请求需要首先发起“预检请求”。
OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain预检请求完成之后，发送实际请求：POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: http://foo.example/examples/pr ... .html
Content-Length: 55
Origin: http://foo.example
Pragma: no-cache
Cache-Control: no-cache

<?xml version="1.0"?><person><name>Arun</name></person>


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some GZIP'd payload]浏览器检测到，从 JavaScript 中发起的请求需要被预检。从上面的报文中，我们看到，第 1~12 行发送了一个使用 OPTIONS 方法的“预检请求”。 OPTIONS 是 HTTP/1.1 协议中定义的方法，用以从服务器获取更多信息。该方法不会对服务器资源产生影响。 预检请求中同时携带了下面两个首部字段：Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER首部字段 Access-Control-Request-Method 告知服务器，实际请求将使用 POST 方法。
首部字段 Access-Control-Request-Headers 告知服务器，实际请求将携带两个自定义请求首部字段：X-PINGOTHER 与 Content-Type。
服务器据此决定，该实际请求是否被允许。第14~26 行为预检请求的响应，表明服务器将接受后续的实际请求。重点看第 17~20 行：Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400首部字段 Access-Control-Allow-Methods 表明服务器允许客户端使用 POST, GET 和OPTIONS 方法发起请求。该字段与 HTTP/1.1 Allow: response header 类似，但仅限于在需要访问控制的场景中使用。首部字段 Access-Control-Allow-Headers 表明服务器允许请求中携带字段 X-PINGOTHER 与 Content-Type。与 Access-Control-Allow-Methods 一样，Access-Control-Allow-Headers 的值为逗号分割的列表。
最后，首部字段 Access-Control-Max-Age 表明该响应的有效时间为 86400 秒，也就是 24 小时。在有效时间内，浏览器无须为同一请求再次发起预检请求。请注意，浏览器自身维护了一个最大有效时间，如果该首部字段的值超过了最大有效时间，将不会生效。
 
预检请求与重定向
大多数浏览器不支持针对于预检请求的重定向。如果一个预检请求发生了重定向，浏览器将报告错误：The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight

Request requires preflight, which is disallowed to follow cross-origin redirectCORS 最初要求该行为，不过在后续的修订中废弃了这一要求。

在浏览器的实现跟上规范之前，有两种方式规避上述报错行为：
在服务端去掉对预检请求的重定向；将实际请求变成一个简单请求。

如果上面两种方式难以做到，我们仍有其他办法：
使用简单请求模拟预检请求，用以探查预检请求是否重定向到其他 URL（使用  Response.url 或 XHR.responseURL）；向上一步中获得的 URL 发起请求。

不过，如果请求由于缺失 Authorization 字段而引起一个预检请求，则这一方法将无法使用。这种情况只能由服务端进行更改。
 
附带身份凭证的请求
 Fetch 与 CORS 的一个有趣的特性是，可以基于  HTTP cookies 和 HTTP 认证信息发送身份凭证。一般而言，对于跨域 XMLHttpRequest 或 Fetch 请求，浏览器不会发送身份凭证信息。如果要发送凭证信息，需要设置 XMLHttpRequest 的某个特殊标志位。
 
本例中，http://foo.example 的某脚本向 http://bar.other 发起一个GET 请求，并设置 Cookies：var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/credentialed-content/';

function callOtherDomain(){
if(invocation) {
invocation.open('GET', url, true);
invocation.withCredentials = true;
invocation.onreadystatechange = handler;
invocation.send();
}
}第 7 行将 XMLHttpRequest 的 withCredentials 标志设置为 true，从而向服务器发送 Cookies。因为这是一个简单 GET 请求，所以浏览器不会对其发起“预检请求”。但是，如果服务器端的响应中未携带 Access-Control-Allow-Credentials: true ，浏览器将不会把响应内容返回给请求的发送者。
 
 
客户端与服务器端交互示例如下：GET /resources/access-control-with-credentials/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/credential.html
Origin: http://foo.example
Cookie: pageAccess=2


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:34:52 GMT
Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
X-Powered-By: PHP/5.2.6
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Credentials: true
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 106
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain


[text/plain payload]即使第 11 行指定了 Cookie 的相关信息，但是，如果 bar.other 的响应中缺失 Access-Control-Allow-Credentials: true（第 19 行），则响应内容不会返回给请求的发起者。
 
附带身份凭证的请求与通配符
 
对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为“*”。

这是因为请求的首部中携带了 Cookie 信息，如果 Access-Control-Allow-Origin 的值为“*”，请求将会失败。而将 Access-Control-Allow-Origin 的值设置为 http://foo.example，则请求将成功执行。

另外，响应首部中也携带了 Set-Cookie 字段，尝试对 Cookie 进行修改。如果操作失败，将会抛出异常。
 
HTTP 响应首部字段
 本节列出了规范所定义的响应首部字段。上一小节中，我们已经看到了这些首部字段在实际场景中是如何工作的。
 
Access-Control-Allow-Origin
 
响应首部中可以携带一个 Access-Control-Allow-Origin 字段，其语法如下:Access-Control-Allow-Origin: <origin> | *其中，origin 参数的值指定了允许访问该资源的外域 URI。对于不需要携带身份凭证的请求，服务器可以指定该字段的值为通配符，表示允许来自所有域的请求。

例如，下面的字段值将允许来自 http://mozilla.com 的请求：Access-Control-Allow-Origin: http://mozilla.com如果服务端指定了具体的域名而非“*”，那么响应首部中的 Vary 字段的值必须包含 Origin。这将告诉客户端：服务器对不同的源站返回不同的内容。
 
Access-Control-Expose-Headers
 
译者注：在跨域访问时，XMLHttpRequest对象的getResponseHeader()方法只能拿到一些最基本的响应头，Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma，如果要访问其他头，则需要服务器设置本响应头。 
Access-Control-Expose-Headers 头让服务器把允许浏览器访问的头放入白名单，例如：
Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header这样浏览器就能够通过getResponseHeader访问X-My-Custom-Header和 X-Another-Custom-Header 响应头了。
 
Access-Control-Max-Age
 
Access-Control-Max-Age 头指定了preflight请求的结果能够被缓存多久，请参考本文在前面提到的preflight例子。
Access-Control-Max-Age: <delta-seconds>delta-seconds 参数表示preflight请求的结果在多少秒内有效。
 
Access-Control-Allow-Credentials
Access-Control-Allow-Credentials 头指定了当浏览器的credentials设置为true时是否允许浏览器读取response的内容。当用在对preflight预检测请求的响应中时，它指定了实际的请求是否可以使用credentials。请注意：简单 GET 请求不会被预检；如果对此类请求的响应中不包含该字段，这个响应将被忽略掉，并且浏览器也不会将相应内容返回给网页。
Access-Control-Allow-Credentials: true上文已经讨论了附带身份凭证的请求。
 
Access-Control-Allow-Methods
Access-Control-Allow-Methods 首部字段用于预检请求的响应。其指明了实际请求所允许使用的 HTTP 方法。
Access-Control-Allow-Methods: <method>[, <method>]*相关示例见这里。
 
Access-Control-Allow-Headers
 
Access-Control-Allow-Headers 首部字段用于预检请求的响应。其指明了实际请求中允许携带的首部字段。
Access-Control-Allow-Headers: <field-name>[, <field-name>]*
HTTP 请求首部字段
 
Origin 首部字段表明预检请求或实际请求的源站。
Origin: <origin>origin 参数的值为源站 URI。它不包含任何路径信息，只是服务器名称。
Note: 有时候将该字段的值设置为空字符串是有用的，例如，当源站是一个 data URL 时。
注意，不管是否为跨域请求，ORIGIN 字段总是被发送。
 
Access-Control-Request-Method
Access-Control-Request-Method 首部字段用于预检请求。其作用是，将实际请求所使用的 HTTP 方法告诉服务器。Access-Control-Request-Method: <method>
 
Access-Control-Request-Headers
Access-Control-Request-Headers 首部字段用于预检请求。其作用是，将实际请求所携带的首部字段告诉服务器。
Access-Control-Request-Headers: <field-name>[, <field-name>]*
浏览器兼容性










 
注：
IE 10 提供了对规范的完整支持，但在较早版本（8 和 9）中，CORS 机制是借由 XDomainRequest 对象完成的。Firefox 3.5 引入了对 XMLHttpRequests 和 Web 字体的跨域支持（但最初的实现并不完整，这在后续版本中得到完善）；Firefox 7 引入了对 WebGL 贴图的跨域支持；Firefox 9 引入了对 drawImage 的跨域支持。
 
参考文档：https://developer.mozilla.org/ ... _CORS 查看全部

var invocation = new XMLHttpRequest();

var url = 'http://bar.other/resources/public-data/';

   

function callOtherDomain() {

  if(invocation) {    

    invocation.open('GET', url, true);

    invocation.onreadystatechange = handler;

    invocation.send(); 

  }

}

GET /resources/public-data/ HTTP/1.1

Host: bar.other

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Connection: keep-alive

Referer: http://foo.example/examples/ac ... .html

Origin: http://foo.example





HTTP/1.1 200 OK

Date: Mon, 01 Dec 2008 00:23:53 GMT

Server: Apache/2.0.61 

Access-Control-Allow-Origin: *

Keep-Alive: timeout=2, max=100

Connection: Keep-Alive

Transfer-Encoding: chunked

Content-Type: application/xml



[XML Data]

var invocation = new XMLHttpRequest();

var url = 'http://bar.other/resources/post-here/';

var body = '<?xml version="1.0"?><person><name>Arun</name></person>';

    

function callOtherDomain(){

  if(invocation)

    {

      invocation.open('POST', url, true);

      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');

      invocation.setRequestHeader('Content-Type', 'application/xml');

      invocation.onreadystatechange = handler;

      invocation.send(body); 

    }

}



......

OPTIONS /resources/post-here/ HTTP/1.1

Host: bar.other

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Connection: keep-alive

Origin: http://foo.example

Access-Control-Request-Method: POST

Access-Control-Request-Headers: X-PINGOTHER, Content-Type





HTTP/1.1 200 OK

Date: Mon, 01 Dec 2008 01:15:39 GMT

Server: Apache/2.0.61 (Unix)

Access-Control-Allow-Origin: http://foo.example

Access-Control-Allow-Methods: POST, GET, OPTIONS

Access-Control-Allow-Headers: X-PINGOTHER, Content-Type

Access-Control-Max-Age: 86400

Vary: Accept-Encoding, Origin

Content-Encoding: gzip

Content-Length: 0

Keep-Alive: timeout=2, max=100

Connection: Keep-Alive

Content-Type: text/plain

POST /resources/post-here/ HTTP/1.1

Host: bar.other

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Connection: keep-alive

X-PINGOTHER: pingpong

Content-Type: text/xml; charset=UTF-8

Referer: http://foo.example/examples/pr ... .html

Content-Length: 55

Origin: http://foo.example

Pragma: no-cache

Cache-Control: no-cache



<?xml version="1.0"?><person><name>Arun</name></person>





HTTP/1.1 200 OK

Date: Mon, 01 Dec 2008 01:15:40 GMT

Server: Apache/2.0.61 (Unix)

Access-Control-Allow-Origin: http://foo.example

Vary: Accept-Encoding, Origin

Content-Encoding: gzip

Content-Length: 235

Keep-Alive: timeout=2, max=99

Connection: Keep-Alive

Content-Type: text/plain



[Some GZIP'd payload]

Access-Control-Request-Method: POST

Access-Control-Request-Headers: X-PINGOTHER

Access-Control-Allow-Origin: http://foo.example

Access-Control-Allow-Methods: POST, GET, OPTIONS

Access-Control-Allow-Headers: X-PINGOTHER, Content-Type

Access-Control-Max-Age: 86400

The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight



Request requires preflight, which is disallowed to follow cross-origin redirect

var invocation = new XMLHttpRequest();

var url = 'http://bar.other/resources/credentialed-content/';

    

function callOtherDomain(){

  if(invocation) {

    invocation.open('GET', url, true);

    invocation.withCredentials = true;

    invocation.onreadystatechange = handler;

    invocation.send(); 

  }

}

GET /resources/access-control-with-credentials/ HTTP/1.1

Host: bar.other

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Connection: keep-alive

Referer: http://foo.example/examples/credential.html

Origin: http://foo.example

Cookie: pageAccess=2





HTTP/1.1 200 OK

Date: Mon, 01 Dec 2008 01:34:52 GMT

Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2

X-Powered-By: PHP/5.2.6

Access-Control-Allow-Origin: http://foo.example

Access-Control-Allow-Credentials: true

Cache-Control: no-cache

Pragma: no-cache

Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT

Vary: Accept-Encoding, Origin

Content-Encoding: gzip

Content-Length: 106

Keep-Alive: timeout=2, max=100

Connection: Keep-Alive

Content-Type: text/plain





[text/plain payload]

Access-Control-Allow-Origin: <origin> | *

Access-Control-Allow-Origin: http://mozilla.com

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

Access-Control-Max-Age: <delta-seconds>

Access-Control-Allow-Credentials: true

Access-Control-Allow-Methods: <method>[, <method>]*

Access-Control-Allow-Headers: <field-name>[, <field-name>]*

Origin: <origin>

Access-Control-Request-Method: <method>

Access-Control-Request-Headers: <field-name>[, <field-name>]*